From nobody Sun Nov 1 17:43:05 2015 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE741B408C; Sun, 1 Nov 2015 17:43:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.7.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151102014302.1094.4026.idtracker@ietfa.amsl.com> Date: Sun, 01 Nov 2015 17:43:02 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-10.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 01:43:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Router Keying for BGPsec Authors : Randy Bush Sean Turner Keyur Patel Filename : draft-ietf-sidr-rtr-keying-10.txt Pages : 13 Date : 2015-11-01 Abstract: BGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements. The corresponding public keys are published in the global Resource Public Key Infrastructure, enabling verification of BGPsec messages. This document describes two methods of generating the public-private key-pairs: router-driven and operator-driven. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Nov 1 17:54:34 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7907E1B4114 for ; Sun, 1 Nov 2015 17:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csTeY7JLotdV for ; Sun, 1 Nov 2015 17:54:32 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 762991B4112 for ; Sun, 1 Nov 2015 17:54:32 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Zt4KM-0007L3-Qi for sidr@ietf.org; Mon, 02 Nov 2015 01:54:31 +0000 Date: Mon, 02 Nov 2015 10:54:30 +0900 Message-ID: From: Randy Bush To: sidr wg list In-Reply-To: <20151102014302.1094.4026.idtracker@ietfa.amsl.com> References: <20151102014302.1094.4026.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-10.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 01:54:33 -0000 this should have answered all comments in addition, a major change. previous drafts na=EFvely assumed the router could send a PKCS#10 to the relevant RPKI CA. this ignored how the CA would know the request was authentic. oops! now, the operator has to mediate the conversation. i am willing to take five minutes of floor time to discuss/explain this. randy From nobody Mon Nov 2 01:37:35 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F541A0015 for ; Mon, 2 Nov 2015 01:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2v5WZCZRI0o for ; Mon, 2 Nov 2015 01:37:32 -0800 (PST) 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 E927B1A000A for ; Mon, 2 Nov 2015 01:37:31 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1ZtBYP-0003Em-4D; Mon, 02 Nov 2015 10:37:30 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-145.ripe.net) by titi.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1ZtBYO-0001cQ-Mk; Mon, 02 Nov 2015 10:37:29 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Tim Bruijnzeels In-Reply-To: Date: Mon, 2 Nov 2015 18:37:25 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <7CF279A5-3609-4EAC-90FF-BA1B1B6E4578@ripe.net> References: <20151102014302.1094.4026.idtracker@ietfa.amsl.com> To: Randy Bush X-Mailer: Apple Mail (2.2104) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07197de84208bb7c588bbfafdb8bb975e45d Archived-At: Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-10.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 09:37:33 -0000 Hi Randy, Good point, and I have to admit that I don't have a clear picture of = this yet (there is definitely a part on me there..). But in any case if = we are to support signing router certificates in a hosted solution, then = it's important that that improves. So I would be very happy to hear about this. Tim > On 02 Nov 2015, at 10:54, Randy Bush wrote: >=20 > this should have answered all comments >=20 > in addition, a major change. previous drafts na=EFvely assumed the = router > could send a PKCS#10 to the relevant RPKI CA. this ignored how the CA > would know the request was authentic. oops! now, the operator has to > mediate the conversation. i am willing to take five minutes of floor > time to discuss/explain this. >=20 > randy >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Mon Nov 2 14:49:27 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49921A8A86 for ; Mon, 2 Nov 2015 14:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GV_Dp3wTiegf for ; Mon, 2 Nov 2015 14:49:24 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A49E1A8A84 for ; Mon, 2 Nov 2015 14:49:24 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id BFF0928B003D for ; Mon, 2 Nov 2015 17:49:23 -0500 (EST) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id F1F2B1F8035; Mon, 2 Nov 2015 17:49:22 -0500 (EST) From: Sandra Murphy X-Pgp-Agent: GPGMail 2.5.1 Content-Type: multipart/signed; boundary="Apple-Mail=_9B00D1BE-CDA2-48BB-95C2-476302FEDE83"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Tue, 3 Nov 2015 07:48:00 +0900 Message-Id: To: sidr wg list Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Sandra Murphy Subject: [sidr] new agenda uploaded X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 22:49:25 -0000 --Apple-Mail=_9B00D1BE-CDA2-48BB-95C2-476302FEDE83 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 A new agenda was uploaded. Thanks to Tim to catching an error in the header, a holdover from a long = ago agenda. =97Sandy --Apple-Mail=_9B00D1BE-CDA2-48BB-95C2-476302FEDE83 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWN+ggAAoJEHplpQeet0IZ/OQP/3OWsFt7uCA9Xl5iDTMPXaiW S+rw5COj++x9e/g/RbGZiGJHehCt5tZ3M87MofT9QHHnflUUs+4UXXNbVLdmdc8k yGbsx9dObbXfpVGs8VIsle8e5V3hTGXSxVFSCz5o7TV5OCxJZwR1h/ORSIf8j3yX Uxga60sbznKupdg/oKHCuUyR3rxtpmU1PJkBBM8GVK8JqeuUiCa1CuE6bg9mtjJc G9s/P+LbdezBSQhuf/Q+TovykQTNP94boQac/7vr6eoeFssx/GHfwS3urjoqbWkf nDkwaahq1/cAhNIfpmWb69zwD7xrqJI9cx2xl/sCWpfbTAr8U7j6sSQi6BLOdNrc SlfMNYtjSjsKu3M2k97kwBUOhpTaex5rtymqdl025HWP2VjKDShFeiyz6azyMmIu 8sEGCpYlvPJj6SLCdkLuvrhYo1UXQiobrCcI3CMeg0Tk2KhjgwbZtivEfda3wMf/ g95OmWyd36V3r6DHSshGBiHqJ0efspGm2wgT7XeAZRgTnrDFOjWWpS36jMI8JcFY KqoBol+MpkjOjPTZLJ4/gOBElbCkSrGQ+YEU1cHi9T4xDF4kShKAac7jA4BFrTZq LM+SENv8z20+xjiAXnbHLD8CiwYuC5JYNjHuCv7Kr4nhtjEAnJDaxdGS90ObaGSE O0JS6BOAxUZiKB24qD8w =QU6h -----END PGP SIGNATURE----- --Apple-Mail=_9B00D1BE-CDA2-48BB-95C2-476302FEDE83-- From nobody Mon Nov 2 15:04:52 2015 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3578A1A8F41; Mon, 2 Nov 2015 15:04:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.7.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151102230451.12372.90186.idtracker@ietfa.amsl.com> Date: Mon, 02 Nov 2015 15:04:51 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-13.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 23:04:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests Authors : Mark Reynolds Sean Turner Stephen Kent Filename : draft-ietf-sidr-bgpsec-pki-profiles-13.txt Pages : 14 Date : 2015-11-02 Abstract: This document defines a standard profile for X.509 certificates used to enable validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPsec. BGP is the standard for inter-domain routing in the Internet; it is the "glue" that holds the Internet together. BGPsec is being developed as one component of a solution that addresses the requirement to provide security for BGP. The goal of BGPsec is to provide full AS path validation based on the use of strong cryptographic primitives. The end-entity (EE) certificates specified by this profile are issued (to routers within an Autonomous System). Each of these certificates is issued under a Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificate. These CA certificates and EE certificates both contain the AS Identifier Delegation extension. An EE certificate of this type asserts that the router(s) holding the corresponding private key are authorized to emit secure route advertisements on behalf of the AS(es) specified in the certificate. This document also profiles the format of certification requests, and specifies Relying Party (RP) certificate path validation procedures for these EE certificates. This document extends the RPKI; therefore, this documents updates the RPKI Resource Certificates Profile (RFC 6487). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-pki-profiles-13 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 Mon Nov 2 18:03:47 2015 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA78B1A1B56; Mon, 2 Nov 2015 18:03:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.7.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151103020345.6574.58546.idtracker@ietfa.amsl.com> Date: Mon, 02 Nov 2015 18:03:45 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-12.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 02:03:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : BGPsec Algorithms, Key Formats, & Signature Formats Author : Sean Turner Filename : draft-ietf-sidr-bgpsec-algs-12.txt Pages : 7 Date : 2015-11-02 Abstract: This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size and signature format used in BGPsec (Border Gateway Protocol Security). This document updates the Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure (draft-ietf-sidr-rfc6485bis). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-12 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 Mon Nov 2 18:07:19 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCFE1A0194 for ; Mon, 2 Nov 2015 18:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUq9ftmKzbsO for ; Mon, 2 Nov 2015 18:07:16 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::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 D36531AC437 for ; Mon, 2 Nov 2015 18:07:14 -0800 (PST) Received: by pasz6 with SMTP id z6so3390980pas.2 for ; Mon, 02 Nov 2015 18:07:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=WPnevipgjPiFKBMbm/u64ncBlsL46qYNx8eEwjckWs4=; b=ESmY50mJS53vyYfN5+99M4Z56yrdEaSG44QogcfrnGmMSiT5IYmiNIRs7q8g1QMaHa yxjRLy5o8kQHd0FYC6A/mTLfixvgRXYBTGMKdJlXb7UbZ7PSInTuI+PKXegNX46DqdPv xzeBwGenozfAdN+gW6fWAVggwQrgr7/ux1lZc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=WPnevipgjPiFKBMbm/u64ncBlsL46qYNx8eEwjckWs4=; b=WKU7os44Wim9JP7Z6FnhUZfOx4f0gv2GEVfD/CiZYfUbbqqAbqX0RI92jysfwjoqxN PR/F4g5uvtEXMwh3regKYj6lRunq7SRUDNVU6RZ6iB8yjifg9Tf3P9bYcEEac9WLYbap /HyedEy1HgtWnTaBDCXObGtnLrqZLqdYwWu0XH5UzPZWkYsUgQfxuSMoCk8hjQhXJ19x zmoxKQwoZsFpsS2gVGh7b9ipNFT5pXTXQTviwJ0XP1k9XloVjUfORW67vKvKRSksicJQ EKgh28R332xUhMiNh2mJ8W87WqQ68MZR9Wk5w/N23phQcoP+xiuZVSd9OWeqM3SiPB0Z G4lQ== X-Gm-Message-State: ALoCoQk9ZE73CdoeXSbjTWs2+mv2Tmf4NRrgQSt0vutLPFkrPddi1clqvRwj08X9ihtJHT2xPLm1 X-Received: by 10.66.156.1 with SMTP id wa1mr31034115pab.84.1446516434543; Mon, 02 Nov 2015 18:07:14 -0800 (PST) Received: from dhcp-28-27.meeting.ietf94.jp (dhcp-28-27.meeting.ietf94.jp. [133.93.28.27]) by smtp.gmail.com with ESMTPSA id zi1sm26420484pbc.10.2015.11.02.18.07.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Nov 2015 18:07:14 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Sean Turner In-Reply-To: <20151103020345.6574.58546.idtracker@ietfa.amsl.com> Date: Tue, 3 Nov 2015 11:07:10 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151103020345.6574.58546.idtracker@ietfa.amsl.com> To: sidr wg list X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-12.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 02:07:18 -0000 Incorporates comments received during WGLC. Willing to be shouted down on the tweaks in the IANA considerations = section, but I am hoping that we can move progress this version of the = document towards our AD. spt > On Nov 03, 2015, at 11:03, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Secure Inter-Domain Routing Working = Group of the IETF. >=20 > Title : BGPsec Algorithms, Key Formats, & Signature = Formats > Author : Sean Turner > Filename : draft-ietf-sidr-bgpsec-algs-12.txt > Pages : 7 > Date : 2015-11-02 >=20 > Abstract: > This document specifies the algorithms, algorithms' parameters, > asymmetric key formats, asymmetric key size and signature format = used > in BGPsec (Border Gateway Protocol Security). This document updates > the Profile for Algorithms and Key Sizes for use in the Resource > Public Key Infrastructure (draft-ietf-sidr-rfc6485bis). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-12 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-algs-12 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Mon Nov 2 18:09:07 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17621ACD55 for ; Mon, 2 Nov 2015 18:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuPBC0D_uSrX for ; Mon, 2 Nov 2015 18:09:02 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::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 61C801ACD5E for ; Mon, 2 Nov 2015 18:09:00 -0800 (PST) Received: by pacfv9 with SMTP id fv9so3592970pac.3 for ; Mon, 02 Nov 2015 18:09:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=pAB1ZZrqiTcm8GxIDY0cOBbEsAseDucxWN3k6hsPmMk=; b=KIZ7RSdmU++Bk1WpkPyduTTPmTflKcK5DVsRwjbMPo2Z02iXENvj76Vj/v0R7CVeQa xRa856apnboDB+6qQ88jPZrCa8c2dMJNFIMftMRMe2uGZy7zjjfoIv5lzCSZ2XSIg2Qh DbtoWhi+YHdDp5tEH6PG+BMmbdeHHGkLbWkSA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=pAB1ZZrqiTcm8GxIDY0cOBbEsAseDucxWN3k6hsPmMk=; b=XO6tLXboIYUn24PQ2dmzJomyHVtCf/JRwHJuCbU+4w/2rhWP50cUslsmxCwIcU9FpG b2AHnNBNdVto0rRd8TiX+0pv3s6YJvQghEy6xWtLS1gC8SXc7w98WI6Kq+QjLaoc6HqG Ef7t+Dh1YnEdLQ+GRklNV17A93BBNWxi5nOMrspwraYgcecY15k0jOw3HDLqrm33+DZC ZkUCF9M4JMXf52vFA9dfQTsz2ZzBl1TXReIUogf9Hwwsu4dV6cjKnkyKlfaHZ4zzWAto VtKaaTovb6LQZ0MNqwnEdG4Atwk0ZgCvqLJvBX91Uyh/9yxqzxkBciwvl8ptvNSQ1zEL YvBA== X-Gm-Message-State: ALoCoQlg3cxUgHPT0fnr82JPHB5+jCzaIRkfOX3cDN6JnFfPXxdvDU1WGZHrmNbxj1q9TSfpvBDm X-Received: by 10.66.253.232 with SMTP id ad8mr30523667pad.21.1446516540125; Mon, 02 Nov 2015 18:09:00 -0800 (PST) Received: from t20010c4000003024cd707f75996b6d88.v6.meeting.ietf94.jp (t20010c4000003024cd707f75996b6d88.v6.meeting.ietf94.jp. [2001:c40:0:3024:cd70:7f75:996b:6d88]) by smtp.gmail.com with ESMTPSA id ia3sm26432740pbb.5.2015.11.02.18.08.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Nov 2015 18:08:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Sean Turner In-Reply-To: <20151102230451.12372.90186.idtracker@ietfa.amsl.com> Date: Tue, 3 Nov 2015 11:08:56 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <9A0AE54E-2AF5-4242-A9B0-F8713BBEA6DD@sn3rd.com> References: <20151102230451.12372.90186.idtracker@ietfa.amsl.com> To: sidr wg list X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-13.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 02:09:04 -0000 This version incorporates comments received during WGLC. I think this one can be safely handed to our AD. spt > On Nov 03, 2015, at 08:04, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Secure Inter-Domain Routing Working = Group of the IETF. >=20 > Title : A Profile for BGPsec Router Certificates, = Certificate Revocation Lists, and Certification Requests > Authors : Mark Reynolds > Sean Turner > Stephen Kent > Filename : draft-ietf-sidr-bgpsec-pki-profiles-13.txt > Pages : 14 > Date : 2015-11-02 >=20 > Abstract: > This document defines a standard profile for X.509 certificates used > to enable validation of Autonomous System (AS) paths in the Border > Gateway Protocol (BGP), as part of an extension to that protocol > known as BGPsec. BGP is the standard for inter-domain routing in = the > Internet; it is the "glue" that holds the Internet together. BGPsec > is being developed as one component of a solution that addresses the > requirement to provide security for BGP. The goal of BGPsec is to > provide full AS path validation based on the use of strong > cryptographic primitives. The end-entity (EE) certificates = specified > by this profile are issued (to routers within an Autonomous System). > Each of these certificates is issued under a Resource Public Key > Infrastructure (RPKI) Certification Authority (CA) certificate. > These CA certificates and EE certificates both contain the AS > Identifier Delegation extension. An EE certificate of this type > asserts that the router(s) holding the corresponding private key are > authorized to emit secure route advertisements on behalf of the > AS(es) specified in the certificate. This document also profiles = the > format of certification requests, and specifies Relying Party (RP) > certificate path validation procedures for these EE certificates. > This document extends the RPKI; therefore, this documents updates = the > RPKI Resource Certificates Profile (RFC 6487). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-13 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-pki-profiles-13= >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Mon Nov 2 21:12:11 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A541B2D67 for ; Mon, 2 Nov 2015 21:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4-fiW113ODV for ; Mon, 2 Nov 2015 21:12:09 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E6C51B2E1E for ; Mon, 2 Nov 2015 21:11:32 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ZtTsY-0004WF-Bd; Tue, 03 Nov 2015 05:11:30 +0000 Date: Tue, 03 Nov 2015 14:11:29 +0900 Message-ID: From: Randy Bush To: Sean Turner In-Reply-To: References: <20151103020345.6574.58546.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-12.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 05:12:10 -0000 > Willing to be shouted down on the tweaks in the IANA considerations > section piffle. ship it randy From nobody Tue Nov 3 00:17:20 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F75C1B2F9F for ; Tue, 3 Nov 2015 00:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSQUY09Hazor for ; Tue, 3 Nov 2015 00:17:18 -0800 (PST) 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 5CA4D1B2F9B for ; Tue, 3 Nov 2015 00:17:18 -0800 (PST) Received: from minas-ithil.hactrn.net (dhcp-25-208.meeting.ietf94.jp [133.93.25.208]) (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 0CB7939812 for ; Tue, 3 Nov 2015 08:17:18 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 697161E61580 for ; Tue, 3 Nov 2015 17:17:18 +0900 (JST) Date: Tue, 03 Nov 2015 17:17:18 +0900 From: Rob Austein To: sidr@ietf.org In-Reply-To: <4F0F4923-0B80-4BA9-946A-BDC8C1486F65@tislabs.com> References: <4F0F4923-0B80-4BA9-946A-BDC8C1486F65@tislabs.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20151103081718.697161E61580@minas-ithil.hactrn.net> Archived-At: Subject: Re: [sidr] WGLCs in progress (one ends tomorrow), and other wg activity X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 08:17:19 -0000 At Tue, 20 Oct 2015 07:32:54 -0400, Sandra Murphy wrote: > > [sidr] WGLC on draft-ietf-sidr-bgpsec-algs-11 (ENDS 30-Oct-2015) > http://www.ietf.org/mail-archive/web/sidr/current/msg07341.html Just read this one. Ship it. From nobody Tue Nov 3 00:22:23 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73BD31B2F73 for ; Tue, 3 Nov 2015 00:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ue2o3E2yU8u for ; Tue, 3 Nov 2015 00:22:19 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 696A71B2F71 for ; Tue, 3 Nov 2015 00:22:19 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 55D26F2417C; Tue, 3 Nov 2015 03:22:08 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id hQ7nZAqiIS2M; Tue, 3 Nov 2015 03:20:32 -0500 (EST) Received: from dhcp-28-85.meeting.ietf94.jp (dhcp-28-85.meeting.ietf94.jp [133.93.28.85]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id A5268F24173; Tue, 3 Nov 2015 03:21:36 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <9A0AE54E-2AF5-4242-A9B0-F8713BBEA6DD@sn3rd.com> Date: Tue, 3 Nov 2015 03:21:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <44929537-2E1A-48E0-B92F-15F418100AE5@vigilsec.com> References: <20151102230451.12372.90186.idtracker@ietfa.amsl.com> <9A0AE54E-2AF5-4242-A9B0-F8713BBEA6DD@sn3rd.com> To: Sean Turner X-Mailer: Apple Mail (2.1085) Archived-At: Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-13.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 08:22:21 -0000 I just skimmed the changes, and this looks ready to go to the IESG. Russ On Nov 2, 2015, at 9:08 PM, Sean Turner wrote: > This version incorporates comments received during WGLC. >=20 > I think this one can be safely handed to our AD. >=20 > spt >=20 >> On Nov 03, 2015, at 08:04, internet-drafts@ietf.org wrote: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Secure Inter-Domain Routing Working = Group of the IETF. >>=20 >> Title : A Profile for BGPsec Router Certificates, = Certificate Revocation Lists, and Certification Requests >> Authors : Mark Reynolds >> Sean Turner >> Stephen Kent >> Filename : draft-ietf-sidr-bgpsec-pki-profiles-13.txt >> Pages : 14 >> Date : 2015-11-02 >>=20 >> Abstract: >> This document defines a standard profile for X.509 certificates used >> to enable validation of Autonomous System (AS) paths in the Border >> Gateway Protocol (BGP), as part of an extension to that protocol >> known as BGPsec. BGP is the standard for inter-domain routing in = the >> Internet; it is the "glue" that holds the Internet together. BGPsec >> is being developed as one component of a solution that addresses the >> requirement to provide security for BGP. The goal of BGPsec is to >> provide full AS path validation based on the use of strong >> cryptographic primitives. The end-entity (EE) certificates = specified >> by this profile are issued (to routers within an Autonomous System). >> Each of these certificates is issued under a Resource Public Key >> Infrastructure (RPKI) Certification Authority (CA) certificate. >> These CA certificates and EE certificates both contain the AS >> Identifier Delegation extension. An EE certificate of this type >> asserts that the router(s) holding the corresponding private key are >> authorized to emit secure route advertisements on behalf of the >> AS(es) specified in the certificate. This document also profiles = the >> format of certification requests, and specifies Relying Party (RP) >> certificate path validation procedures for these EE certificates. >> This document extends the RPKI; therefore, this documents updates = the >> RPKI Resource Certificates Profile (RFC 6487). >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-13 >>=20 >> A diff from the previous version is available at: >> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-pki-profiles-13= >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Tue Nov 3 00:28:43 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7340B1A1A96 for ; Tue, 3 Nov 2015 00:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2ZmYhcBU915 for ; Tue, 3 Nov 2015 00:28:41 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id D74D51A1A94 for ; Tue, 3 Nov 2015 00:28:40 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 44685F24173; Tue, 3 Nov 2015 03:28:30 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id zwv-aDoQNuWV; Tue, 3 Nov 2015 03:26:55 -0500 (EST) Received: from dhcp-28-85.meeting.ietf94.jp (dhcp-28-85.meeting.ietf94.jp [133.93.28.85]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id B63D9F24171; Tue, 3 Nov 2015 03:27:59 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Tue, 3 Nov 2015 03:27:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151103020345.6574.58546.idtracker@ietfa.amsl.com> To: Sean Turner X-Mailer: Apple Mail (2.1085) Archived-At: Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-12.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 08:28:42 -0000 I just reviewed the changes, and I think this is ready to go to the = IESG. Russ On Nov 2, 2015, at 9:07 PM, Sean Turner wrote: > Incorporates comments received during WGLC. >=20 > Willing to be shouted down on the tweaks in the IANA considerations = section, but I am hoping that we can move progress this version of the = document towards our AD. >=20 > spt >=20 >> On Nov 03, 2015, at 11:03, internet-drafts@ietf.org wrote: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Secure Inter-Domain Routing Working = Group of the IETF. >>=20 >> Title : BGPsec Algorithms, Key Formats, & Signature = Formats >> Author : Sean Turner >> Filename : draft-ietf-sidr-bgpsec-algs-12.txt >> Pages : 7 >> Date : 2015-11-02 >>=20 >> Abstract: >> This document specifies the algorithms, algorithms' parameters, >> asymmetric key formats, asymmetric key size and signature format = used >> in BGPsec (Border Gateway Protocol Security). This document updates >> the Profile for Algorithms and Key Sizes for use in the Resource >> Public Key Infrastructure (draft-ietf-sidr-rfc6485bis). >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-12 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-algs-12 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Tue Nov 3 01:21:23 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36231B30B6; Tue, 3 Nov 2015 01:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOXEmbtpVxj8; Tue, 3 Nov 2015 01:21:21 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (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 9A3AC1B30B5; Tue, 3 Nov 2015 01:21:21 -0800 (PST) Received: by ykba4 with SMTP id a4so9486106ykb.3; Tue, 03 Nov 2015 01:21:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=3f3HeV1eIthbhlfmxAumYyInwbHoXNQVhCtsjtiAEuM=; b=XD69K35J2AVdcLomvTxipQET+ETyRuiboEpZrDNtKwzBrjyYS8QUOaocUn7GQzaXAU ih9pBzPXea+MrbjvLoC0KcNRuODObkM04xhs5PUmLsd8a5os4FRh1mrfLG/TUu9VCXPU +NUzo8oQaSXOD0en0d8m8QXbk5+M9R9q9AoTdTuB6sIHEIjNR2uxp5C1q1Upnki1F+TX AzmghtYHbAz1Smnd+FKnPPpV8MgAo043KSsry94iLxIikpdumw3Bt/Ge08XdN/MqedPb /AyS4OhUvSfAnZRVaVPR1fm29bcm+yBDPegzqVd0QRXwiilKKWIbvXX3HeSSO9Q9mGWf fGvg== MIME-Version: 1.0 X-Received: by 10.129.82.18 with SMTP id g18mr19908375ywb.234.1446542480995; Tue, 03 Nov 2015 01:21:20 -0800 (PST) Received: by 10.13.202.16 with HTTP; Tue, 3 Nov 2015 01:21:20 -0800 (PST) Date: Tue, 3 Nov 2015 20:21:20 +1100 Message-ID: From: Christopher Morrow To: "sidr@ietf.org" , "sidr-ads@tools.ietf.org" , "sidr-chairs@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [sidr] Validation reconsidered draft status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 09:21:22 -0000 During the meeting today (tues 11/3/2015) one of the authors of: draft-ietf-sidr-rpki-validation-reconsidered noted that after the last set of updates and over the history of the document (2+yrs) there's been no real support nor direction from the working-group. Additionally, all co-authors noted that the lack of support and direction meant that abandoning the draft seemed like the best current direction. The primary author: Geoff Huston (gih@apnic.net) is willing to toss the XML over the fence to another author/editor if there is interest, or to let the draft expire/die if no one is willing to take up the pencil. Over the next three weeks let's discuss the direction/end-goal and determine if 'abandon' or 'new author' is the best course of action here. -chris sidr-co-chair From nobody Tue Nov 3 07:04:51 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DA01A1BB0 for ; Tue, 3 Nov 2015 07:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGLfbTxUu_HK for ; Tue, 3 Nov 2015 07:04:48 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 067991A1B65 for ; Tue, 3 Nov 2015 07:04:38 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:44885 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Ztd8V-000BEU-RD for sidr@ietf.org; Tue, 03 Nov 2015 10:04:35 -0500 To: sidr From: Stephen Kent Message-ID: <5638CD03.3070509@bbn.com> Date: Tue, 3 Nov 2015 10:04:35 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sidr] draft-ietf-sidr-bgpsec-algs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 15:04:49 -0000 I reviewed this doc and sent a few editorial changes to Sean. With those changes, I think it's ready to go. Steve From nobody Tue Nov 3 14:10:12 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B01D1B2AF1 for ; Tue, 3 Nov 2015 14:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IXHASH_X1=1.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwXSwbhuR7s7 for ; Tue, 3 Nov 2015 14:10:09 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 160681B2AF0 for ; Tue, 3 Nov 2015 14:10:09 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:37509 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZtjmJ-000LUJ-8W for sidr@ietf.org; Tue, 03 Nov 2015 17:10:07 -0500 To: sidr From: Stephen Kent Message-ID: <563930BF.8090009@bbn.com> Date: Tue, 3 Nov 2015 17:10:07 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sidr] BGPsec overview X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 22:10:10 -0000 I reviewed this document and suggested a number of editorial changes to the authors. Other than these changes, I think this document is ready. Steve From nobody Tue Nov 3 14:38:26 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F7C1B2D1E for ; Tue, 3 Nov 2015 14:38:24 -0800 (PST) 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=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oz2TL0IoLucp for ; Tue, 3 Nov 2015 14:38:23 -0800 (PST) Received: from nm4.access.bullet.mail.bf1.yahoo.com (nm4.access.bullet.mail.bf1.yahoo.com [216.109.114.56]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67BBE1B2CE9 for ; Tue, 3 Nov 2015 14:38:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1446590302; bh=JyPkHlX4jQZ7Wy7pCV+4pF+LtWSHrq9d+M85c714/j4=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject; b=BNkB8tP5tVsCTU2jxT4wiJA48ROfH04/HUdlqPBkJeAUnvht+36tyjhG6h0caKqhu/v3lciLJvoqY8BG+fnlwihzZPP6+ZZFwNJ+yqRujtw5TsQx4EmwXmnVkH+P+ZLVMMbJLIjl7aOjF6MU/iizo1tndlW17WwVbez1Bvqv0q9pfNls/Ljj7lzT+vY13BvQBZnYyqYOYyHacjo62ZZnTESRHvJa0MaApDCXirRiCXyt9WbQA2Sw1TPNYZ/6/GuiooMCLdMz/P0z75BJc9yTV5zvWd/m9NZ+d6NS5UuZotbhC7p5FMaUwnUN+9XpJ4ZdD1C3ZvAxXLjZU6rGR8iusQ== Received: from [66.196.81.160] by nm4.access.bullet.mail.bf1.yahoo.com with NNFMP; 03 Nov 2015 22:38:22 -0000 Received: from [98.138.226.240] by tm6.access.bullet.mail.bf1.yahoo.com with NNFMP; 03 Nov 2015 22:38:22 -0000 Received: from [127.0.0.1] by smtp111.sbc.mail.ne1.yahoo.com with NNFMP; 03 Nov 2015 22:38:22 -0000 X-Yahoo-Newman-Id: 317427.54530.bm@smtp111.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: kycDwQ0VM1mjIffeSBecIU3KePwBK1B1C6V.xezPEKt.mt. zfB4wA2UBXeahTTH5LuoKijJEiDJU5F3xMLMVT9x8k9rDJpU_H12gv5llUWg 2fHyT3ubt17BNk0XnUq7CicyGniJJSyOtok_xuh2V12Fkgd2slcpDjD7SwdB Nr3mPnYjZFxgJluKqddkCxceBV6pdqVecirnrk_rbONFFeqpaYvmlDhxudtz jOZdqYvxMCWrUTfSalJ0G80PW70i9B3P9ygHt_OdmYt4GJ1pw_H9ZIDP2DSF aFZ4f5aEAQILy6jl8ukjy2.cRgZy.0k4hSyEapZrLUeT9Summ3IuR6YTabEJ cpnEYFzQKM66VenKdt6x0WiS4xsASc_nFDboIqwtzDV_Vr3KsJK3XDy3oeMo nEJOAaAWlIibup1P6djrzcY22s4iasc1uWTDmaTEGnwSx_rut5ezlwhM4gKj yLjDFwogqMwZn99o60uZMxiHMZ4ixvuVtsoK7qStFBjK4_wo7ZOVmGxbDVe6 59i7V3u8UtFaf9fek0Dq39QQcUN4- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id DE3721C6035 for ; Tue, 3 Nov 2015 17:38:20 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 03 Nov 2015 17:38:20 -0500 From: David Mandelberg To: In-Reply-To: References: <20151103020345.6574.58546.idtracker@ietfa.amsl.com> Message-ID: <3c6df83bacce0bc32f6a436767c56984@mail.mandelberg.org> X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-12.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 22:38:25 -0000 Thanks, this addresses all the (minor) comments I sent off-list during WGLC. And since I realized I hadn't remembered to publicly support this, I'll do so now: it looks good to me. On 2015-11-02 21:07, Sean Turner wrote: > Incorporates comments received during WGLC. > > Willing to be shouted down on the tweaks in the IANA considerations > section, but I am hoping that we can move progress this version of > the > document towards our AD. > > spt > >> On Nov 03, 2015, at 11:03, internet-drafts@ietf.org wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Secure Inter-Domain Routing Working >> Group of the IETF. >> >> Title : BGPsec Algorithms, Key Formats, & Signature >> Formats >> Author : Sean Turner >> Filename : draft-ietf-sidr-bgpsec-algs-12.txt >> Pages : 7 >> Date : 2015-11-02 >> >> Abstract: >> This document specifies the algorithms, algorithms' parameters, >> asymmetric key formats, asymmetric key size and signature format >> used >> in BGPsec (Border Gateway Protocol Security). This document >> updates >> the Profile for Algorithms and Key Sizes for use in the Resource >> Public Key Infrastructure (draft-ietf-sidr-rfc6485bis). >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-12 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-12 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Tue Nov 3 14:55:34 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D845F1B3401 for ; Tue, 3 Nov 2015 14:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RB3tEv0SS2lP for ; Tue, 3 Nov 2015 14:55:32 -0800 (PST) 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 0DE381B33B4 for ; Tue, 3 Nov 2015 14:55:32 -0800 (PST) Received: from minas-ithil.hactrn.net (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp [153.220.164.231]) (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 F180A39834 for ; Tue, 3 Nov 2015 22:55:30 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 0D6FC1E6380C for ; Wed, 4 Nov 2015 07:55:32 +0900 (JST) Date: Wed, 04 Nov 2015 07:55:32 +0900 From: Rob Austein To: sidr@ietf.org MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20151103225532.0D6FC1E6380C@minas-ithil.hactrn.net> Archived-At: Subject: [sidr] draft-ietf-sidr-bgpsec-pki-profiles-12 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 22:55:33 -0000 Just reviewed draft-ietf-sidr-bgpsec-pki-profiles-12 (again). Not only does it look OK, it looks like what I implemented. Ship it. From nobody Tue Nov 3 22:54:16 2015 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 783AF1AD067; Tue, 3 Nov 2015 22:54:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.8.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151104065412.5003.67926.idtracker@ietfa.amsl.com> Date: Tue, 03 Nov 2015 22:54:12 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-14.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 06:54:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests Authors : Mark Reynolds Sean Turner Stephen Kent Filename : draft-ietf-sidr-bgpsec-pki-profiles-14.txt Pages : 14 Date : 2015-11-03 Abstract: This document defines a standard profile for X.509 certificates used to enable validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPsec. BGP is the standard for inter-domain routing in the Internet; it is the "glue" that holds the Internet together. BGPsec is being developed as one component of a solution that addresses the requirement to provide security for BGP. The goal of BGPsec is to provide full AS path validation based on the use of strong cryptographic primitives. The end-entity (EE) certificates specified by this profile are issued (to routers within an Autonomous System). Each of these certificates is issued under a Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificate. These CA certificates and EE certificates both contain the AS Identifier Delegation extension. An EE certificate of this type asserts that the router(s) holding the corresponding private key are authorized to emit secure route advertisements on behalf of the AS(es) specified in the certificate. This document also profiles the format of certification requests, and specifies Relying Party (RP) certificate path validation procedures for these EE certificates. This document extends the RPKI; therefore, this documents updates the RPKI Resource Certificates Profile (RFC 6487). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-pki-profiles-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 3 23:53:48 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307311B2ADD for ; Tue, 3 Nov 2015 23:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AK-p7vohpGcz for ; Tue, 3 Nov 2015 23:53:46 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::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 69CFD1B2A63 for ; Tue, 3 Nov 2015 23:53:46 -0800 (PST) Received: by padhx2 with SMTP id hx2so37596190pad.1 for ; Tue, 03 Nov 2015 23:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=/MlSRjUEWwt/Emy7Q1DJRl52P3iYbaNm1ajWD8bk2iQ=; b=c/zkp023+rvXD/BqpfrbKgJwCgcm/ZTngZmL9qHVX8MnhV2sErisgWu+mHDt6wO/r6 KywbZYvi9RxORX+zMB7ABjKtKerK8+7kBU26vS3EyN+QeecvA8+wSj7zo1xJrkmzzpLs H+EQs7AePZAC8dNfGRLQdXK0HadilhF/eTOSA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=/MlSRjUEWwt/Emy7Q1DJRl52P3iYbaNm1ajWD8bk2iQ=; b=W7Jve+N26lEaYxma0cUi3q69x/JewPT6Ctj6OufTq6s7iRrxXGgXAhP/5hqUIcrmY6 sqWV/cvPHjxsuPZjamGfacm0SXlvmBhN+vznVPv7vEnjXK6ItFdOul1KsA//PTXowS22 U+eQOewUS6uWcOBvitJoz/NceFxXAP4RgepYTL+VCtJiZFdhEWYd/827Xmd+DnYcatVC v6JZs4qkUNSdaI5kuVp1AuI8aX+FymMCJks8rjR+msNy7bt0SRFxXFTLOFov9aPChzWM 2VHFKreHINsOdI0jCKp8moz5ZmQtLVFtg08RXIP7yKHx95R3P4rEYdBFltq2TMDYiJvj 2CHA== X-Gm-Message-State: ALoCoQkRJzKjsL8XkhY2ODOJ0FiQ8+d+vV3FNXpfoUF6eVgz1HogG0ryfYkmdJ9ABibAMDAQ+58b X-Received: by 10.67.5.164 with SMTP id cn4mr68296pad.141.1446623626044; Tue, 03 Nov 2015 23:53:46 -0800 (PST) Received: from dhcp-28-27.meeting.ietf94.jp (dhcp-28-27.meeting.ietf94.jp. [133.93.28.27]) by smtp.gmail.com with ESMTPSA id k5sm197515pbq.74.2015.11.03.23.53.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Nov 2015 23:53:45 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Sean Turner In-Reply-To: <20151104065412.5003.67926.idtracker@ietfa.amsl.com> Date: Wed, 4 Nov 2015 16:53:44 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <4DBB60F2-1947-4098-A765-712929DCF53F@sn3rd.com> References: <20151104065412.5003.67926.idtracker@ietfa.amsl.com> To: sidr wg list X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-14.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 07:53:48 -0000 WG chair review turned up that for some reason an earlier version got = switched to BCP. I=E2=80=99ve got no record of why and since we=E2=80=99r= e updating 6485bis that=E2=80=99s standards track - I switched it back. spt > On Nov 04, 2015, at 15:54, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Secure Inter-Domain Routing Working = Group of the IETF. >=20 > Title : A Profile for BGPsec Router Certificates, = Certificate Revocation Lists, and Certification Requests > Authors : Mark Reynolds > Sean Turner > Stephen Kent > Filename : draft-ietf-sidr-bgpsec-pki-profiles-14.txt > Pages : 14 > Date : 2015-11-03 >=20 > Abstract: > This document defines a standard profile for X.509 certificates used > to enable validation of Autonomous System (AS) paths in the Border > Gateway Protocol (BGP), as part of an extension to that protocol > known as BGPsec. BGP is the standard for inter-domain routing in = the > Internet; it is the "glue" that holds the Internet together. BGPsec > is being developed as one component of a solution that addresses the > requirement to provide security for BGP. The goal of BGPsec is to > provide full AS path validation based on the use of strong > cryptographic primitives. The end-entity (EE) certificates = specified > by this profile are issued (to routers within an Autonomous System). > Each of these certificates is issued under a Resource Public Key > Infrastructure (RPKI) Certification Authority (CA) certificate. > These CA certificates and EE certificates both contain the AS > Identifier Delegation extension. An EE certificate of this type > asserts that the router(s) holding the corresponding private key are > authorized to emit secure route advertisements on behalf of the > AS(es) specified in the certificate. This document also profiles = the > format of certification requests, and specifies Relying Party (RP) > certificate path validation procedures for these EE certificates. > This document extends the RPKI; therefore, this documents updates = the > RPKI Resource Certificates Profile (RFC 6487). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-14 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-pki-profiles-14= >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Nov 4 03:18:43 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5171B2D9C for ; Wed, 4 Nov 2015 03:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnDif1LOr9Pj for ; Wed, 4 Nov 2015 03:18:39 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0702.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::702]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B56C1AD0C2 for ; Wed, 4 Nov 2015 03:18:38 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.185.87.133) by DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) with Microsoft SMTP Server (TLS) id 15.1.318.15; Wed, 4 Nov 2015 11:18:19 +0000 Message-ID: <05b401d116f2$5df837a0$4001a8c0@gateway.2wire.net> From: t.petch To: Sean Turner , sidr wg list References: <20151103020345.6574.58546.idtracker@ietfa.amsl.com> Date: Wed, 4 Nov 2015 11:14:34 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.87.133] X-ClientProxiedBy: HE1PR05CA0071.eurprd05.prod.outlook.com (25.164.28.39) To DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB064; 2:nsYaohmuYhvewmURQQ1296YTONWFVaLgu8j4CT0d8CKaiQNiFnFmtxLbfJmM7anbdu1aMv86kr1+RQ/CUU20uCGwgMctKP57r2R/QBOzpTm/7KvO+7vqUC9x3olEYRMDeS1MxyYh1tuMTYj/A820mRMEoywPxmwqLGxg6gEwlVA=; 3:hK/6MIPko4GGRN7tOqXgwyEwvOC1Ls1Fq58QepXfuTpyh3HdeE3wYo8wrnw6Aju9WueYg39T/s078WBvwixsUGt8NRwoSEKcPMNfJoJrUJH03gzXfEMPoTBxn487+VSpVAWBX18ZoB4cM+FSbfJBVg==; 25:cflpXyxyxgoXhnrB/3ZWGZxeZjnCHiVbhOt/u1Oki3zXWzI6UVmcGqO2gGNHMHDdoiNsdwYk5JJXYQ0cmunix6HaJf19/nwtSCl+DFOuXrpdj5UOlJRdgVNrxvX8zhUjX/Lf1xnwzVdH0Azehi3+juS0ffFH0kQakMOMWQWIc/tv5oWgMNt+1pAHjq34l9b17yYvBZa9phymDUHpFwS5EtJGgK8aAVbuZZhcHDox6Kw70B6KQf2JO9ZivrU85vZ00tvmJ5Q0aSfGLgXsisxJuw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB064; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(10201501046); SRVR:DBXPR07MB064; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB064; X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB064; 4:GKCR8PWpToPK+NNsa/7E/5W1BnCQA64dmJ9Jb9a6jgMbi7t7+YwD5QOHl5KzYKkTU3rYtt/1adRJFDFxCE4/3VIIrR+Kkg5kzPSSj3FRQESf3eP7kYqEcZwcK/lQwcKryUvl1zUpt3DhM4QNJE3O28E45lme+cT0IBYr1i98SEcCNbjxnasP8xd1wowUGEIM+bVsxksDiCL0KblTNVOJeP8zuDw/TBOw49oCo46dhcGDbBmO2jrU+qtmT7w/0OjEhgLNhr1KCeF8Jy/5sJbpOFDx2Hvi0UkW13B/BUDeIyoDa9iHx4yyhzlhdwA4pazb+b5NSI5KVq3KyiyUDzMxwxD7Fcn+NXyDXpUOGy6CkddQSlKqm1QD6g4nLA8wfC/8 X-Forefront-PRVS: 0750463DC9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(189002)(24454002)(199003)(13464003)(377454003)(5001960100002)(40100003)(107886002)(189998001)(92566002)(122386002)(1456003)(15975445007)(81156007)(5001770100001)(5008740100001)(77096005)(50466002)(230700001)(97736004)(44736004)(1556002)(62236002)(50226001)(116806002)(84392001)(19580405001)(106356001)(44716002)(87976001)(105586002)(19580395003)(230783001)(50986999)(66066001)(76176999)(5004730100002)(14496001)(33646002)(101416001)(81686999)(47776003)(5007970100001)(81816999)(42186005)(23756003)(86362001)(61296003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB064; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DBXPR07MB064; 23:Mkv2K+gM5W0rpHvihNWhzOVo9AyBN0E+K9vEl2wS?= =?iso-8859-1?Q?T3F3t9un4Stk0XDzGzsUugHSCH7onSA9bHyXzVKG+INm5MparCkQSJury3?= =?iso-8859-1?Q?K2Qdh6YfF0ok6gTHTi0sLbdwn7L7aq0ZGQeI2R0n6nCKEWauRMpWMP7Acw?= =?iso-8859-1?Q?hZ3BkAlHHsadn0QLZeiITR2klgjo8fegWcourFfFcmJCDy+q35ACj/bk4u?= =?iso-8859-1?Q?cZsjbLFCoCw2HhjDBJWtKM/UdGlGZtuC+zLtwpDfFcUZM6qnSMxsMC8ICA?= =?iso-8859-1?Q?g2hHwU0VasOv098kJHEx/qN7uNIk7HTuJlbmcYWrCtet/oruF/8WCuwHB7?= =?iso-8859-1?Q?u4beKihj2d03hFZhfXvlpPyq2pQgOsWjIQHF/YV7Phd9/0nR+oWt9+fWao?= =?iso-8859-1?Q?YXx6/1A3XefLObdNlVQ+HR8BoVNBpLqyvPu9JKCoAy9d6m3Xqk5pjZjor6?= =?iso-8859-1?Q?3Wy5SDpYKZsiyEz3Y67oiHAEceQNSsCinD4vhI0inM04dSnZp12YlyQzTV?= =?iso-8859-1?Q?k8ctW3qZu/JsFa4H5P/3E7mgaGfcQ/CFNStXzeQuA588UDn3hal7Be669y?= =?iso-8859-1?Q?B0JOrwDs1ZWX1HtphCPJRbkdRcj79yd6sXS11lBX9AQiWmlo9vlc2KDC3c?= =?iso-8859-1?Q?k0nWraZXCCevQCd7VpS41kkNYkjOg+v3MdKA7SI4TtDEPQUlSVwUVuGCun?= =?iso-8859-1?Q?TBGH/DEMua3DzKoB+ClZ9Vcn+eMPppmFS3qZO+N/NphD+RoaEZvj1xxs17?= =?iso-8859-1?Q?k2iu5yP1AsDBN1An97lu+9Cn/4C9r7qbOlniyGTYhWqACXOFHCRjh3qDZb?= =?iso-8859-1?Q?Q4V0zyZ/1hQornX9cI8rLWuOOokNLTwLJbTsgSJjRB+kl7D+lzIKxdCNr1?= =?iso-8859-1?Q?rW4NQ39kFIB+FfRwRqkzOwlky5lDU0RaMcxLrU2kG9XrOu+q3/V/kRhIPl?= =?iso-8859-1?Q?dnHmUYSTXUX6rGC+rJ7BMQGbamr31HLjg/t25jN3RMG8+CmsW5GdT/HnJP?= =?iso-8859-1?Q?XtfZvKhRCx7zUx+d+TO0fvTULr/X05Wa6OvG4NFjuR+z0zsaJLarpBa4AZ?= =?iso-8859-1?Q?nO6Yl5B1PzLHmfsRJtgBh5sf8XgrJ/KXfLsWuD1jxqe4aTE9GlVQCqIDWF?= =?iso-8859-1?Q?h+rjf5WOOSzpgfhnNr6TJ+O1hG28ZSFhGIJanpE19qgHyZBXOn1ULvo2tP?= =?iso-8859-1?Q?xDV1Pw9ckjhXtzDDjnNcjsKlFCuOPhKG3uM1V/4xWXjWdUifdIFSq4LoSa?= =?iso-8859-1?Q?iignlX8DJNgGrjX4Kr2mppB3opGXEVXHMkzjxb8Fd4+gWloVT+rBcUZHIv?= =?iso-8859-1?Q?Yv99RxnWAMtKgPmqA4cwg5nlXFJesoBzP5FArilFupS0az7GQhynrT3Ite?= =?iso-8859-1?Q?maKU1GCijLtVJnEIQ3Vr37g2c0Qa?= X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB064; 5:/hCcUgh0IVQz7IgK40i7ePMHZjlx/+iTLqrLJJqWCSqlDQqYD5a1AnUPGum48xM6d5c7OmMqhvyOfRvRNDZNmxOuAtiMeRE1WMW1EVGuP5uIq+PeThAToDBHJzASf47ZyNFk5qQvB91YfdNOGtIRkw==; 24:zJHab8dPkcP8FVkvpFqllzJP9y6Occvec+567hJ7jx5m7m7AJ4XNJJn/rxQBSsqoHhip6VfQdgZpcksivuA30dcWqKGNCHM9pxcQt/NgPRw=; 20:kUPDaGH6tG0tDjOMPYmcBHhVeWcYYsLbr9P+fp1Y2wU3FN/oRHHI3lIWj1B4r+aSSB6uWS2qFq43cxf68wVjUA== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Nov 2015 11:18:19.0385 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB064 Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-12.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 11:18:41 -0000 ----- Original Message ----- From: "Sean Turner" To: "sidr wg list" Sent: Tuesday, November 03, 2015 2:07 AM > Incorporates comments received during WGLC. > > Willing to be shouted down on the tweaks in the IANA considerations section, but I am hoping that we can move progress this version of the document towards our AD. Sean More a gentle nudge than a shout. draft-leiba-cotton-iana-5226bis-11 introduces the idea of a registry being within a group and this I-D makes no mention of the latter. Is the intent to have a new BGPsec Group, slotting in between Battery Technologies and BFD, or is it part of the existing RPKI Group? I suggest making that explicit in the IANA Considerations. And to make the IANA Considerations complete of themselves, since they get extracted onto a web site, should there be a reference to the constraints imposed on the algorithms in section two i.e. the two algorithms to be registered must be as specified in rfc6485bis? An rfc6485ter would then have to have IANA Considerations to update that part but I expect we would remember to do that. Tom Petch > > spt > > > On Nov 03, 2015, at 11:03, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. > > > > Title : BGPsec Algorithms, Key Formats, & Signature Formats > > Author : Sean Turner > > Filename : draft-ietf-sidr-bgpsec-algs-12.txt > > Pages : 7 > > Date : 2015-11-02 > > > > Abstract: > > This document specifies the algorithms, algorithms' parameters, > > asymmetric key formats, asymmetric key size and signature format used > > in BGPsec (Border Gateway Protocol Security). This document updates > > the Profile for Algorithms and Key Sizes for use in the Resource > > Public Key Infrastructure (draft-ietf-sidr-rfc6485bis). > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-12 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-12 > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Wed Nov 4 06:23:53 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D631B305F; Wed, 4 Nov 2015 06:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CW7dR3zmNxi3; Wed, 4 Nov 2015 06:23:51 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (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 E6ADE1B305A; Wed, 4 Nov 2015 06:23:49 -0800 (PST) Received: by ykdr3 with SMTP id r3so73926648ykd.1; Wed, 04 Nov 2015 06:23:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Txtgzm4JQTeWqtusxw07PbzbNrOiqP4rnAGCaQTqQV8=; b=oPHkg/HVEPDU2L1EKx7Q2jb8+EfDAPcp4r1lPBehhBjenYm4Njckq43zQS9HVIjB7A zPBRmEbc9L7DWVqCxmNIii4RgEQmWakKnazePLTIXK6xOlOlENK9gCuliaWIR/e+wpJY 8CMEgofc2eifzgPSi0xlbCA6KPBOr0odGLiX4zWRa8ZxuTt2V1s7Q+NCHGXXLZYSC9kc HmsKlgJXl7sd+smRVRhUAVb0vttbwrIktCQD9NSsQrq66tZcTso+RNC4mF99cEupYR1E A4RBLUqdKxJhoUosXCTPCkxuHPPPgu2oW+edQCe6M2oF4YOjCyHTfKSnL0q+VawuT0J8 c7sg== MIME-Version: 1.0 X-Received: by 10.129.71.6 with SMTP id u6mr1653828ywa.247.1446647029231; Wed, 04 Nov 2015 06:23:49 -0800 (PST) Received: by 10.13.202.16 with HTTP; Wed, 4 Nov 2015 06:23:49 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Nov 2015 01:23:49 +1100 Message-ID: From: Christopher Morrow To: "sidr@ietf.org" , "sidr-ads@tools.ietf.org" , "sidr-chairs@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sidr] Validation reconsidered draft status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 14:23:53 -0000 hurray! ambiguity in questions was raised by an interested party... I'd rather do this Friday at the end of the meeting with a short presentation/conversation. -chris On Tue, Nov 3, 2015 at 8:21 PM, Christopher Morrow wrote: > During the meeting today (tues 11/3/2015) one of the authors of: > draft-ietf-sidr-rpki-validation-reconsidered > > noted that after the last set of updates and over the history of the > document (2+yrs) there's been no real support nor direction from the > working-group. Additionally, all co-authors noted that the lack of > support and direction meant that abandoning the draft seemed like the > best current direction. > > The primary author: Geoff Huston (gih@apnic.net) is willing to toss > the XML over the fence to another author/editor if there is interest, > or to let the draft expire/die if no one is willing to take up the > pencil. > > Over the next three weeks let's discuss the direction/end-goal and > determine if 'abandon' or 'new author' is the best course of action > here. > > -chris > sidr-co-chair From nobody Wed Nov 4 15:15:25 2015 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 378D41B379F; Wed, 4 Nov 2015 15:15:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.8.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151104231524.15805.94393.idtracker@ietfa.amsl.com> Date: Wed, 04 Nov 2015 15:15:24 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-15.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 23:15:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests Authors : Mark Reynolds Sean Turner Stephen Kent Filename : draft-ietf-sidr-bgpsec-pki-profiles-15.txt Pages : 13 Date : 2015-11-04 Abstract: This document defines a standard profile for X.509 certificates used to enable validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPsec. BGP is the standard for inter-domain routing in the Internet; it is the "glue" that holds the Internet together. BGPsec is being developed as one component of a solution that addresses the requirement to provide security for BGP. The goal of BGPsec is to provide full AS path validation based on the use of strong cryptographic primitives. The end-entity (EE) certificates specified by this profile are issued (to routers within an Autonomous System). Each of these certificates is issued under a Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificate. These CA certificates and EE certificates both contain the AS Identifier Delegation extension. An EE certificate of this type asserts that the router(s) holding the corresponding private key are authorized to emit secure route advertisements on behalf of the AS(es) specified in the certificate. This document also profiles the format of certification requests, and specifies Relying Party (RP) certificate path validation procedures for these EE certificates. This document extends the RPKI; therefore, this documents updates the RPKI Resource Certificates Profile (RFC 6487). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-pki-profiles-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 4 15:21:21 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92AD1B37EE for ; Wed, 4 Nov 2015 15:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7g6JUTiq3da for ; Wed, 4 Nov 2015 15:21:16 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (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 A24921B37E0 for ; Wed, 4 Nov 2015 15:21:16 -0800 (PST) Received: by pacdm15 with SMTP id dm15so42214868pac.3 for ; Wed, 04 Nov 2015 15:21:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=E7f2k/s2XJu5IT6h6qwFD3sBPS7+zirmt3xAw9e0fGQ=; b=VFx+MHkTusdtRlLaWn/3Sc2pZ2fBhF6eFhXaL4zBtX0ihjcC8YMw+Pe/cnHVFy0KaL 0hm1xUriwTi4GxcyqjFvkcte/jaAJh+h2rxt8rFNKkInvmjdM8A9czVzhZhK3Tp0QywI MrVACfolwKIdxmegmHAAz8s4ics5+YP6HcMXo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=E7f2k/s2XJu5IT6h6qwFD3sBPS7+zirmt3xAw9e0fGQ=; b=ke4u+Vp5fRvXDRdL+HDmCL/H8edzd6jsiF9SqetQL233Gq/Fj2Ib+TyDCQ1rVyhqTn 9GMk45x+e60sNEHjr6abCWtTGn4nLcvCNBVamof1q7M77i3ExvJAk4hzbox5WYqJyyyx 3najT5mm+tBoO8U9Ot21+CrP3s9AXdnpgFGCG2mrxxJPbmBdKbmeniQo7nXIuRZe14p9 JDvF+4iszNISAijWKPvh5qYtIYL5951XesPcPnfObVWQs3dVs3SsMySpU5g/Gzz/3j21 TE7ojwYR+/RJ7evPZ5AahfqSinFMh8U6rm8gCcjIEZ1aqAfshkp4XiXJksI1ErO/3NKq Burw== X-Gm-Message-State: ALoCoQnvgNsXyAmTjQbtufkJiLanuS+Olo+dEpM3G6zg7j0Ao+DVZwhfUnKu4nvCEM0jOxtwEw/P X-Received: by 10.67.30.168 with SMTP id kf8mr4650250pad.106.1446679276239; Wed, 04 Nov 2015 15:21:16 -0800 (PST) Received: from [10.71.2.205] ([101.110.53.38]) by smtp.gmail.com with ESMTPSA id qc16sm4019157pab.47.2015.11.04.15.21.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 15:21:15 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Sean Turner In-Reply-To: <20151104231524.15805.94393.idtracker@ietfa.amsl.com> Date: Thu, 5 Nov 2015 08:21:13 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <5A9CD8E6-8459-4E6B-914B-E2F87EE4AC05@sn3rd.com> References: <20151104231524.15805.94393.idtracker@ietfa.amsl.com> To: sidr wg list X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-15.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 23:21:20 -0000 tl;dr: new versions since -13 to address editorial comments - changed = from BCP to standards track Sandy noted that a some point this draft switched the BCP. For the life = of me, I can=E2=80=99t remember the rationale for that changed = especially since this draft is updating a standards track RFC. I = changed the intended track to the more defensible standards track. spt > On Nov 05, 2015, at 08:15, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Secure Inter-Domain Routing Working = Group of the IETF. >=20 > Title : A Profile for BGPsec Router Certificates, = Certificate Revocation Lists, and Certification Requests > Authors : Mark Reynolds > Sean Turner > Stephen Kent > Filename : draft-ietf-sidr-bgpsec-pki-profiles-15.txt > Pages : 13 > Date : 2015-11-04 >=20 > Abstract: > This document defines a standard profile for X.509 certificates used > to enable validation of Autonomous System (AS) paths in the Border > Gateway Protocol (BGP), as part of an extension to that protocol > known as BGPsec. BGP is the standard for inter-domain routing in = the > Internet; it is the "glue" that holds the Internet together. BGPsec > is being developed as one component of a solution that addresses the > requirement to provide security for BGP. The goal of BGPsec is to > provide full AS path validation based on the use of strong > cryptographic primitives. The end-entity (EE) certificates = specified > by this profile are issued (to routers within an Autonomous System). > Each of these certificates is issued under a Resource Public Key > Infrastructure (RPKI) Certification Authority (CA) certificate. > These CA certificates and EE certificates both contain the AS > Identifier Delegation extension. An EE certificate of this type > asserts that the router(s) holding the corresponding private key are > authorized to emit secure route advertisements on behalf of the > AS(es) specified in the certificate. This document also profiles = the > format of certification requests, and specifies Relying Party (RP) > certificate path validation procedures for these EE certificates. > This document extends the RPKI; therefore, this documents updates = the > RPKI Resource Certificates Profile (RFC 6487). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-15 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-pki-profiles-15= >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Wed Nov 4 16:27:58 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0540F1B2AA9 for ; Wed, 4 Nov 2015 16:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebbGbTDdTpgV for ; Wed, 4 Nov 2015 16:27:56 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (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 E6E3E1B2A1C for ; Wed, 4 Nov 2015 16:27:55 -0800 (PST) Received: by pacdm15 with SMTP id dm15so43819836pac.3 for ; Wed, 04 Nov 2015 16:27:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Garm2AO/Jx2jG6paBN/UFkwk014ht/xL2LHxoqPtixU=; b=FNeWrDT2+HkCXtX/+61b3ZWgtGpILcxf6jXEY7J8CqY0N7BmWws1Kjh+5uuGNtC0YL OJsyiOkNBbxNS/tRFcgXnoofzSTfVezSp7PAB7HD32u9i8L2m3IhUOs/hQozAo/pEHnM WdDa82AOa1bFAxLnYX6yq7f/o4CqOIAQcoDYo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Garm2AO/Jx2jG6paBN/UFkwk014ht/xL2LHxoqPtixU=; b=RoS2bHilhPPLONbhmANQI+6VrKIsNIJJ4Q9s2sRbYqnOTQ36Xpk0IGNnV5LO/JQLGr 9GJ2Z/r0GaMKRGc3r1/d2ZiYlo7ywmlKkYlS2JWTIm5hBQ3z4o16yzO6gZ+De76qzSZS EqHLxEjERqFXbIakTUN+hSZs2qY4etWRLuGrVzyMoogYHZ3xjNAcsTXGCda4cWAsAao8 lPZT1BWy1c7ltxNIbEhFq30B7NFMS5B2SWSOIy0yWzAv+fk9Yth+oT1BrV5lecYn1iX7 FPU6J3RYiBq0pxM6j0M8ckibxdXhNzbUztOmoIXbOYzL4JB7GSzdBFy8qXdFAX53jjjn AHfQ== X-Gm-Message-State: ALoCoQnM+4WFCJYvyUFgfI7XwPyAnjzYaTnz6sNnNVwZll2lNU0o+PG4jN4zAWMAzoQ1FEfEFNIS X-Received: by 10.68.139.98 with SMTP id qx2mr2768258pbb.150.1446683275407; Wed, 04 Nov 2015 16:27:55 -0800 (PST) Received: from t20010c4000003024f10a371371e89136.v6.meeting.ietf94.jp (t20010c4000003024f10a371371e89136.v6.meeting.ietf94.jp. [2001:c40:0:3024:f10a:3713:71e8:9136]) by smtp.gmail.com with ESMTPSA id ve8sm4214858pbc.48.2015.11.04.16.27.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 16:27:54 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Content-Type: text/plain; charset=utf-8 From: Sean Turner X-Priority: 3 In-Reply-To: <05b401d116f2$5df837a0$4001a8c0@gateway.2wire.net> Date: Thu, 5 Nov 2015 09:27:51 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <71E73C3B-73C8-42C5-BC2E-BD67AFB5F4BB@sn3rd.com> References: <20151103020345.6574.58546.idtracker@ietfa.amsl.com> <05b401d116f2$5df837a0$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-12.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 00:27:57 -0000 On Nov 04, 2015, at 20:14, t.petch wrote: >=20 > ----- Original Message ----- > From: "Sean Turner" > To: "sidr wg list" > Sent: Tuesday, November 03, 2015 2:07 AM >=20 >> Incorporates comments received during WGLC. >>=20 >> Willing to be shouted down on the tweaks in the IANA considerations > section, but I am hoping that we can move progress this version of the > document towards our AD. >=20 > Sean >=20 > More a gentle nudge than a shout. >=20 > draft-leiba-cotton-iana-5226bis-11 introduces the idea of a registry > being within a group and this I-D makes no mention of the latter. Is > the intent to have a new BGPsec Group, slotting in between Battery > Technologies and BFD, or is it part of the existing RPKI Group? I > suggest making that explicit in the IANA Considerations. Oh good idea. I think we should put the BGPsec registry in the RPKI = group so how about : The Internet Assigned Numbers Authority (IANA) is requested to define the "BGPsec Algorithm Suite Registry" described below in the Resource Public Key Infrastructure (RPKI) group. =20 > And to make the IANA Considerations complete of themselves, since they > get extracted onto a web site, should there be a reference to the > constraints imposed on the algorithms in section two i.e. the two > algorithms to be registered must be as specified in rfc6485bis? An > rfc6485ter would then have to have IANA Considerations to update that > part but I expect we would remember to do that. So there=E2=80=99s no registry for the algorithms used to sign RPKI = objects. Folks that start out in IANA registries will need to follow = some bread crumbs from ROAs, Manifests, and Ghostbusters to 6487 to = 6485bis. BGPsec will be no different in this regard. Again, this = assume readers start in the IANA registries, which I hope is not where = they=E2=80=99re starting ;) spt= From nobody Wed Nov 4 21:42:38 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F141B39F9 for ; Wed, 4 Nov 2015 21:42:37 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwM2rMQ5gsl5 for ; Wed, 4 Nov 2015 21:42:31 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0107.outbound.protection.outlook.com [65.55.169.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D67781B39F3 for ; Wed, 4 Nov 2015 21:42:30 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from jfujimiya-sslvpn-nc.jnpr.net (122.216.203.186) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.312.18; Thu, 5 Nov 2015 05:42:27 +0000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "John G. Scudder" In-Reply-To: Date: Thu, 5 Nov 2015 14:42:05 +0900 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: Sandra Murphy X-Mailer: Apple Mail (2.2104) X-Originating-IP: [122.216.203.186] X-ClientProxiedBy: SIXPR01CA0017.apcprd01.prod.exchangelabs.com (25.163.105.145) To CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB457; 2:bIKmDmx6kLZ13hzPl3wvqRAXjZj2UEZcEFvM1AKddA3tTGJhbEMXJRzSWidrbmiHGiItTt3wZc51J7iTu2mAHwoVkkSw7mAXc3ul8qHDdw9QEbXloibVhS0+WvjleKgmjSWr60MWqKaufWNDb+FfWlDdvfy4rzAERhDkSHgUVYE=; 3:e/NnOEcdzkNeQXzOwAmg+a1qnvO2cU88+UPf9tWdy8OWYWTAdLUdEp3ochTP0QtURF8oIQWahe/sgs7x3DZzDS4wUkNZLoASTa3GSGi5s6/CNENPs5GuqiyXOC2mHby4Uurdt4eb2+98w1NkwWMlqA==; 25:vsxu7pxh1By6pzcmk3HOHrOScAI1g6UeTLQS2YfrqMj30oK7VU2oymKA2y5AhcmmLoU1/gRADBsfzu0srmHL0g6LX0xf2ie2buLUz1VOaHzkpy7Sao0WdE8hq4djGLmZvgTxM11xvZX9cGdC8kCGMkQwW117qxqkyMegrsrDy12RPpNysJKXrvChvu6U6n5S6AZmyVC30ZZ1dEqEaWAHzn0O1LR14vRzE4R2UI3JcufEh0YhGvxuOSU44nhHwbysiwlqeqB+sqpX9nJt7CVR1g== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB457; 20:3/LG4AEcCTWddoaSZR+XDwnkezUnOExI1Cn8hg7VPJY/cyRuzgQ4D6o9x7fjVj7Qtf6/TwDA1+3S/53Knbj0Z7Z1ZcGJDfvMLsADpdDv0aXUmpgLXua13Hg4Rl/j7sprqe6DI+RXrWH4KzJB4nBfI8ebq2AzbbS9+X7DTLIQUoLdtPtXa/Q1zw1Vfb1Q+7Gb15HtKhxA+5MoBouUTetiNgAcUmBSd0kLCFCjZWGP/E5ETsOzQOvIOWNmZ4hp9HGQFW9Av+urMOyzVmWEhR/IqzEQHCU6zwQ5/dD2CONuNqYFQwRoAITSeUn0uZSMgwJgufqcytC8vfaLZyS8WjBIWn1APnjmRN8+UgY3yOSY/eDvkaVYtqKBDWb+Ddm9Jz7xWLzX/zL4lm1vys+0Rme7Q2y/j8AmmLE30o+bvXbLoubOTH2GcfXR7WgmFbq4vGdN4QSNAaM3a27Ug3d+yx9VQKc+SBe/dKqdOTgD2BVlgWJinKVhwnGgzJj6ZgzZ8+Kg; 4:u+FDYw+4yEpFFAK9HnokraIAsZZAmvWfQtv/QNa7YcIWhH4SaSDkIbVbf//tMAOYQZXZ2HLjA8kJ5ig7XtaMHIQ+pGU4cCx3FBo/GTTWaZb9Ll8fDMglzLbyTa9q0KjTxjKceyHh0+yG97fQu3xF5dhWIcsnUMIWSe0xDtSVR9b5yEODIwQVADHp4S6XYx/lUEwOZKVWr/y7ccmHYZgJ6d5iS/HyvQlILHytjWG0m2p5RezHGeOhMo8WtH2iILIxMzimqIG40RVneXu3mctEFsRTzemz7xRQ8CwyOW+LIwpMy2fpECHiDGAkzOLU4izYWupntKJnC4D4dVXjHAVwHDo1sUppoFazJIAZHAzhfNhB+zQ6RTbNkEDm9XwTRZdb X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10201501046); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; X-Forefront-PRVS: 0751474A44 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(189002)(199003)(36756003)(23746002)(33656002)(82746002)(81156007)(57306001)(97736004)(5001960100002)(106356001)(40100003)(110136002)(189998001)(105586002)(50986999)(50226001)(83716003)(2950100001)(47776003)(5004730100002)(53416004)(42186005)(92566002)(77096005)(87976001)(69596002)(19580405001)(50466002)(76176999)(5007970100001)(86362001)(66066001)(5001920100001)(101416001)(122386002)(19580395003)(5008740100001)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:jfujimiya-sslvpn-nc.jnpr.net; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; CO1PR05MB457; 23:Zg+TjzJo3FA85GkyPFVLjomkHo/vL0myZfC7FY?= =?Windows-1252?Q?bPu/5bTo0qpQluD9tlJe2kduaNKEOLfQJWw/ZweD79ZXTRIm5XIZDFiW?= =?Windows-1252?Q?N/wdJEUvb3mppKxTzE4EOlqoawW8mWMM+gCVj2tRaDOcP72pSSyumZid?= =?Windows-1252?Q?o6okeroleCaMIXEuL6mRO0XsPR9Y03gH+Oaf/K08E825FRqWdwLHgqv6?= =?Windows-1252?Q?XbbD55oKgh/g8Yiu/53he/CWRwMOyhXs7SyGfMuvSI1PgTURkKXeRX73?= =?Windows-1252?Q?EyeijwtYbdBTgeBRQmIi9kz5PVNVRi5R+SnH6IG0bWRbreROpaAtDdPj?= =?Windows-1252?Q?C7PktESVkK3zKN1F0wIH/UC5iikOzYzhFE4GRX1TtXnuTdnYNj9NI41Z?= =?Windows-1252?Q?dw12xmC55WCnM19uN/FaeHUT/Z9nLgAN9L6dFTibkqDK+G27hIBcRfei?= =?Windows-1252?Q?jzGpr/uZjcj16D82A8koGppAaKt5Jy/d9T60FEUroc2KD8smpqglILXl?= =?Windows-1252?Q?019isNtrRav6yifXz7nuLYlVSGHwY6xG/rZgbZqPA5Lq73HFurMmNsta?= =?Windows-1252?Q?unvT1tWJHMxPUBpqfVdsPXNwgWhfW46u9doYqjfg0zBX32FDXYkHVuae?= =?Windows-1252?Q?4pi9y6Yh+bRofEaZQBw8C5+0fVpEs0jlR0lN6pmFOh8xfhjvv9rI6Ud8?= =?Windows-1252?Q?RZqXIv8AyiCUIO2cmYxzrtJPK5y34OeYMhnpB+ah19XE3IbBzYVXOR3y?= =?Windows-1252?Q?DRmFqk4WguW2x+SGj9ME368CUJTV6imwLtrK+7H8DSvXjC7sQQwz7iq0?= =?Windows-1252?Q?WXKVu8R7e3HqtVGaylTb0dE7vLAbADCrancBkWOPIOXsPE75YiJzOeZn?= =?Windows-1252?Q?KwiR+SgHvrsRTIX+7AeGAFlDcjaElbn30/JcZdMOIu9RapAnykUjWroW?= =?Windows-1252?Q?j/8m9CiaHE66xR5ZPAo5uKGKrUVjYFsspXov2q9hV/NHVl8IMwysVAAB?= =?Windows-1252?Q?OE+XRjzM9Ojar7h2ul7IDlEEhyCeOIL88aMh0uyapkOMIGZ3U29KfVZ1?= =?Windows-1252?Q?nwECKnZjnMmdIJOmoM66VGGB7CCHPtArQ44vW2j+e79BbWflDxNFGci5?= =?Windows-1252?Q?+nWzuNqF+pFhFfvIDAxcPgruLJJ45Uk985y7/qplU+6K86d7QiRqx4jG?= =?Windows-1252?Q?8QjAt36FEJWLSJqXNNH4g7Klb5eg5in9MIEXRCw6/hvBCH3yzDsTRQHX?= =?Windows-1252?Q?mLINWlCL2D1qiBHQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB457; 5:L9Ca/gWiAoDkQfp8ShE3ChjDTkqreK4ukoHNjgWO75FsMibYR5uFIyrRtKIpwhF9NLgjcBY6rgy2i0YqpTX4HWhOaPxgs8Tj9mgLIauiayMB7VNk2h5K/uW6GT/uL9nxg+Nzv3hzRNPjeJ0XHXai0A==; 24:uPrK6h0Bt/CXV6AJXtzAH9cmRM9OdSTme7ATQQYwSOGO4fBKaeYffWJ1oeKuwqgpFBRSiGYrNqNY8mjivetv1WKlbJaWok9c803gdN98ZRU=; 20:J86vq9kBqM8k/s8+u5a1A2A5/HYOYRY5u2K/Jbr/1JtsTsP14xthjOjEizlJd82Eu6n9jZE8hSqy+Y3BSIlKXg== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Nov 2015 05:42:27.8487 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 Archived-At: Cc: sidr wg list Subject: Re: [sidr] new agenda uploaded X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 05:42:37 -0000 If you don't mind uploading a new new one to reflect the current plan = for Friday, it would be helpful. Thanks! --John > On Nov 3, 2015, at 7:48 AM, Sandra Murphy wrote: >=20 > A new agenda was uploaded. >=20 > Thanks to Tim to catching an error in the header, a holdover from a = long ago agenda. >=20 > =97Sandy From nobody Wed Nov 4 23:51:00 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9C01B3364 for ; Wed, 4 Nov 2015 23:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mk3QzFnRUPCh for ; Wed, 4 Nov 2015 23:50:57 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B31981B3BC3 for ; Wed, 4 Nov 2015 23:49:55 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 147C728B003D; Thu, 5 Nov 2015 02:49:55 -0500 (EST) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 2695A1F8035; Thu, 5 Nov 2015 02:49:53 -0500 (EST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_4103D433-7753-4374-99FC-4282B6CF0262"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.1 From: Sandra Murphy In-Reply-To: Date: Thu, 5 Nov 2015 16:49:46 +0900 Message-Id: <5B354B9E-C4A5-4C99-823C-8CF156F980D2@tislabs.com> References: To: John Scudder X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: sidr wg list , Sandra Murphy Subject: Re: [sidr] new agenda uploaded X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 07:50:59 -0000 --Apple-Mail=_4103D433-7753-4374-99FC-4282B6CF0262 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I uploaded a new agenda, moving Rob=92s time on Friday to Tuesday = without any attempt to represent Tue timing, moved Randy=92s = presentation on router keying to Friday, and added a presentation of = validation reconsidered. Still on the Friday agenda are Steve Kent and Yu Fu talking about bad = CAs. =97Sandy, speaking as a wg co-chair On Nov 5, 2015, at 2:42 PM, John G. Scudder wrote: > If you don't mind uploading a new new one to reflect the current plan = for Friday, it would be helpful. Thanks! >=20 > --John >=20 >> On Nov 3, 2015, at 7:48 AM, Sandra Murphy wrote: >>=20 >> A new agenda was uploaded. >>=20 >> Thanks to Tim to catching an error in the header, a holdover from a = long ago agenda. >>=20 >> =97Sandy >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_4103D433-7753-4374-99FC-4282B6CF0262 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWOwohAAoJEHplpQeet0IZQ60QALPwUYdGj4xpVBz+wfCmOeJ4 CnfL4YDSoVsqDq8TVarxYv/SQPRVNKF07r0MzydIGgCgifMZn6QOqY3kaMteGq1Z AD554Sa5Xfyx1RkEJe3voEAneaXbe04ByhUoaahDvQNwPWvKXpE+R/+usj21vHot vF9Z9Kn1lmNq7mVMPlqsQ55e2ncU71mT3yYirJug1PedXzYVYupA5ZtAk5DHG2GN oDN47QLY9O/fcOQQndlXABzSr86Inzd+jpSLByYuJMKa3wTXkW0bugCXCBGG+Irp HQS01vkHCozvRLYPpz7iCFsDaDYhivZQ98U7IiPU12AEnndYdHbtq8gtx4Br28Pg 4WeAftn9nQ5AcDpAjuNJkeoNFAycWZ62fLNPZBsjH7O5YBk/ukpK5HdJ89ra/apr u+TEyHLK7rFhmqkGxYkwVuvW8bFbhUd7oUCR4phpGnjIZnDHkp3mnU5yk8VdJQ2I Bavvn24NIElxqnIZZmY9FzTtrfV1uwUiUlJ4iTgFfZ1StKFdUIyMllusxModpx2y GpXgNEeOqSE237LBdZWwWmQqqdsy9TBvBmu1MDvDXucMK1bjnB6fzsaMpMPaqujG CNGklZZxDKwewiK9ya/KK3+1IHlJK+GVEA97MqxxOjtEHA7lrV8N0LjiIEU5iEAc 4u9jhXHTeXkSCaGLM/tJ =DYqV -----END PGP SIGNATURE----- --Apple-Mail=_4103D433-7753-4374-99FC-4282B6CF0262-- From nobody Thu Nov 5 07:29:04 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F7C1B3011 for ; Thu, 5 Nov 2015 07:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaiiSagDgxgU for ; Thu, 5 Nov 2015 07:29:01 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83BB71B3034 for ; Thu, 5 Nov 2015 07:25:01 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:54112 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZuMPL-000ACx-Fz for sidr@ietf.org; Thu, 05 Nov 2015 10:24:59 -0500 From: Stephen Kent To: sidr@ietf.org References: <5B354B9E-C4A5-4C99-823C-8CF156F980D2@tislabs.com> Message-ID: <563B74CB.5030509@bbn.com> Date: Thu, 5 Nov 2015 10:24:59 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5B354B9E-C4A5-4C99-823C-8CF156F980D2@tislabs.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sidr] new agenda uploaded X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 15:29:02 -0000 Sandy, I think "draft-ietf-sidr-rpki-validation-reconsidered served a valuable purpose, highlighting valid concerns about potential fragility in the RPKI, in the face of errors by CAs and in the context of INR transfers. However, I feel that this I-D should not progress. The topic of INR transfers is being addressed in much grater detail in draft-ymbk-sidr-transfer (which lists Geoff and George as co-authors). This doc. for which I provided extensive comments over the summer, is examining discussing INR transfers in a more thorough fashion and thus should provide a better basis for selecting a standard mechanism for their support. The impact of errors by CAs is being examined in a much broader context in an I-D that Di Ma and I have authored: draft-kent-sidr-adverse-actions. This document examines a very wide range of impacts that can result from an error by a CA or an attack against a CA (or an error/attack involving a repository manager). Thus I feel that it will provide a more comprehensive analysis of the sort of concerns raised in validation-reconsidered. Finally, the the validation algorithm change proposed in validation-reconsidered does not address the broader range of errors noted in adverse-actions. It also is not compatible with current RP software designs that validates CA (not just EE) certs as part of local cache maintenance. Once the sidr-transfer and adverse-actions I-Ds are completed, I believe the WG will be a much better position to develop mechanisms that will address both sets of concerns noted above. Steve From nobody Thu Nov 5 08:29:18 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2D11B3044 for ; Thu, 5 Nov 2015 08:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.151 X-Spam-Level: X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8G9EJlZULBh for ; Thu, 5 Nov 2015 08:29:15 -0800 (PST) Received: from mail.zdns.cn (smtp.knet.cn [202.173.10.15]) by ietfa.amsl.com (Postfix) with SMTP id EB7FB1B3042 for ; Thu, 5 Nov 2015 08:29:14 -0800 (PST) X-TM-DID: bd3e532f4a2505b4f295f5858a0ef20a Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Declan Ma In-Reply-To: <563B74CB.5030509@bbn.com> Date: Fri, 6 Nov 2015 00:26:36 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B354B9E-C4A5-4C99-823C-8CF156F980D2@tislabs.com> <563B74CB.5030509@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] new agenda uploaded X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 16:29:17 -0000 I agree with Steve. =A1=B0RPKI Validation Reconsidered=A1=B1 should not be carried on. And I believe that our WG should look at RPKI operation security from a = wider perspective and pursue countermeasures according to a deliberate = threat model as described in draft-kent-sidr-adverse-actions.=20 Di Ma ZDNS Ltd. > =D4=DA 2015=C4=EA11=D4=C25=C8=D5=A3=AC23:24=A3=ACStephen Kent = =D0=B4=B5=C0=A3=BA >=20 > Sandy, >=20 > I think "draft-ietf-sidr-rpki-validation-reconsidered served a = valuable purpose, > highlighting valid concerns about potential fragility in the RPKI, in = the face of > errors by CAs and in the context of INR transfers. However, I feel = that this I-D > should not progress. >=20 > The topic of INR transfers is being addressed in much grater detail in > draft-ymbk-sidr-transfer (which lists Geoff and George as co-authors). = This doc. > for which I provided extensive comments over the summer, is examining = discussing > INR transfers in a more thorough fashion and thus should provide a = better basis for > selecting a standard mechanism for their support. >=20 > The impact of errors by CAs is being examined in a much broader = context in an I-D that > Di Ma and I have authored: draft-kent-sidr-adverse-actions. This = document examines > a very wide range of impacts that can result from an error by a CA or = an attack > against a CA (or an error/attack involving a repository manager). Thus = I feel that it > will provide a more comprehensive analysis of the sort of concerns = raised in > validation-reconsidered. >=20 > Finally, the the validation algorithm change proposed in = validation-reconsidered does > not address the broader range of errors noted in adverse-actions. It = also is not compatible > with current RP software designs that validates CA (not just EE) certs = as part of local cache > maintenance. >=20 > Once the sidr-transfer and adverse-actions I-Ds are completed, I = believe the WG > will be a much better position to develop mechanisms that will address = both sets > of concerns noted above. >=20 > Steve >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Nov 5 12:54:00 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD301A1AC9 for ; Thu, 5 Nov 2015 12:53:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8eyEnQYluCb for ; Thu, 5 Nov 2015 12:53:56 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1461A1AA6 for ; Thu, 5 Nov 2015 12:53:56 -0800 (PST) Received: from dhcp89-089-172.bbn.com ([128.89.89.172]:56754) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZuRXf-000Ivx-9r for sidr@ietf.org; Thu, 05 Nov 2015 15:53:55 -0500 To: sidr@ietf.org References: From: Karen Seo Message-ID: <563BC1E3.40100@bbn.com> Date: Thu, 5 Nov 2015 15:53:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sidr] Validation reconsidered draft status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 20:53:58 -0000 Folks, I think the authors have brought up some pertinent issues which have helped inspire other work which subsumes them. So I thank them but agree that it seems appropriate to drop this draft since those issues are now being covered in other documents and those documents have additional detail. Randy's I-D discusses INR transfers. Steve's draft on adverse action provides a detailed analysis of the "operational fragility" of the RPKI in the face of attacks and errors. So, if the adverse actions draft is adopted by the WG, we (the WG) could use the requirements stemming from these two IDs as the basis for a solution(s) document. Just personal preference, but I also find having one document per topic/issue (at least when they're as complex as is the case with the threat analysis) easier to follow and would also like to separate defining of issues and their requirements from describing the solution. Respectfully, Karen On 11/3/15 4:21 AM, Christopher Morrow wrote: > During the meeting today (tues 11/3/2015) one of the authors of: > draft-ietf-sidr-rpki-validation-reconsidered > > noted that after the last set of updates and over the history of the > document (2+yrs) there's been no real support nor direction from the > working-group. Additionally, all co-authors noted that the lack of > support and direction meant that abandoning the draft seemed like the > best current direction. > > The primary author: Geoff Huston (gih@apnic.net) is willing to toss > the XML over the fence to another author/editor if there is interest, > or to let the draft expire/die if no one is willing to take up the > pencil. > > Over the next three weeks let's discuss the direction/end-goal and > determine if 'abandon' or 'new author' is the best course of action > here. > > -chris > sidr-co-chair > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Nov 5 13:18:26 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB961A1BB5 for ; Thu, 5 Nov 2015 13:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7l3qNX61s3wE for ; Thu, 5 Nov 2015 13:18:23 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75E381A1BD4 for ; Thu, 5 Nov 2015 13:18:23 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id DB01B28B0042 for ; Thu, 5 Nov 2015 16:18:21 -0500 (EST) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 3C4341F8035; Thu, 5 Nov 2015 16:18:20 -0500 (EST) From: Sandra Murphy X-Pgp-Agent: GPGMail 2.5.1 Content-Type: multipart/signed; boundary="Apple-Mail=_6DE705C7-A52D-44BB-8620-40FA6D84E5AF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Fri, 6 Nov 2015 06:18:13 +0900 Message-Id: <65C4E852-CEDD-49BA-929C-36ECA3DDFF0B@tislabs.com> To: sidr wg list Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Sandra Murphy Subject: [sidr] jabber scribe and minutes taker volunteers needed X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 21:18:25 -0000 --Apple-Mail=_6DE705C7-A52D-44BB-8620-40FA6D84E5AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 We meet in a few hours but we don=92t yet have jabber scribe and minutes = taker volunteers. Please do consider volunteering. For minutes taker, use of the etherpad = means others can help out. Jabber scribing is very helpful for the = remote participants. The meeting will be unable to progress before we have volunteers. Please. Please. Please. =97Sandy, speaking as wg co-chair --Apple-Mail=_6DE705C7-A52D-44BB-8620-40FA6D84E5AF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWO8ebAAoJEHplpQeet0IZWQcP/0b3yvuYyYXNBLxLtVHT3kv8 qhIsAbZfddf7qBI0YjyxZE21ZY0ZdsHajbUtyNZiVXT2Z3IDiXVtUidnU25D0bFC MYIQhUdm99n3eeKWWayuMZ6FfEg5bGUcZVqdid+WVvirsApOlT6+N4INkbLZ5enK R24prmfvGjo2WZ1ZfmucFNQQoNl7enWaBUYKmqeKLJ/I+6a1lKeFpdmKoCN8PNnr 0Y307XTdOsYvIk6ZPHp/vqvRStBXgpoF8P9Zdu/HBgxfd6cSRv+hypeWIxVSBqK6 DcJ/vVlWyQAXPnHpKSLYvT+3vjQc2dWked+ajqzgffg8Gg6dCyWqiqnDVyOWhI46 eyH34aYiCY/C0m0Y+v2+iUsvNGH6ViStOJB7uzYIWx7otFPTDDCcLuqf8dfro1Zy DUpoJbxzpZTN1TyN+WilX+npoUb0+0zvzwxPdmMKd9BlyGv0dK81KASK+BTdPK58 RMQn5kLd0OpgHl9uJB6Jzxpq1iqgHEAYWKOfNU2/hq5bqowzmWjFQ2k9UGVUOmvR uDNpzvKFWdrCSEbPHn11KF6HjgURoMrirUFo0JmIVeElX2FVPLo5P6TdBHTDKkho f45pGgLRfzfSbMX9RaNJZOl+mA2Cyy3ayxVb0/idHe1riVW6NiL0oonEdh+EU3EB fipKqhSCLdjuPvYIzgjo =nzrX -----END PGP SIGNATURE----- --Apple-Mail=_6DE705C7-A52D-44BB-8620-40FA6D84E5AF-- From nobody Thu Nov 5 14:31:35 2015 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 677121B3C8B; Thu, 5 Nov 2015 14:31:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.8.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151105223132.16465.73433.idtracker@ietfa.amsl.com> Date: Thu, 05 Nov 2015 14:31:32 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-13.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 22:31:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : BGPsec Algorithms, Key Formats, & Signature Formats Author : Sean Turner Filename : draft-ietf-sidr-bgpsec-algs-13.txt Pages : 7 Date : 2015-11-05 Abstract: This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key size and signature format used in BGPsec (Border Gateway Protocol Security). This document updates the Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure (ID.sidr-rfc6485bis). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-13 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 Nov 5 14:36:39 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58CE1B3C80 for ; Thu, 5 Nov 2015 14:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7PDaYfQflkC for ; Thu, 5 Nov 2015 14:36:36 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (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 7DD811B3CB0 for ; Thu, 5 Nov 2015 14:36:35 -0800 (PST) Received: by pasz6 with SMTP id z6so104086103pas.2 for ; Thu, 05 Nov 2015 14:36:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=XOyOd+HBdzcSMzZM8C7Yh7OZQL6f8EMd5iYZxwRh3Hs=; b=Pjf0lYV9s7J/rT/Nk4cPgH3/+OaVFztK8FXnhx3Pau+AdG4s1VMvTq+SOiH2fYg9xG ratsQa2jjDwFvNMuJoX6Hdx/EZE26zfCwCEoZc1a6g8utZmw1CtaSCZ9sL3YxiqxpQiS C8uSrllGG3zloh25+V3Qthaut3Bf/lk5XigKk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=XOyOd+HBdzcSMzZM8C7Yh7OZQL6f8EMd5iYZxwRh3Hs=; b=BhW4LMpCfcUHi4mOfT4ULJRXxuQVvLhHGmvCw+HAC3Ra7gCIeZu4UyVXYHgwCZ7z5n No1d+/6ejG2loPK2/VgNOaq+WK6+CBns6gXQooRBV4N2kSbBSuyc+vBc8zYGf7k3hh+F IUh+DVupMsyOTRjf8nVSalAdIEQkP/9nUwG8NewJ20ljRfTY2HQOjFDiHD3UrjOELg0r qTgMd0IGKQi1pAqLi4DD7FqOaRehT/uO1XLX9U4aK3xPliBNgZCASDA+wTTmqa1SaxXr kT3a3XjqzQxS9hBrJU/sbjC7dThANL+1gwIPDF05lh5njHzPMzH+sZ38Kh7zEpwtoyEE XmBg== X-Gm-Message-State: ALoCoQkWMKynyilpi869VP/1U9UDMtVylvrUDyL7YTZBpzZwkw5fsFsblSa5Q/v07f8IvPcgKZeJ X-Received: by 10.66.136.11 with SMTP id pw11mr12649904pab.87.1446762994905; Thu, 05 Nov 2015 14:36:34 -0800 (PST) Received: from [10.71.2.205] ([101.110.53.38]) by smtp.gmail.com with ESMTPSA id ea1sm9735618pbb.76.2015.11.05.14.36.33 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Nov 2015 14:36:34 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Sean Turner In-Reply-To: <20151105223132.16465.73433.idtracker@ietfa.amsl.com> Date: Fri, 6 Nov 2015 07:36:31 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151105223132.16465.73433.idtracker@ietfa.amsl.com> To: sidr wg list X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-13.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 22:36:38 -0000 This version addresses editorial tweaks I got from Steve. Most are = concentrated in s2 where I tried to make it clearer that the algs to = sign/verify cert requests and sign/verify BGPsec update messages are = defined in the doc and the algs to make certs/CRLs are in 6485bis. And like the pki-profiles draft this one updates another Standards track = draft/rfc so this really ought to be intended for Standards track as = well. spt > On Nov 06, 2015, at 07:31, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Secure Inter-Domain Routing Working = Group of the IETF. >=20 > Title : BGPsec Algorithms, Key Formats, & Signature = Formats > Author : Sean Turner > Filename : draft-ietf-sidr-bgpsec-algs-13.txt > Pages : 7 > Date : 2015-11-05 >=20 > Abstract: > This document specifies the algorithms, algorithm parameters, > asymmetric key formats, asymmetric key size and signature format = used > in BGPsec (Border Gateway Protocol Security). This document updates > the Profile for Algorithms and Key Sizes for use in the Resource > Public Key Infrastructure (ID.sidr-rfc6485bis). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-13 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-algs-13 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Thu Nov 5 15:20:50 2015 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 862B21A00A4; Thu, 5 Nov 2015 15:20:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.8.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151105232047.1458.9483.idtracker@ietfa.amsl.com> Date: Thu, 05 Nov 2015 15:20:47 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-origin-validation-signaling-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 23:20:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : BGP Prefix Origin Validation State Extended Community Authors : Pradosh Mohapatra Keyur Patel John Scudder Dave Ward Randy Bush Filename : draft-ietf-sidr-origin-validation-signaling-05.txt Pages : 5 Date : 2015-11-05 Abstract: As part of the origination AS validation process, it can be desirable to automatically consider the validation state of routes in the BGP decision process. The purpose of this document is to provide a specification for doing so. The document also defines a new BGP opaque extended community to carry the validation state inside an autonomous system to influence the decision process of the IBGP speakers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-origin-validation-signaling/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-origin-validation-signaling-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Nov 5 16:18:41 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7DC1A6FA6; Thu, 5 Nov 2015 16:18:40 -0800 (PST) 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxgm4FthkvBT; Thu, 5 Nov 2015 16:18:38 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0721.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:721]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CA1B1A212D; Thu, 5 Nov 2015 16:18:37 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from jfujimiya-sslvpn-nc.jnpr.net (122.216.203.186) by DM2PR05MB461.namprd05.prod.outlook.com (10.141.105.15) with Microsoft SMTP Server (TLS) id 15.1.312.18; Fri, 6 Nov 2015 00:18:16 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "John G. Scudder" Date: Fri, 6 Nov 2015 09:17:53 +0900 Content-Transfer-Encoding: quoted-printable Message-ID: <348AACB0-9619-4778-9A57-41BB92862396@juniper.net> References: <20151105232047.1458.9483.idtracker@ietfa.amsl.com> To: "" X-Mailer: Apple Mail (2.2104) X-Originating-IP: [122.216.203.186] X-ClientProxiedBy: HK2PR04CA0028.apcprd04.prod.outlook.com (25.162.205.166) To DM2PR05MB461.namprd05.prod.outlook.com (10.141.105.15) X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB461; 2:jk6+KLlPbRpSXAmDnQXJZe55fl7e+m79gmwgNrDNYrMP5yQluZ/XWl8ZsnRebAN7u9G8Z74gmBIhi3gJCvR3/fSNa4yqfuh6SQI9Yzh/CaCY+eP8vfW3KR7EpRNcyhxgMrzPDUGewAZrbkeO8Ec+TrITn++n3UgjecdnVz7A+lo=; 3:VwWThP0SxvbP4Qk8aLJ+HuDaq4PycGa493i19HhtWBq/3oRUObnt8EAnZfj71ek6nGtWdCDDRRf7lemOTy2SL/oLiMFmFNbCgBNS3xAV4LFeMTRf9QE4y8E+i0a5UPxIjsyaT5QZYNh1rbvnTGBlag==; 25:Pzpl0bjOa75fWcS6aqJXYADyDZIKkd7HQVl9KtX6QoHJ2akon/86KgHXf5Pv2Cn2NkfR84BEyF6Y+Befhddv55VmnBQbwLfm/7T9ow1z9onDkJADmgfTMdiRhYAIUPaOifCTP5busBbMA/O/TfKA+/OPq+oJkAX+ezKY4XQ0X3l/3sVn0ul0vj6S/Oqy2DtsbaTixc/MW6DRNU50W2hhC50+F+HqNrd7Yj3WWzcYEoriygeoFIksJ1arVwg9EluXmbHJULVMzWRw8QBQFkej7g== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB461; X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB461; 20:m3d+ugkSoI66O14bhH9xgAiQFH0CrXnGD2RTUIGN9+o/zGggj2bxC5/uwrhevaPb1pPjHoqcF48oXOWi+epOCCjFMFVe+/Lu3SaDnbuCMq6GXAf1iYzoUugLWWPfRsrW8dLpz0PAUp/o3AwwRIracbCGnvwCqqkQdTHb3A9tFhv1Ne2cz9SmwYLhkxUmbDYJuanorVu5/uGWts2Juw+qzWqBo1MxelqKyHVOIJ0eeoVQxozWzUUurq8if1KUY4dEQpsDb9EsF6L+xWhus2MrXSTiEwHUMRMUFxChNZN5M+xPjHrLcBvEhgp2qFaiXLYMY+SAN/sNmHsWoUH6rTwoXhYhOr4qeD7HDTPNckqdJPA8qB05pRYYxs4ac+ukwTH9iHPdsu+Ha++hTCEyqZgEqQutifPm4dqU9gJwEUqHI9Mltes5vsCl5GyOYoX3kQJKQgNyrWIkSbhxgqL41G6fQQ67F6IwLg2kU+eZjp76+NEa08vxA8yjQ+Br9pef5yju; 4:beQWcHVBL5coEMnx+ZEZjAfblMvya6JLyogLxH3GrQ62wdy3x/fvLtrv+3B16DE962k69L0KNhINSr0+qe2oPTBGpqzBgKMx1tvfvVw1nTn77NrOCq+OrajaWroP3TOIGo1gP0ob+/FWgtkM0Q/a5R0eeDKEqLK847P+lEmisgFjUM6sxfm6evCK6ajmKqcivr/VCWzZyDXURQNiye57ql1AipelNRpAEqnhu7twB/9aPA6+T/qUbJhHDwdBQydccwUs+kJ6BrHQ8UpIUZNEHckYoapomM1+t8EitQgeINPPKOc9CWDLJ7M2d7dVOoaegM1mwjH/Z4MJG74MVT6od+TLrSdykdiR6y9ZfWOCarJAFF8WT7FLQ/Rwmi+EPvH9 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:DM2PR05MB461; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB461; X-Forefront-PRVS: 07521929C1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(164054003)(2473001)(53754006)(377424004)(377454003)(189002)(230783001)(76176999)(53416004)(66066001)(19580405001)(77096005)(23726002)(87976001)(5007970100001)(5008740100001)(15975445007)(42186005)(47776003)(122386002)(86362001)(82746002)(92566002)(5004730100002)(36756003)(50466002)(46406003)(33656002)(97736004)(40100003)(5001960100002)(105586002)(69596002)(50986999)(450100001)(83716003)(57306001)(50226001)(189998001)(97756001)(101416001)(19580395003)(81156007)(106356001)(110136002)(42262002)(104396002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB461; H:jfujimiya-sslvpn-nc.jnpr.net; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR05MB461; 23:fWz0ngh1Sn5slyOR9PZ6FVaZk+wfnQ1KYASUlhCpL4?= =?us-ascii?Q?K/iv2s0fa17SvnOt+ymBYa4Ml2E1MtwTBvjD6m3fne/nYGaFnXEWxEwZcIiF?= =?us-ascii?Q?gWxCSzs9L+M4QQl92z6lzU7uMGudqH/wv4YotATNz47fspd49EWSUUCsZh6w?= =?us-ascii?Q?M5b7YLYTJDz5SycCBHeckxMUIcafeHiK1PAPymMWQ/mRnOud83nVPEtnEC6s?= =?us-ascii?Q?rBgideew1ycytWuLAWZONZGp264JVBjjGDGuQZUa7WbhpKotdrZMU+BJUHGR?= =?us-ascii?Q?9wytuVOpwZfH2PN1IsPfD4THTWwdZMIS0joPv7g6oHFIllgRnVaqb+qUL2P2?= =?us-ascii?Q?pGae6QaeqW851SWx4elhslOn2eL1aoyMRPQ7FmH62yoihI92GFStnW1WUqtx?= =?us-ascii?Q?Bqxf3A4oTxZbP/NiJyOTSzk1AAuC+L8k8ap3iMw/15jhUuyiH2XHQxa3jBA8?= =?us-ascii?Q?GT7c3zT5eaAALdSMjbkcFTAESPn1GRWv18wJ3qlAk3JyR12V8z6jhZg8yvaz?= =?us-ascii?Q?V68iK5fuRnAY6kaikK2bwcSUtD/aL+A7M2KlTh/lXbRd/8t6jTyuodWn+FOE?= =?us-ascii?Q?x0gF3rid1cw9S1JhwticLYTtVp+yqVJe19hKlOQGmYhVxdIFbtYwNxBRMmOh?= =?us-ascii?Q?OYPeW/9l1V0+Dh9OluZY16vYdxRscLTcuRI0PdeJVXlVX2EHDlZ6anS5YABl?= =?us-ascii?Q?g774S9q9FbK1jRy99FRjAuFSvi/n6AL2jtgyQg1u7I352W9hIC8lsyUJ522h?= =?us-ascii?Q?gk5/8ViuLh1slyYswEMkiYhfDrIUyv3TlZq6Fgd5NxewbkjQVGvhDbjbxU2i?= =?us-ascii?Q?/XfVQq3tBtsgiyi7WWTOrAk4GFdWpxOX682TT99y3KV3x7AAip6B7rRLNTJC?= =?us-ascii?Q?/br7ZzaLTxVl+iHjqgSABZifbr+H35PANXgj7tjtQlWedpd7UXA1SB3EhenF?= =?us-ascii?Q?v4jqsgXpcTJZvUxp44RFlVGjIjc5ttNSKMgr3eLu2L0dQCgvc6LAXLVRgIQR?= =?us-ascii?Q?pKIE4sRlgNHJvbKCBwpnoKPk0YO2IJyFDGRoxYxBWc9GybcY6aUQr2EeWL5A?= =?us-ascii?Q?2C+XitgBpGWu4BASTau55jeCTXO8NiGlcE+e6De9JXkxKk0EJ1Y6JI11zhJi?= =?us-ascii?Q?3wgSGF7xcRCT9fbxVvAiEtzYfmbE++kKyQcUitY1xUU6RkU6uGOiSgO/Kbde?= =?us-ascii?Q?bhUEwoSW5aw0TBQMkUvx+bT6RY2Wxz0a4WQbn62erGHz77zyBfttyxSBeaKb?= =?us-ascii?Q?fkVwqS2xdBTenfl7J387F56kGOWgjm97gQtI9l0B+qFUqfhQbye5xlWnf3Ag?= =?us-ascii?Q?=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB461; 5:vV9HV6w4ZZCOotB0nyMVTDmRS3MW/E8+/Umn5n2WTx7BI7K82n87p4+oQqlRDx+x9eKjnllDtNR5DKSsDl6UBzFEBg/RuNG6LeLJNLftPn9IBdxIAJfLnCRvocUjsUCq88VYDaTgLlF5bmtq19QkEg==; 24:Y+6HmmBvA4N63PLeJC1fBBwHdrhPnFgB/svDhsF+7upzuvJOs9JNME1am50Dtv9c8Sn+hU103cqqbcgVmZVrvgPR1QQEP9M7bRaf4A2HYyQ=; 20:ujxWwiOncBy8scFC6/l0syHq02TdkGPItEghbOUwfS0cp4iKJ3QgiuAz6YxgZd8Ct4vPOVr9JLbtsDYhdcyKOg== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Nov 2015 00:18:16.9707 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB461 Archived-At: Cc: sidr wg list Subject: [sidr] Fwd: I-D Action: draft-ietf-sidr-origin-validation-signaling-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 00:18:40 -0000 Hi Everyone, This is a revision to address the comments that arose on the IDR list as = part of the SIDR WGLC for this document. I summarized those comments = back at IETF-90, see = https://tools.ietf.org/agenda/90/slides/slides-90-sidr-5.pdf.=20 The authors believe the document is ready to advance now. Thanks, --John > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: [sidr] I-D Action: = draft-ietf-sidr-origin-validation-signaling-05.txt > Date: November 6, 2015 at 8:20:47 AM GMT+9 > To: > Cc: sidr@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Secure Inter-Domain Routing Working = Group of the IETF. >=20 > Title : BGP Prefix Origin Validation State Extended = Community > Authors : Pradosh Mohapatra > Keyur Patel > John Scudder > Dave Ward > Randy Bush > Filename : = draft-ietf-sidr-origin-validation-signaling-05.txt > Pages : 5 > Date : 2015-11-05 >=20 > Abstract: > As part of the origination AS validation process, it can be = desirable > to automatically consider the validation state of routes in the BGP > decision process. The purpose of this document is to provide a > specification for doing so. The document also defines a new BGP > opaque extended community to carry the validation state inside an > autonomous system to influence the decision process of the IBGP > speakers. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-sidr-origin-validation-signali= ng/ >=20 > There's also a htmlized version available at: > = https://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-05= >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-origin-validation-sign= aling-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Nov 5 16:38:54 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF451A854C; Thu, 5 Nov 2015 16:38:52 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7k0x4UhVQ-jQ; Thu, 5 Nov 2015 16:38:50 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0115.outbound.protection.outlook.com [207.46.100.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A2851A854B; Thu, 5 Nov 2015 16:38:49 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from jfujimiya-sslvpn-nc.jnpr.net (122.216.203.186) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.312.18; Fri, 6 Nov 2015 00:38:43 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "John G. Scudder" In-Reply-To: Date: Fri, 6 Nov 2015 09:38:16 +0900 Content-Transfer-Encoding: quoted-printable Message-ID: References: <002a01cf84b8$b0f55230$12dff690$@ndzh.com> <11159_1402415346_539728F2_11159_3728_16_53C29892C857584299CBF5D05346208A07161787@PEXCVZYM11.corporate.adroot.infra.ftgroup> <8DE674B8-45B5-4102-B974-B9312106E2A8@parsons.com> <3364_1402559139_53995AA3_3364_2738_1_53C29892C857584299CBF5D05346208A07162318@PEXCVZYM11.corporate.adroot.infra.ftgroup> To: Robert Raszuk X-Mailer: Apple Mail (2.2104) X-Originating-IP: [122.216.203.186] X-ClientProxiedBy: SIXPR01CA0035.apcprd01.prod.exchangelabs.com (25.163.105.163) To CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB459; 2:tCi0sSnIWwb4KuF1151F1f7v4AL96PKRRDtrmnp7ZNdZLbBGMg8OsZIfPytnvPOjXy+1XqWGItGr8jnozp0dGLpp6U5NiduLG7BLpUt5Zrle3zWEAEEiO8po9zCq0p/K47eZORTa9H2aSpEoezI8CLZSsBPAqHLHhQE+93I9sR8=; 3:XL1bnzLSnCsoUgYjfMmqJS5ZmZxpv177iFgJ4bDF1p+glvDmkZNMj002fMXaX4m5bKU9W/cFNBSHwjLs5xx3Oq1//NCiQu5/aa9tjv8ghCsKObytTniFeTdvKXET3uc8bn5X7CnV5JdvKp9QX1GQyA==; 25:ebLaN0+clUiP5mGWr7bxj8MlcjY/0tOWTYYtbiumXPNAAkxZg+/p3ty9MBMUH8cZXBGTvLpo//1NmOyoCZczzuf0P6lp57Q1XgIATlxwubSlyNBiaBAVkXaHIvgaYDS42uYWXMX4+/N8WDmb+UqMpLRYtt/DhN2HU3fyr5/0pYypwa15UztvWOpZ7PDTYe+xJpdQAhWN7MU5YnO0tKtJUe/CYTqFYpGz7kb6lYV/rHz8bdgV7eObIw/vlAA1uvV7fmyLqmQlq5BApSvrs7N4GA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB459; 20:miBZCdTzbpUiaVgHLw7j/CUjS0FHIbBrhQhZm1gBIz+kLeaM0w/GbWOQawlHGehm0zlcPMaeORMe5TJFOrwBeJOI5nBI4BjJM7NoFq+wwMNHEVYofLxOBe9eNrUhgPRLVhgNTwUSirUvMBw3IA5K/fP5fnQozHa+YxtQ0sC6+g5bcwjGuuNp7xB+X1tMEHcxRwoXmMrCToXSMy4mPFAvG96ECWdcjRANR9MEiJR/RCCUQdzkgTATjEqCbxEKL5qWVvnjdsmiBUdo2jy6RyYDH1eo2t3fjZNU+pvCrLEPJE9Z88YfpRdA1zXcgn7VZq6UWcxuKoGqRK0gAb27iuXtVZWhcAPSuzjdMsQhtKof3GRrk1YAqjciKVzHyzSPHyWwN/2vGArTg7ZZh3TQ2GrYkuWTXBA/A/+tJoAsOD5QCU2+mpC6vuZmK5T+Z3sVcNghii7meOX4YbN0Z7ec33qEsFbqblK4aCxkOl/05YY6fY0x3675HZY77Z50N3eBlNU+; 4:bkeeSroYVt4YzEwem5eH420zBJfslByGUgaXkxqaDDCY0cfZpMx30R0ZM9eKPNFv8J0NZsalnNBzvKoi+6ixSzWMuAAfU7dN5NLlrXb35uUSvFlBxQpOnxRFN4Xl8IwtNEoqp4n01rLDv3LX2XmbTYMk5HvePbxrUYTkWedJ2q10xzssEzhx0Viv86ToqPu5KXXthzDyh/hpiA/bUkbe6xWoTJa96EILwXsG8MDbbWiNLoO4EhgC3BLdWl5YeTjrT0iAfkklMz3SA37Yi6tp4CXIzWitJMVRnLmRlvc/EAVP8J516P7zmh+52YzCvnoDfGhZ9FGoobkZkhUke1+uMzz6N+TREizfCDhVqW7CnGmh+hmWQnHvfC+H/PHI7XSY X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(18271650672692); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; X-Forefront-PRVS: 07521929C1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(377454003)(24454002)(164054003)(189002)(19580405001)(81156007)(36756003)(110136002)(57306001)(106356001)(77096005)(46406003)(87976001)(50466002)(5004730100002)(33656002)(189998001)(83716003)(230783001)(42186005)(53416004)(93886004)(5007970100001)(82746002)(69596002)(50986999)(19580395003)(101416001)(5890100001)(97736004)(1720100001)(5001920100001)(76176999)(50226001)(66066001)(40100003)(86362001)(5008740100001)(105586002)(92566002)(5001960100002)(122386002)(23726002)(15975445007)(47776003)(97756001)(2950100001)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:jfujimiya-sslvpn-nc.jnpr.net; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO1PR05MB459; 23:KoFeSHzAahNGuVPgyeYR5Ugo3O52jpsT2CAegKFm0d?= =?us-ascii?Q?HesiRT8xcD9eiltdZHA8O4bL2LfYL1GvVrKtTgd50p+YOMcFW4esCUpK+Pxa?= =?us-ascii?Q?JHOGdI71Vovrqun77a6RM3j3ShKOzozfDkt8xlA4brIB6TmhQx3ajhsaA01B?= =?us-ascii?Q?u7DL8q/9yBaUr1nBpeVpX9CdwAp6Xqedg7oQFI/EdBwS8TSXbwShKdBk8GzG?= =?us-ascii?Q?ftC556Z7T65tRnCvhcdWmXggOkLOfy1xScDSi8UxT4OB5suuSr9pOdp/jnNJ?= =?us-ascii?Q?VwauqnAd/oJVf52nYd3lbBwn9QU8sh9Si0Gkqfp/4SekDCt/86wS/SZpxnUZ?= =?us-ascii?Q?rIFjyCRKvgCG3SDGQbOZITrKn9SAffCHG5AZKv5DpJ3X8j5qgT/HR20yJKDW?= =?us-ascii?Q?82VtbJ7nX8jb/WQmhiqTiCYWjJt6JAvJ28iCd8h0gaJ6Ds6cTfNB3qeO17qD?= =?us-ascii?Q?2+eHByy6Bo26t+bdTW1jP+7ZzC+ivRJ1s96hRZPHTUGJZsJ4xdBh7mPqkWDW?= =?us-ascii?Q?kbIHin+BOs8HzJkHoNcVGvEah5Tg6qmriMiTVHyK9GsFp8S9lBNOCLNVLp7d?= =?us-ascii?Q?WaJahwC9hgUnIw9XFOPjaKO5AWLinrNvcmV9rvJxLozpOM9P8CwhUXR4seWw?= =?us-ascii?Q?ALes19pmmvfDOr8wtlPGy8caPTmiLNQZ6lZ4nfV8xI+t7AmODivfr9G+WMUQ?= =?us-ascii?Q?Sxha395B+xcox/tSIIQ3MHnm8mslH1O811W+cDxktk20B8ChqkkveOmDCWIs?= =?us-ascii?Q?pFCDoH+jQfCqGO96pHoVckpo7hiZyiU3B9bZl9huqB4rHo4A76xEmRxmCYAy?= =?us-ascii?Q?Dh8Gpxl+ym5dsMvr3Wty7nuZ/Kw9GPi7WuKMBFwTCQY2vGexx+NfvU6w/d1t?= =?us-ascii?Q?P0TlGt+1El/YuMMxa/Y0gGx3/nGYiBgFON30m3ycgDG1w7/u9BRPfz8dQPzw?= =?us-ascii?Q?1D6cRUmDzsFckkZi8B9IDNCltDBeXAnKPcQgvCu3bMpYJoWim3ZZ7b8rcPpN?= =?us-ascii?Q?NYM5pzCx+N7sR400IABsil1abm4BJIV8zbLEVNoJ76+5ahXMyiB+aDMx6ODX?= =?us-ascii?Q?JEiGDoKMKNyzRQnHuiA2/ABlMJ+FA4s8xh+wnIJwSFi8m0CwkQbeCYEUOy4p?= =?us-ascii?Q?0h4iEBbcRxAdH7Aj1Ph7g4jYB/hd5BtC4yN5UQ4d7sx+UxINCDc/K57G9qS6?= =?us-ascii?Q?9L7x7PrGz1gI4REF0Ym3hTpo6ibN4msOHWQl68eKZdOHjEMhnZfMSb63Z92q?= =?us-ascii?Q?BzgTzAhfNTC93U1lSmg449tdcutBXohRUiOX/4Tx9hwGZFpk7nKdexU+DJn3?= =?us-ascii?Q?6P8xJflAHDcwaRlGof0aucsdnwvpdtXvWFUorYH5xr?= X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB459; 5:WRBNDqUoxzVHRt/D8JhArA0Fhu7hGiAxkNmtXV61RC+vY14sdCjj6KgxOskQ9OzjZYe78jKqkDzi1h6UhDG5uLsD1npnmQ2GWpC2eim6y2T9ctyb3Ewx9nwi6qikJ5ZptA2NZrqSa2E7zFR1WPasnQ==; 24:6iDn7ZuLNJo2jJlwyHPD7LHnFFfgKkF4SukcCsZSD1ifPx5QVVchXhJyknO0eK8JHryZ8WeO2X7JeQvyJ2L8WwDnFuOmYIfIg5rbhfpTxoI=; 20:cI7VgwH2VHRCC09u4e+8/xtUgbHD8L7u3Kds/2TN//L+glMxjl0QQTafsCggOWszrz7unKPSvQ/aSiMMup6rIQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Nov 2015 00:38:43.3384 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 Archived-At: Cc: Bruno Decraene , "sidr@ietf.org list" , Sandra Murphy , idr wg Subject: Re: [sidr] [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 00:38:52 -0000 Hi Robert, I didn't see any specific change requests in your followups to this = thread and indeed the changes in -05 are (I believe) consistent with the = positions you took, but in any case you might like to take a look at the = update. Thanks, --John > On Jun 12, 2014, at 5:06 PM, Robert Raszuk wrote: >=20 > Hi Bruno, >=20 > Glad we are in sync ;-) >=20 >> It's a priori not possible to define whether origin-validation shoud = have >> a low or high value compared to another possible existing usage. >=20 > Well I do not think it can be left as such. >=20 > The entire point of adding the new extended community for propagation > of origin validation result (valid, nf, invalid) is to accomplish > consistency in IBGP. >=20 > If you leave it open (ie not specified a priori) there is risk of > different selections of best path in your domain for a given net > (possibly with different exit points) . >=20 > Frankly since this ext community is non transitive one could also > depref the routes via local pref .. yes yes I can hear already voices > .. don't touch it - my local pref is for customers ! Except what this > draft defines will easily ignore all those customer local preferences > anyway ... IMO it is all about wisely choosing local pref values. >=20 > Cheers, > R. >=20 >=20 >> On Thu, Jun 12, 2014 at 9:45 AM, wrote: >>=20 >> Hi Robert, all >>=20 >>> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of = Robert Raszuk > Sent: Wednesday, June 11, 2014 10:26 PM >>>=20 >>> Hi Bruno & all, >>>=20 >>> Just focusing on Q1: >>>=20 >>>> 1) For people not following SIDR, could you please elaborate on = why >>>> http://tools.ietf.org/html/draft-ietf-idr-custom-decision-04 >>>> has not been used? (via the registration of a new Point of = Insertion >>>> specific to origin validation) (as I though draft-ietf-idr- >>>> custom-decision was intended to be the last time BGP decision = process >>>> would be modified) >>>=20 >>> Few observations: >>>=20 >>> A. draft-ietf-sidr-origin-validation-signaling does not really = modify a BGP best >>> path selection .. it adds a check before BGP best path selection = algorithm >>> kicks in. >>=20 >>=20 >> "3. Changes to the BGP Decision Process" >> [...] >> "When comparing a pair of routes for a BGP destination, the route = with the lowest "validation state" value is preferred." >>=20 >> My reading is that it does change the BGP decision process and the = relative priority of the routes. >>=20 >>> B. Adding new POI is not needed as we already have a POI =3D 128 = which is to >>> be executed before any step in BGP best path selection hence at = exactly the >>> same point as this draft recommends. >>=20 >> Using POI=3D128 is indeed an option. However in theory there could = already be existing usage of POI=3D128, hence possible conflict. In such = case, the sub-field "Community-ID" define the priority. It's a priori = not possible to define whether origin-validation shoud have a low or = high value compared to another possible existing usage. >>=20 >>=20 >>> therefor one obvious question comes in: >>>=20 >>> C. Based on A & B there is clear conflict not addresses in the = draft. >>> Assume both custom decision with POI =3D 128 "ABSOLUTE_VALUE" as = well as >>> origin validation are enabled. Moreover assume they result in = opposite >>> decisions. So the question of the day is: "Which of those two is the = one to >>> win the pre best path check ?" Effectively - which of those two is = more >>> important ? >>=20 >> You are reading my mind :-). >> I assumed that the first document becoming RFC freely define its = behavior and then the second will need to adapt (i.e. position itself = with regard to the first one). However, given that both documents are = worked in different WG, there is a risk that this is missed. >>=20 >>> The answer to this question should be included in the draft. And I = do suspect >>> authors of both drafts will answer: mine ! >>=20 >> :-) >> Indeed it's up to the authors/WG, but to me "Absolute" seems above = any other criteria. >>=20 >> Thanks, >> Bruno >>=20 >>> Thx, >>> R. >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or = privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Nov 5 16:39:27 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECD61A8033 for ; Thu, 5 Nov 2015 16:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 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, T_HTML_ATTACH=0.01] autolearn=unavailable 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 TUYAnDZVIh8M for ; Thu, 5 Nov 2015 16:39:19 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (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 C65781A86EC for ; Thu, 5 Nov 2015 16:39:10 -0800 (PST) Received: by pasz6 with SMTP id z6so107120450pas.2 for ; Thu, 05 Nov 2015 16:39:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=N4PgfKkbQnszHXC6eTctiGNN/9VxwEnA3jyFydPggQs=; b=T5MEKT7fEAKsE+3uhUcfA9iL0u3lI7XJpAPA6GaiBuPlwK4WZJ+iKZIU07YtXuLhXt giGDmH/aj9PzX2Kwz3N34v5FSWXgZq3ws2eu7ROpd+65POgaS/uifl/DNEOL/nuu9pcO uUnoPw3l1hFgW0Ea3VX3p4NNKNO+cZOs+KonI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=N4PgfKkbQnszHXC6eTctiGNN/9VxwEnA3jyFydPggQs=; b=F8Gpthh5veeG9dWured+nVWdhHDFYQ2fF39vmSgQb6QfV8o4b6lc7D7PhUjaanNlON g3wi9yD/wiD5z9D3aQV85ZvjU5zQXJmqefEG3Hkcc7LLfHm7909bN2lan7o9RZoOj9SE H7hChLThSinvjKd6bNCFIycR2g9ywueDB2KSoEhgty0VbOKYCFsyJPVkAuECujTleEKB ThIizStCSwpKmzWG8o96/11Iu9NmPhj99oZ06dQcV7R/wmTJiidr7A+KCQkXe5Bps2v9 5HFrJKiaQqwc3EQVRzMJBN0DL02gRND0SwWzz9nvK9wPIQ/Or/IxP3Sj/Xc0G9lpSUD7 Wxng== X-Gm-Message-State: ALoCoQlmdz936448ElrzkDDm6S5tLmHRWrbNg4QxwWEq17+tM63CX4+27BqMRB4oxVtsQ2146E+Q X-Received: by 10.67.13.107 with SMTP id ex11mr13427438pad.126.1446770350459; Thu, 05 Nov 2015 16:39:10 -0800 (PST) Received: from dhcp-28-27.meeting.ietf94.jp (dhcp-28-27.meeting.ietf94.jp. [133.93.28.27]) by smtp.gmail.com with ESMTPSA id ha1sm10046465pbc.54.2015.11.05.16.39.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Nov 2015 16:39:09 -0800 (PST) Content-Type: multipart/mixed; boundary="Apple-Mail=_95C083B6-E6AC-4345-A8CB-B3571115F4A0" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Sean Turner In-Reply-To: Date: Fri, 6 Nov 2015 09:39:02 +0900 Message-Id: <27FFEE52-A6D3-4CC3-8E94-E02420A82F53@sn3rd.com> References: To: Christopher Morrow X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "sidr-ads@tools.ietf.org" , "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Validation reconsidered draft status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 00:39:26 -0000 --Apple-Mail=_95C083B6-E6AC-4345-A8CB-B3571115F4A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Here=E2=80=99s a file that shows the differences between the two = procedures (I backed out the capitalization changes). text1 is in 6487 = (left) and text2 is in validation-reconsidered (right). spt --Apple-Mail=_95C083B6-E6AC-4345-A8CB-B3571115F4A0 Content-Disposition: attachment; filename=text2-from-1.diff.html Content-Type: text/html; name="text2-from-1.diff.html" Content-Transfer-Encoding: 7bit Diff: text1.txt - text2.txt
 text1.txt   text2.txt 
Validation of signed resource data using a target resource Validation of signed resource data using a signing key that is
certificate consists of verifying that the digital signature of the certified in a resource certificate, coupled with a specific set of
signed resource data is valid, using the public key of the target number resources, consists of verifying that the digital signature of
resource certificate, and also validating the resource certificate in the signed resource data is valid, using the public key that is
the context of the RPKI, using the path validation process. This certified by the resource certificate, and also validating the
path validation process verifies, among other things, that a resource certificate in the context of the RPKI, using the path
validation process.
This path validation process verifies, among other things, that a
prospective certification path (a sequence of n certificates) prospective certification path (a sequence of n certificates)
satisfies the following conditions: satisfies the following conditions:
1. for all 'x' in {1, ..., n-1}, the subject of certificate 'x' 1. for all 'x' in {1, ..., n-1}, the subject of certificate 'x'
is the issuer of certificate ('x' + 1); is the issuer of certificate ('x' + 1);
2. certificate '1' is issued by a trust anchor; 2. certificate '1' is issued by a trust anchor;
3. certificate 'n' is the certificate to be validated; and 3. certificate 'n' is the certificate to be validated; and
4. for all 'x' in {1, ..., n}, certificate 'x' is valid. 4. for all 'x' in {1, ..., n}, certificate 'x' is valid for the
specific set of resources.
Certificate validation entails verifying that all of the following RPKI validation for a specific set of resources entails verifying
conditions hold, in addition to the certification path validation that all of the following conditions hold, in addition to the
criteria specified in Section 6 of [RFC5280]: certification path validation criteria specified in Section 6 of
[RFC5280]:
1. The certificate can be verified using the issuer's public key 1. The certificate can be verified using the issuer's public key
and the signature algorithm and the signature algorithm
2. The current time lies within the certificate's Validity From 2. The current time lies within the certificate's Validity From
and To values. and To values.
3. The certificate contains all fields that MUST be present, as 3. The certificate contains all fields that MUST be present, as
defined by this specification, and contains values for specified by [RFC6487], and contains values for selected
selected fields that are defined as allowable values by this fields that are defined as allowable values by this
specification. specification.
4. No field, or field value, that this specification defines as 4. No field, or field value, that the [RFC6487] specification
MUST NOT be present is used in the certificate. defines as MUST NOT be present is used in the certificate.
5. The issuer has not revoked the certificate. A revoked 5. The issuer has not revoked the certificate. A revoked
certificate is identified by the certificate's serial number certificate is identified by the certificate's serial number
being listed on the issuer's current CRL, as identified by the being listed on the issuer's current CRL, as identified by the
CRLDP of the certificate, the CRL is itself valid, and the CRLDP of the certificate, the CRL is itself valid, and the
public key used to verify the signature on the CRL is the same public key used to verify the signature on the CRL is the same
public key used to verify the certificate itself. public key used to verify the certificate itself.
6. The resource extension data is "encompassed" by the resource 6. The resource extension data contained in this certificate
extension data contained in a valid certificate where this "encompasses" the entirety of the resources in the specific
issuer is the subject (the previous certificate in the context resource set ("encompass" in this context is defined in
of the ordered sequence defined by the certification path). Section 7.1 of [RFC6487]).
7. The certification path originates with a certificate issued by 7. The certification path originates with a certificate issued by
a trust anchor, and there exists a signing chain across the a trust anchor, and there exists a signing chain across the
certification path where the subject of Certificate 'x' in the certification path where the subject of Certificate 'x' in the
certification path matches the issuer in Certificate 'x + 1' certification path matches the issuer in Certificate 'x + 1'
in the certification path, and the public key in Certificate in the certification path, and the public key in Certificate
'x' can verify the signature value in Certificate 'x+1'. 'x' can verify the signature value in Certificate 'x+1'.
 End of changes. 6 change blocks. 
18 lines changed or deleted 23 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--Apple-Mail=_95C083B6-E6AC-4345-A8CB-B3571115F4A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 04, 2015, at 23:23, Christopher Morrow = wrote: >=20 > hurray! ambiguity in questions was raised by an interested party... >=20 > I'd rather do this Friday at the end of the meeting with a short > presentation/conversation. >=20 > -chris >=20 > On Tue, Nov 3, 2015 at 8:21 PM, Christopher Morrow > wrote: >> During the meeting today (tues 11/3/2015) one of the authors of: >> draft-ietf-sidr-rpki-validation-reconsidered >>=20 >> noted that after the last set of updates and over the history of the >> document (2+yrs) there's been no real support nor direction from the >> working-group. Additionally, all co-authors noted that the lack of >> support and direction meant that abandoning the draft seemed like the >> best current direction. >>=20 >> The primary author: Geoff Huston (gih@apnic.net) is willing to toss >> the XML over the fence to another author/editor if there is interest, >> or to let the draft expire/die if no one is willing to take up the >> pencil. >>=20 >> Over the next three weeks let's discuss the direction/end-goal and >> determine if 'abandon' or 'new author' is the best course of action >> here. >>=20 >> -chris >> sidr-co-chair >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_95C083B6-E6AC-4345-A8CB-B3571115F4A0-- From nobody Thu Nov 5 16:40:32 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5FB71A1A7D; Thu, 5 Nov 2015 16:40:28 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJCHNZTVDMWh; Thu, 5 Nov 2015 16:40:24 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0130.outbound.protection.outlook.com [65.55.169.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5041B1A871E; Thu, 5 Nov 2015 16:40:24 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from jfujimiya-sslvpn-nc.jnpr.net (122.216.203.186) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.312.18; Fri, 6 Nov 2015 00:40:17 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "John G. Scudder" In-Reply-To: Date: Fri, 6 Nov 2015 09:39:52 +0900 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: "George, Wes" X-Mailer: Apple Mail (2.2104) X-Originating-IP: [122.216.203.186] X-ClientProxiedBy: HK2PR04CA0011.apcprd04.prod.outlook.com (25.162.205.149) To CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB458; 2:+vyCRQIeYzq7rWV1hhq+L42TObmYj6KRaKO4pcWkO+khL0QrOdZYj2IkCK3SI2uvSL/ykTz0Tj9fqdpEXx2MagosWdya52cEAHPKmzR7+YZd9G1a6SBfTGXBZyM322r3FyKxLPYc9fqsBy9KPHoYqInIO3vaaqqoig8dvdZCgd4=; 3:d8US7USAXh8SsOFpvy/9hJhJWzerXSkmVSRy3XjGO8PXNJEmjUXB/meB4TQhO3LqwC5pPnnOvVis8+TCKcJ/IUgEB01kM74gVlnsQKZkWyngrYtusPBiBBUwVDctTS3G/SRnHzCfi4kninawMIIeTw==; 25:i7rTjPxjuoUp5f023gDTEVOmZ4GpdeO7vx5FmQxEI3aHmwk+ix5KbgNPOnm1q31xBFOTdvu9O4zcUjLZ9CikJFY8RLUY7idaURDIcrPZwxYE7kEVTjElabZKm9Bx1asSWhMnO62OSm4xVqdYuHRCW9rBTleZ6ecFv/R4e7EUBZOSfIV+3KTSAJf7ZM23pabhKTawQUgCwO4MuK2UAKViBcDdq+K/aPWKa+T6vy6IkABMEFXD/ExoH8GOoyaKTyHYEu30TaRc1cSnOc0VpH9mbQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; X-LD-Processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB458; 20:W38PBzVs2WQeNfSOo9xb7Oid9duAO3sygOB6LkM1xQTa1589tohHyS8wvuHwM/Zyqr4DVgExgaB9VmPq7+U0V0bYW7UGHMnT8pe9IFdbPU2FwFKfDKzIXbT8BSjtqGm6bR2Eq96g2630vDPpRKpU9msBHCZ32npz+naX4Z23HEKSIUICUMkDauWuVtmlHJudaca2PWUZsRz9hS4XMZ0MtUIAh2NPwIHlxoIqdteEiIRnOKB8KuJPjS0dWpfqeFYM6wmgIP5/21md4UaZOlV+XBzLrhEnWnw80zGLHd8GL5HTygBMPZJJ7o9BfGqdbauRZ7+gHBTDPOGMabekJn+8sw1DEG7FvA0LwTCA+nN3zD7KZdDZ40265ZVxbBP/yIIGo+cnHfKt7Hbna7Ugi+oYVEELbX8yWpVVVzHVWPaEVIy9Qc9izxqqb0lBoQev7DMpRif7d7Qo5FGgpedobEI+zJAx55LRA2sl0uilZ+FB7wJmrthgPvsT35Y3X4AF43Dt; 4:3rAOhDHmXW77VkFzFCJR987PW0lWQj8WD/zKfAHIl39wBvrW6SQJmGwGgJ/Vbh91gJDf5ctCI7FNGeZnIH5f5DhH/GWDPwZntc3Old3NaIgwhIjYXFNmkGgSkpt1WwtpNSjpoUp6rGvL/k0Wx/gnATlU0a3GsQkN9nxyQ9ehhHIpwBoET+znf1lBeihULKJMxvu/+c/l9tgFaVPc+je4RTmHbFRPSwlGjh4pqBymwwfv4T2mxgmrAWtx9BWirVoMhDKZ1xtlT01YEIVKHDRcARtesVw4dng2xOLuvtsiacTc8KYIayyJLmbP6t4PXOI/bkH3UfQCmpO3sePqJoEzZ+wLTgUOGDztmFXCqJh1sa3+2U1OXPsbxyZV/rRIkggR X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(3457453519779)(18271650672692); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; X-Forefront-PRVS: 07521929C1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(377454003)(24454002)(164054003)(51694002)(479174004)(82746002)(19580395003)(33656002)(81156007)(97756001)(86362001)(105586002)(69596002)(66066001)(97736004)(76176999)(50986999)(83716003)(42186005)(46406003)(110136002)(50226001)(101416001)(47776003)(2950100001)(40100003)(5004730100002)(50466002)(23726002)(57306001)(92566002)(19580405001)(5007970100001)(5001960100002)(77096005)(122386002)(87976001)(53416004)(230783001)(36756003)(189998001)(106356001)(5008740100001)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:jfujimiya-sslvpn-nc.jnpr.net; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO1PR05MB458; 23:ZnYobpg1aHhU/VUj5Zpgb/pvMzE272q4Ua+GBVH/pK?= =?us-ascii?Q?ashqITcOVL+NLG+mWMjxHrEEkcpAujQoSxX4acGYDNHbCzETHPAuOS673XA+?= =?us-ascii?Q?nApD5phQ81nzU5p+ZmyKWJA4ZuB/mc5G7poKcg+t9kT/jJ0ngKzYxAYRbCSI?= =?us-ascii?Q?wW7pIs1lOb2GtKeYBjdydZo42+eFAcvJkOeXAvX9sBMWUb7NLipdzS1fI5gc?= =?us-ascii?Q?JZiMzt97Q/1yxgJk9FmE6fkQ/gtvucTr7nQ0QpX0isM4qF0nfM6W8TbXWuIW?= =?us-ascii?Q?Ol9umm727f0+ZAwgH6C18kxsE7Y03TTPZTBF1tvTp7YsgdxEd4qLZ89wsmZA?= =?us-ascii?Q?QBbyCaVM0IgMb3VOnW890muxvla5TK0VPgVFyxpNnMdCftU3qdYJ2oiawirB?= =?us-ascii?Q?3BAk+I8ef/VaRuCfjV26WdjH4ouDcWQZNAmk8V4CaV4Uj6EDs6nl9dWdcbHx?= =?us-ascii?Q?NJ+3wlOH3bj2bZFAbWkhXxwdhfPB+JPSpDsrDCMg67zH11lJXTBZ0B+WaZHU?= =?us-ascii?Q?E8W55gL56v032bnbg+iAfrTyTCfLZVum/eiMgP+J8H+Neh8QXQ96zwXgvXPU?= =?us-ascii?Q?w7QRFoMM7PbvZslCGEuO04grFBvpRtjvN2Q1ruv2ca6ccMWfuMg3m5QD9pYK?= =?us-ascii?Q?Bm1h+EIigWRmJBSPsg0W9Bc9a7MjM0acnJn2bTnONrTx2RPqwyUy0+W5uttC?= =?us-ascii?Q?jC5NzSa1u3tRoP8iPVp0Bd1KEZ48NiOTrAFXXvivcPsmajr1KslE0B1laIRV?= =?us-ascii?Q?NDlGcaSky6RhxNhLEaMesmNrsTn4ia99rwde/C28d+v0vmrlfDm1UHxoCYOX?= =?us-ascii?Q?IcMRJt515wp8h2raM3vCRK1f+5uMIxQVtH4qqBbYWf8iQSCAuK9J05bCobcr?= =?us-ascii?Q?xtpmoJ5RVm9U3B1XKZ3DLGOexoUK4FYFIwWEqxmyJpTY0JpSmGvN/Bz9LrKo?= =?us-ascii?Q?nGzIIR5P3PvxkUti3PxI8pwNj8bS1UCF1DCPSupM/w0aZTeOb7hmMb24LY5N?= =?us-ascii?Q?CO01usAUcaAzjcP/Fg8+ZvIrhB9dRWD7ZKUafo//RI8V2wWOZ9Wnf/2Szakl?= =?us-ascii?Q?/EZ2Tnqj5jk3n2tmGFdHIKh6502EzHcgqXYa5SwZygREPB1CyhErMHTZSsPk?= =?us-ascii?Q?YVzwR+NAjIwaVDyZ2zWrj3SqjdY88cHfYdWHZy2ififKnPyf8oSpiG/5HlwE?= =?us-ascii?Q?673MnWMLLVNjugAt80q3HAQh+qpdVe0ucXRF6n36NWyniBWq7Xnf7cdbm9tT?= =?us-ascii?Q?nREfucky9i/Y0jqmA=3D?= X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB458; 5:eK7TApeDkKi8S/dc5qtxxzeBmrnJFKfZZntpzD1MWOPq7yiRgazgrE7NqGeZMtkJwW9y0nsMvxh8IOdxVqAZfyDEdzCKpyqeznFJJo/1vRYm/k046VsytmBaHaUl2Sw1UkX5xNNaP+dpc6vFnGqmvQ==; 24:7FJwMFvL2EmBENftcOIajSccpLVIgQcM3TFaV98E/gwgHsIE2l1t5WAUOGpvDeSeN+5hCC6XWZEhLzXrqlFJMPFnsBU82q+U50VWb3G5zKk=; 20:nLFoNMjKsuTTcwkWj9FypqgF0LMUe0Zt1vUvOObYnYJuo9NqyijpbyVbJRWnFk7OPYYa3N1i51EhXWbqFBs2qw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Nov 2015 00:40:17.9365 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Cc: "bruno.decraene@orange.com" , "sidr@ietf.org list" , idr wg Subject: Re: [sidr] [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 00:40:29 -0000 Hi Wes, I believe -05 should work for you -- we updated it to say 'don't leak = across AS boundaries unless configured to do so'. Presumably in your = case you would do that configuration. Thanks, --John > On Jun 14, 2014, at 12:25 AM, George, Wes = wrote: >=20 >=20 > On 6/13/14, 5:07 AM, "bruno.decraene@orange.com" > wrote: >=20 >> If this is the choosen way, = draft-ietf-sidr-origin-validation-signaling >> should also say that: >> - ASBR should remove such community from routes received over eBGP >> sessions (possibly modulo confederation, 2 AS from the same >> organization/trusted...) >> - this community must not be used in the AS until all ASBR are = upgraded >> to support draft-ietf-sidr-origin-validation-signaling >=20 > Just wanted to note that as an operator of a network where my = Autonomous > System (i.e. The span of the network under common control) spans = multiple > Autonomous System NUMBERS, these carve-outs to handle confeds and = multiple > ASNs from same org are pretty important if I am to implement Origin > Validation. Being able to validate at external ASBRs and keep that = info > across the internal ASN boundaries would make a deployment in networks > like mine much simpler than if we have to revalidate at the internal = ASBRs. >=20 > Thanks > Wes George From nobody Thu Nov 5 17:52:16 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277C11B2AC1; Thu, 5 Nov 2015 17:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Yf5uuEwQzF7; Thu, 5 Nov 2015 17:52:13 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::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 C364E1A8788; Thu, 5 Nov 2015 17:52:13 -0800 (PST) Received: by ykdv3 with SMTP id v3so75960569ykd.0; Thu, 05 Nov 2015 17:52:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=SwaW3gcIhP1kmjuV+kAwAeW058MjCY23OhYy8WG/WIk=; b=fIFHwfCSsBdowWvWayo1CRFlH+MsuOIcTJWj+exXLCxndrgGkFpHgjSaKdYeby8S6c yH9zlCDvzeeiRJJ2XZ/A/mbkuGhFKxRII8mhTzPlqpkCX0U3QnRBiVvTYsCSJVmJoCNJ a2uNqvc/m1Cg+mmz8lsIaHWfrC20iLY9JWg8a2liRwMAE1DD+zt+ey8PUGDwbMsuu09H sGRx4Gb5lrTDNEda6l351gV7xm+v8sODssExftuFMdzfqnTWd5svFxrCF7ugxrvCgc9P wqCHusjEkMmBfvUWddmEYxGOeVlI+fwCRU0cxLh44IANY3khlUH/RrOWI4Zlroib/mOf kwLw== MIME-Version: 1.0 X-Received: by 10.129.71.6 with SMTP id u6mr10713344ywa.247.1446774733068; Thu, 05 Nov 2015 17:52:13 -0800 (PST) Received: by 10.13.202.16 with HTTP; Thu, 5 Nov 2015 17:52:13 -0800 (PST) Date: Fri, 6 Nov 2015 12:52:13 +1100 Message-ID: From: Christopher Morrow To: "sidr@ietf.org" , "sidr-ads@tools.ietf.org" , "sidr-chairs@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 01:52:15 -0000 Please take 2 weeks time to consider: "This document was adopted as a WG work item, should we accept this change and complete the work or not?" where: 'this document' is: I'll close the mic line on: 11/20/2015 Nov 20, 2015 -Chris sidr-co-chair From nobody Thu Nov 5 17:56:12 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E4B1B2B01; Thu, 5 Nov 2015 17:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pX09m0cSTGbt; Thu, 5 Nov 2015 17:56:08 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (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 8B1C81B2B14; Thu, 5 Nov 2015 17:56:08 -0800 (PST) Received: by pabfh17 with SMTP id fh17so105178832pab.0; Thu, 05 Nov 2015 17:56:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=4MvVtiRhbnqXHCQlSSe/NjxSXBApD91q8p5nSvXBbeI=; b=WTpGjYoJhGF5fg0NYHGDndHGF7poe7eelKKAPNlLLJ1/vjETQKHycvFix994WFNUCR rcmrzBae3GiK0FhkxZn5qpMBdxJegREtAIQwuJ59oYf2WDUBVo5pf4Yy88chqxqF/mfb L1vClbH5gc7TC2xm9eNQ6Tjxv+Ton5bNEOC1N7CNWodljknwuuEWp8KhW5fktM71ODKJ C222YXjKP2lLclADl5dl9wewt/kAzfkEUPKQnevLb5CQpyKouhKiIQSr8wGDuwKWdqgj A4HkXzywHo0XaexI8bc70cb19ZQ3VvIHpHGZSmRtbyE2yYcxAf2WTbgY5tudjBAI5bFj fgVQ== X-Received: by 10.66.216.233 with SMTP id ot9mr13503457pac.148.1446774968159; Thu, 05 Nov 2015 17:56:08 -0800 (PST) Received: from kafka.local (dhcp-27-20.meeting.ietf94.jp. [133.93.27.20]) by smtp.googlemail.com with ESMTPSA id rz9sm10233407pbb.61.2015.11.05.17.56.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Nov 2015 17:56:07 -0800 (PST) References: To: Christopher Morrow , "sidr@ietf.org" , "sidr-ads@tools.ietf.org" , "sidr-chairs@ietf.org" From: "Carlos M. Martinez" Message-ID: <563C08B2.4000800@gmail.com> Date: Fri, 6 Nov 2015 10:56:02 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 01:56:09 -0000 Aside from process questions (whether should the draft update a standard or nor), I definitely believe the WG should continue working on this. -Carlos On 11/6/15 10:52 AM, Christopher Morrow wrote: > Please take 2 weeks time to consider: > > "This document was adopted as a WG work item, should we accept this > change and complete the work or not?" > > where: > 'this document' is: > > > > I'll close the mic line on: 11/20/2015 > Nov 20, 2015 > > -Chris > sidr-co-chair > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From nobody Thu Nov 5 18:00:01 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B19A1B2B91 for ; Thu, 5 Nov 2015 18:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQ-3Sn2cHz_7 for ; Thu, 5 Nov 2015 17:59:59 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::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 0F3321B2B85 for ; Thu, 5 Nov 2015 17:59:59 -0800 (PST) Received: by pacdm15 with SMTP id dm15so81084713pac.3 for ; Thu, 05 Nov 2015 17:59:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=hsHy/QLUpg0u1XJYYttgJGwrAFdzo+rn865zTsmHkr4=; b=ZoTHW1XvKO4az+7523sb4u1jB7I9UWRPDvCDgZmsEE1F72rE7TOh6gP6AttnPiGpdJ xnXfWGAYRB7KzyPl+D/Zd0CquqczMqRqLBqVW06DfplfJkAWjaikvSIJvPvDmv9k1YZ7 R1Y9JnlsC5Tz31hrrGfFg2T8HTjwoMXDSthiz7Bz/dUhQYV002s9qMRXjo1iLmHIFrqB 8A5DcJXA0apD43XYrp9C9M4YJUz2xbCVJHRPoTYPdeE/LPcMWQ4531/Jip/aZg0zywhe a4yVNPDcv0VPjQf+WZ5AqWkih5Mu1FkStPtTWroHpLvbCFDwIFsB6dkzFnwnWhS102NH SOkA== X-Received: by 10.68.105.197 with SMTP id go5mr13543678pbb.126.1446775198720; Thu, 05 Nov 2015 17:59:58 -0800 (PST) Received: from kafka.local (t20010c400000302430df5d6f86c36d37.v6.meeting.ietf94.jp. [2001:c40:0:3024:30df:5d6f:86c3:6d37]) by smtp.googlemail.com with ESMTPSA id qd2sm10238964pbb.68.2015.11.05.17.59.57 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Nov 2015 17:59:58 -0800 (PST) References: <563BC1E3.40100@bbn.com> To: sidr@ietf.org From: "Carlos M. Martinez" Message-ID: <563C0987.4010200@gmail.com> Date: Fri, 6 Nov 2015 10:59:35 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563BC1E3.40100@bbn.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sidr] Validation reconsidered draft status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 02:00:00 -0000 Karen, I disagree with your position. Our draft does not explore adverse actions nor discuses transfers. It is not the same topic. -Carlos On 11/6/15 5:53 AM, Karen Seo wrote: > Folks, > > I think the authors have brought up some pertinent issues which have > helped inspire other work which subsumes them. So I thank them but > agree that it seems appropriate to drop this draft since those issues > are now being covered in other documents and those documents have > additional detail. Randy's I-D discusses INR transfers. Steve's draft > on adverse action provides a detailed analysis of the "operational > fragility" of the RPKI in the face of attacks and errors. So, if the > adverse actions draft is adopted by the WG, we (the WG) could use the > requirements stemming from these two IDs as the basis for a solution(s) > document. Just personal preference, but I also find having one document > per topic/issue (at least when they're as complex as is the case with > the threat analysis) easier to follow and would also like to separate > defining of issues and their requirements from describing the solution. > > Respectfully, > Karen > > On 11/3/15 4:21 AM, Christopher Morrow wrote: >> During the meeting today (tues 11/3/2015) one of the authors of: >> draft-ietf-sidr-rpki-validation-reconsidered >> >> noted that after the last set of updates and over the history of the >> document (2+yrs) there's been no real support nor direction from the >> working-group. Additionally, all co-authors noted that the lack of >> support and direction meant that abandoning the draft seemed like the >> best current direction. >> >> The primary author: Geoff Huston (gih@apnic.net) is willing to toss >> the XML over the fence to another author/editor if there is interest, >> or to let the draft expire/die if no one is willing to take up the >> pencil. >> >> Over the next three weeks let's discuss the direction/end-goal and >> determine if 'abandon' or 'new author' is the best course of action >> here. >> >> -chris >> sidr-co-chair >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Nov 5 18:09:55 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028A91B2B91; Thu, 5 Nov 2015 18:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYwMlymURR9n; Thu, 5 Nov 2015 18:09:47 -0800 (PST) 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 86E5E1B2BF3; Thu, 5 Nov 2015 18:09:47 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1ZuWTH-000C6G-V9; Fri, 06 Nov 2015 03:09:45 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-89.ripe.net) by titi.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1ZuWTH-0005dq-CM; Fri, 06 Nov 2015 03:09:43 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Tim Bruijnzeels In-Reply-To: <563C08B2.4000800@gmail.com> Date: Fri, 6 Nov 2015 11:09:38 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <9D13F35E-CC9B-4BDB-9203-97A890A68B41@ripe.net> References: <563C08B2.4000800@gmail.com> To: carlos@lacnic.net X-Mailer: Apple Mail (2.2104) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07194d5cf01216146d7994b10779db88e4e8 Archived-At: Cc: Christopher Morrow , "sidr-ads@tools.ietf.org" , "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 02:09:54 -0000 > On 06 Nov 2015, at 10:56, Carlos M. Martinez = wrote: >=20 > Aside from process questions (whether should the draft update a = standard > or nor), I definitely believe the WG should continue working on this. +1 Tim >=20 > -Carlos >=20 > On 11/6/15 10:52 AM, Christopher Morrow wrote: >> Please take 2 weeks time to consider: >>=20 >> "This document was adopted as a WG work item, should we accept this >> change and complete the work or not?" >>=20 >> where: >> 'this document' is: >> = >>=20 >>=20 >> I'll close the mic line on: 11/20/2015 >> Nov 20, 2015 >>=20 >> -Chris >> sidr-co-chair >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >>=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Nov 5 21:04:31 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F111B359C for ; Thu, 5 Nov 2015 21:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.801 X-Spam-Level: X-Spam-Status: No, score=-101.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzcIkJow9jVY for ; Thu, 5 Nov 2015 21:04:28 -0800 (PST) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) (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 105F11B3597 for ; Thu, 5 Nov 2015 21:04:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=xbh9R/BQu8rOBrFAv/SG5g7crwx/LcYu2+hSlla94U8=; b=grP6P3psB3W4jAf1TZwYmw3p3J3UIuTVYeiMZQq9NKIN+UM54UtFghXOTNYi7GmPNMpfEr5rCwjkb zrYpuY+yii6VwgePxgyhFEAOWQqPulgh39Ms0e/cVnjgZNRKwKOjLyoR0qkAbsDvMzYpsIsZrZbtZG +H5nvZcLO+9XXn1M= Received: from iamda3.org.apnic.net (unknown [IPv6:2001:dd8:9:2::101:249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS; Fri, 6 Nov 2015 15:04:24 +1000 (AEST) Received: from [10.111.152.8] (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.1.218.12; Fri, 6 Nov 2015 15:04:28 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Geoff Huston In-Reply-To: Date: Fri, 6 Nov 2015 16:04:21 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <3E651EC9-A059-4CB0-9873-C4338B3A361B@apnic.net> References: To: Christopher Morrow X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "sidr-ads@tools.ietf.org" , "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 05:04:30 -0000 > On 6 Nov 2015, at 12:52 PM, Christopher Morrow = wrote: >=20 > Please take 2 weeks time to consider: >=20 > "This document was adopted as a WG work item, should we accept this > change and complete the work or not?=E2=80=9D >=20 I say =E2=80=9CYes," for some value of somebody/some people completing = the work that is !=3D me thanks, Geoff From nobody Thu Nov 5 21:17:09 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645281B35F7 for ; Thu, 5 Nov 2015 21:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eE1j6RrIYhnJ for ; Thu, 5 Nov 2015 21:17:07 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::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 866F81B35FB for ; Thu, 5 Nov 2015 21:16:57 -0800 (PST) Received: by padhx2 with SMTP id hx2so102530568pad.1 for ; Thu, 05 Nov 2015 21:16:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oJhJoqzS7ee3sBEtvrMCQ6nbiLqol6OQBcVe+JN5R6g=; b=lGZbq89+v/011vl1dVluwkLdr6fx1/XKdLtEz/sTsBa6qLO0hxUzirNIkQ1OeRvbAJ Wm0qNTF+Pg986EorhHxgXmgwH8AsmS3LWpSOUlT4OM/c9VEjzQOBh9B56f6xlQxAew+j yXp/47ek1HX9/VSz0TMlLLZj1ZUhWXNFFSimGkXXntD6Wm6j6/H0vx1wxSsshYdHdE7G 06avcmNsoriGQnj4MKReb14WgCFV6PbXf1I7+enFG9C3hRCd8gVzkQlSW//cUHn/Jv/A WzkM8mSQKsOeOGF7nxg0t3EeISENle3DDg0Mfh3NvN9shR4GyRRJUHGbkLWWesnAxKyp h52Q== X-Received: by 10.66.102.101 with SMTP id fn5mr5884097pab.66.1446787017148; Thu, 05 Nov 2015 21:16:57 -0800 (PST) Received: from [10.111.152.8] (122x210x83x163.ap122.ftth.ucom.ne.jp. [122.210.83.163]) by smtp.gmail.com with ESMTPSA id sb4sm2784095pbb.55.2015.11.05.21.16.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Nov 2015 21:16:56 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Geoff Huston In-Reply-To: <563BC1E3.40100@bbn.com> Date: Fri, 6 Nov 2015 16:16:51 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <7BCB6406-E37D-4171-9D9B-9867BE4B822A@gmail.com> References: <563BC1E3.40100@bbn.com> To: Karen Seo X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] Validation reconsidered draft status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 05:17:08 -0000 I disagree with the assertions Karen > On 6 Nov 2015, at 7:53 AM, Karen Seo wrote: >=20 > Folks, >=20 > I think the authors have brought up some pertinent issues which have = helped inspire other work which subsumes them. So I thank them but = agree that it seems appropriate to drop this draft since those issues = are now being covered in other documents and those documents have = additional detail. this is the overall assertion that I disagree with. > Randy's I-D discusses INR transfers. This is just one way to think about certificate-mediated transfer of = resources between address registries. It does not necessarily address = the brittleness of the overall RPKI when using the existing validation = algorithm. > Steve's draft on adverse action provides a detailed analysis of the = "operational fragility" of the RPKI in the face of attacks and errors. As I said in the working group meeting, I oppose the adoption of this = draft. It is by no means a complete list of =E2=80=9Cthings that could = go wrong=E2=80=9D and as we continually find out in operations each and = every day, what actually surprises us that goes wrong is stuff that we = never expected to go wrong. This document pretends to be a comprehensive = list of all things that could go wrong and such a pretension is at best = a dangerously mistaken one. The suggested remediations rely on = unspecified mechanisms that are at best using a liberal application of = magic. It leads to a misapprehension that nothing else could ever go = wrong, and therefore if we just concentrate on these things the result = would be operationally perfect. I have yet to see such a theory of how = to attain operational perfection withstand even one week in the field. > So, if the adverse actions draft is adopted by the WG, we (the WG) = could use the requirements stemming from these two IDs as the basis for = a solution(s) document. And that in a nutshell is exactly why I oppose the adoption of this = document. It appears to me that this step assumes that the adverse = actions has catalogued avery possible problem and now all we need to do = now is to replace the magic placeholders with some action or other. = I=E2=80=99m sorry but this premise is just not realistic and this = approach in the draft is just not realistic for me. > Just personal preference, but I also find having one document per = topic/issue (at least when they're as complex as is the case with the = threat analysis) easier to follow and would also like to separate = defining of issues and their requirements from describing the solution. Just personal preference, but I would like the Working Group to address = some basic design issues here that invoke brittleness in all kinds of = known and unknown ways rather than play hunt the wumpus with some = supposedly comprehensive list of everything that could ever possibly go = wrong. ever. regards, Geoff From nobody Thu Nov 5 23:07:44 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5039F1B2C7D for ; Thu, 5 Nov 2015 23:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.151 X-Spam-Level: X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rg4kRG_xhH6S for ; Thu, 5 Nov 2015 23:07:40 -0800 (PST) Received: from mail.zdns.cn (smtp.knet.cn [202.173.10.15]) by ietfa.amsl.com (Postfix) with SMTP id 519A61B2C67 for ; Thu, 5 Nov 2015 23:07:39 -0800 (PST) X-TM-DID: d50850db41bad3e672a5728299c2303d Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Declan Ma In-Reply-To: <7BCB6406-E37D-4171-9D9B-9867BE4B822A@gmail.com> Date: Fri, 6 Nov 2015 15:07:01 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <563BC1E3.40100@bbn.com> <7BCB6406-E37D-4171-9D9B-9867BE4B822A@gmail.com> To: Geoff Huston X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] Validation reconsidered draft status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 07:07:43 -0000 > =D4=DA 2015=C4=EA11=D4=C26=C8=D5=A3=AC13:16=A3=ACGeoff Huston = =D0=B4=B5=C0=A3=BA >=20 > I disagree with the assertions Karen >=20 >=20 >> On 6 Nov 2015, at 7:53 AM, Karen Seo wrote: >>=20 >> Folks, >>=20 >> I think the authors have brought up some pertinent issues which have = helped inspire other work which subsumes them. So I thank them but = agree that it seems appropriate to drop this draft since those issues = are now being covered in other documents and those documents have = additional detail. >=20 > this is the overall assertion that I disagree with. >=20 >=20 >> Randy's I-D discusses INR transfers. >=20 > This is just one way to think about certificate-mediated transfer of = resources between address registries. It does not necessarily address = the brittleness of the overall RPKI when using the existing validation = algorithm. >=20 >=20 >> Steve's draft on adverse action provides a detailed analysis of the = "operational fragility" of the RPKI in the face of attacks and errors. >=20 > As I said in the working group meeting, I oppose the adoption of this = draft. It is by no means a complete list of =A1=B0things that could go = wrong=A1=B1 and as we continually find out in operations each and every = day, what actually surprises us that goes wrong is stuff that we never = expected to go wrong. This document pretends to be a comprehensive list = of all things that could go wrong and such a pretension is at best a = dangerously mistaken one. The suggested remediations rely on unspecified = mechanisms that are at best using a liberal application of magic. It = leads to a misapprehension that nothing else could ever go wrong, and = therefore if we just concentrate on these things the result would be = operationally perfect. I have yet to see such a theory of how to attain = operational perfection withstand even one week in the field. >=20 Geoff, The way I think about =A1=B0things that could go wrong=A1=B1 is = different from you. No one can enumerate all specific and concrete security problems as we = are moving forwards with RPKI deployment and operations. But reviewing RPKI operation security on the whole and establish a = threat model is necessary as people did in other areas. One can easily = find a bunch of RFCs that are intended to do so. RFC 3833 Threat Analysis of the Domain Name System (DNS)=20 RFC7132 Threat model for BGP Path Security=20 RFC7375 Secure Telephone Identity Threat Model. for instance. And the adverse actions draft is intended to well shape the RPKI = operation security problems by offering taxonomy that helps seek = security mechanisms to safeguard RPKI operations. Di >=20 >> So, if the adverse actions draft is adopted by the WG, we (the WG) = could use the requirements stemming from these two IDs as the basis for = a solution(s) document. >=20 >=20 > And that in a nutshell is exactly why I oppose the adoption of this = document. It appears to me that this step assumes that the adverse = actions has catalogued avery possible problem and now all we need to do = now is to replace the magic placeholders with some action or other. I=A1=AF= m sorry but this premise is just not realistic and this approach in the = draft is just not realistic for me. >=20 >> Just personal preference, but I also find having one document per = topic/issue (at least when they're as complex as is the case with the = threat analysis) easier to follow and would also like to separate = defining of issues and their requirements from describing the solution. >=20 >=20 > Just personal preference, but I would like the Working Group to = address some basic design issues here that invoke brittleness in all = kinds of known and unknown ways rather than play hunt the wumpus with = some supposedly comprehensive list of everything that could ever = possibly go wrong. ever. >=20 >=20 > regards, >=20 > Geoff >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Nov 5 23:08:20 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0581A1B2EEE for ; Thu, 5 Nov 2015 23:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxn4kmZ6aezv for ; Thu, 5 Nov 2015 23:08:17 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D9A61B2C67 for ; Thu, 5 Nov 2015 23:08:17 -0800 (PST) Received: from [128.89.255.115] (port=57991 helo=Johns-MacBook-Pro.local) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Zub8B-0000lf-NB; Fri, 06 Nov 2015 02:08:15 -0500 To: Geoff Huston References: <563BC1E3.40100@bbn.com> <7BCB6406-E37D-4171-9D9B-9867BE4B822A@gmail.com> From: Karen Seo Message-ID: <563C51DF.4070501@bbn.com> Date: Fri, 6 Nov 2015 02:08:15 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <7BCB6406-E37D-4171-9D9B-9867BE4B822A@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] Validation reconsidered draft status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 07:08:19 -0000 Geoff, >> So, if the adverse actions draft is adopted by the WG, we (the WG) could use the requirements stemming from these two IDs as the basis for a solution(s) document. >> >> And that in a nutshell is exactly why I oppose the adoption of this document. It appears to me that this step assumes that the adverse actions has catalogued avery possible problem Sorry for not being clear. I did not mean to imply that this work is 100% complete or to pre-empt the WG's right to modify the draft and decide when it is complete. It could well be, as you suggest, that the adverse actions draft requires extension and modification. And that is the WG's prerogative. However, I do believe this draft provides a good starting place for WG collaboration on the issue of what threats are faced by the RPKI and how they would impact it. And such an analysis (once vetted and approved by the WG) would provide useful input towards picking which vulnerabilities most need addressing and how to address them, even if the analysis was not 100% comprehensive. >> and now all we need to do now is to replace the magic placeholders with some action or other. I’m sorry but this premise is just not realistic and this approach in the draft is just not realistic for me. I'm confused by this statement. The threat analysis/attack model does not magically produce solutions. What the draft does (IMHO) is to methodically go through possible attacks and describe the resulting impact if the attack is successful. Whether or not the list of attacks is 100% complete, one can use the analysis to (a) prioritize the identified attacks/vulnerabilities as to impact (and therefore importance to mitigate) (b) generate the corresponding requirements for the solutions and (c) identify those attacks/vulnerabilities for which no reasonably feasible mitigation can be found, so that we know those dangers remain. I agree that the more complete the analysis the better but I wouldn't throw out the approach. > Just personal preference, but I would like the Working Group to > address some basic design issues here that invoke brittleness in all > kinds of known and unknown ways rather than play hunt the wumpus with > some supposedly comprehensive list of everything that could ever > possibly go wrong. ever. regards, Geoff Could the problem cases you mention in your draft be added to the adverse actions draft? For example, there are categories for when the CA makes various kinds of errors. Thank you, Karen From nobody Fri Nov 6 13:06:47 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42661A1A60; Fri, 6 Nov 2015 13:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9APBSh03Q5i; Fri, 6 Nov 2015 13:06:45 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (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 39D631A1A5A; Fri, 6 Nov 2015 13:06:45 -0800 (PST) Received: by ykdv3 with SMTP id v3so107999835ykd.0; Fri, 06 Nov 2015 13:06:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=jcpEQsVDv4m73owfcEi7Dv/IIcm9Nyisk16hcxDL9a4=; b=BfEdpbncOxUMSxd1+J8E49lcvPfYFKkl7W1g5aSLXjLZpWM7rNzES83z6DALSm9dJ+ d09vcTTiAMZv+KLl/U0OvKA7+oT2CMo0nO4XAh2mEcgvFogKboPcDR0DL8IJvbW2UeF5 hbRxIxAeZNADPiMho5tE2K/vPII/bLn16nJXm9+1xjeCBgapiNtIHA0rGe2Hd28+ViYu /aSneTZ0HZqoRhwu8Ozr7kJI5tgc7IQG4aDgc7KxVqqdqHiIiY7fY60HUPU8w0xjyCsL iiKczaTzkmeSoniwFjZJz3LnHOvdJoD0InDMPtyHGauJaSQM1muvSxQkxtC7yQEVRulf GOYw== X-Received: by 10.13.198.194 with SMTP id i185mr12843768ywd.124.1446844004550; Fri, 06 Nov 2015 13:06:44 -0800 (PST) MIME-Version: 1.0 References: <3E651EC9-A059-4CB0-9873-C4338B3A361B@apnic.net> In-Reply-To: <3E651EC9-A059-4CB0-9873-C4338B3A361B@apnic.net> From: Arturo Servin Date: Fri, 06 Nov 2015 21:06:35 +0000 Message-ID: To: Geoff Huston , Christopher Morrow Content-Type: multipart/alternative; boundary=001a114e6082efcdf50523e59e15 Archived-At: Cc: "sidr@ietf.org" , "sidr-chairs@ietf.org" , "sidr-ads@tools.ietf.org" Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 21:06:46 -0000 --001a114e6082efcdf50523e59e15 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable + 1 for adoption. And hopefully somebody would say "I take this". Regards as On Thu, 5 Nov 2015 at 23:04 Geoff Huston wrote: > > > On 6 Nov 2015, at 12:52 PM, Christopher Morrow < > christopher.morrow@gmail.com> wrote: > > > > Please take 2 weeks time to consider: > > > > "This document was adopted as a WG work item, should we accept this > > change and complete the work or not?=E2=80=9D > > > > I say =E2=80=9CYes," for some value of somebody/some people completing th= e work > that is !=3D me > > > thanks, > > Geoff > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --001a114e6082efcdf50523e59e15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

+ 1 for adoption.

An= d hopefully somebody would say "I take this".

Regards
as



On Thu, 5 Nov 2015 at 23:04 Geoff = Huston <gih@apnic.net> wrote:

> On 6 Nov 2015, at 12:52 PM, Christopher Morrow <christopher.morrow@gmail.com= > wrote:
>
> Please take 2 weeks time to consider:
>
> "This document was adopted as a WG work item, should we accept th= is
> change and complete the work or not?=E2=80=9D
>

I say =E2=80=9CYes," for some value of somebody/some people completing= the work that is !=3D me


thanks,

=C2=A0 Geoff


_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
--001a114e6082efcdf50523e59e15-- From nobody Fri Nov 6 13:35:11 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961781A1DE1 for ; Fri, 6 Nov 2015 13:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wD89FC1jddcL for ; Fri, 6 Nov 2015 13:35:09 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 317BC1A1DBC for ; Fri, 6 Nov 2015 13:35:09 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:37669 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Zuof5-000Hzm-OA for sidr@ietf.org; Fri, 06 Nov 2015 16:35:07 -0500 From: Stephen Kent To: sidr@ietf.org References: Message-ID: <563D1D0B.9030002@bbn.com> Date: Fri, 6 Nov 2015 16:35:07 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 21:35:10 -0000 > Please take 2 weeks time to consider: > > "This document was adopted as a WG work item, should we accept this > change and complete the work or not?" Adopting a doc as a WG item does not mean that it is acceptable "as is" at the time it was adopted. The intent is that the author(s) will cooperate with WG members to refine the doc as comments are posted. This doc has received detailed comments, posted to the list, to which the authors have never deigned to respond. It is very poorly written, and the specific change it describes (vaguely) is not technically consistent with the part of RFC (6487) that it purports to be updating. So, unless the folks who volunteered to assume responsibility for the doc (all of whom were already listed as co-authors) are prepared to do a much better job in addressing these shortcomings, I object to continuing with this work. Steve From nobody Fri Nov 6 21:31:12 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2B61B2A88 for ; Fri, 6 Nov 2015 21:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0WMrXya1lgM for ; Fri, 6 Nov 2015 21:31:08 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D1361B2A87 for ; Fri, 6 Nov 2015 21:31:07 -0800 (PST) Received: from [128.89.255.114] (port=64113 helo=Johns-MacBook-Pro.local) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Zuw5i-0001KP-9B; Sat, 07 Nov 2015 00:31:06 -0500 To: carlos@lacnic.net, sidr@ietf.org References: <563BC1E3.40100@bbn.com> <563C0987.4010200@gmail.com> From: Karen Seo Message-ID: <563D8C99.90507@bbn.com> Date: Sat, 7 Nov 2015 00:31:05 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563C0987.4010200@gmail.com> Content-Type: multipart/alternative; boundary="------------080604000305020505020209" Archived-At: Subject: Re: [sidr] Validation reconsidered draft status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 05:31:11 -0000 This is a multi-part message in MIME format. --------------080604000305020505020209 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi, Carlos, Perhaps I've misunderstood your draft but to me it seems to claim that there are 2 areas that could cause problems. 1. Page 4-5 discusses possible errors by CAs in issuing certificates that could cause subordinate certificates to fail validation. With regard to exploring adverse actions, what I meant is that your draft describes an adverse action (possibly several depending on how one interprets your text) that can be done by a CA by error (or maliciously or because of an attack). And I believe the adverse action draft covers this or could be extended to cover it, if the WG feels the current text does not adequately describe this case (or cases). 2. Page 5-7 talks about resource transfers as a source of concern. The way in which resource transfers can/will cause problems and the resulting impact will depend on how the WG decides to handle the transfers, the order of the actions, who does what, etc. So while your draft does not define how transfers should be done, Randy's draft struck me as potentially addressing the issue or at the very least providing the necessary basis for evaluating its seriousness and what to do about it. Karen On 11/5/15 8:59 PM, Carlos M. Martinez wrote: > Karen, > > I disagree with your position. Our draft does not explore adverse > actions nor discuses transfers. > > It is not the same topic. > > -Carlos > > On 11/6/15 5:53 AM, Karen Seo wrote: >> Folks, >> >> I think the authors have brought up some pertinent issues which have >> helped inspire other work which subsumes them. So I thank them but >> agree that it seems appropriate to drop this draft since those issues >> are now being covered in other documents and those documents have >> additional detail. Randy's I-D discusses INR transfers. Steve's draft >> on adverse action provides a detailed analysis of the "operational >> fragility" of the RPKI in the face of attacks and errors. So, if the >> adverse actions draft is adopted by the WG, we (the WG) could use the >> requirements stemming from these two IDs as the basis for a solution(s) >> document. Just personal preference, but I also find having one document >> per topic/issue (at least when they're as complex as is the case with >> the threat analysis) easier to follow and would also like to separate >> defining of issues and their requirements from describing the solution. >> >> Respectfully, >> Karen >> >> On 11/3/15 4:21 AM, Christopher Morrow wrote: >>> During the meeting today (tues 11/3/2015) one of the authors of: >>> draft-ietf-sidr-rpki-validation-reconsidered >>> >>> noted that after the last set of updates and over the history of the >>> document (2+yrs) there's been no real support nor direction from the >>> working-group. Additionally, all co-authors noted that the lack of >>> support and direction meant that abandoning the draft seemed like the >>> best current direction. >>> >>> The primary author: Geoff Huston (gih@apnic.net) is willing to toss >>> the XML over the fence to another author/editor if there is interest, >>> or to let the draft expire/die if no one is willing to take up the >>> pencil. >>> >>> Over the next three weeks let's discuss the direction/end-goal and >>> determine if 'abandon' or 'new author' is the best course of action >>> here. >>> >>> -chris >>> sidr-co-chair >>> >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --------------080604000305020505020209 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi, Carlos,

Perhaps I've misunderstood your draft but to me it seems to claim that there are 2 areas that could cause problems.
  1. Page 4-5 discusses possible errors by CAs in issuing certificates that could cause subordinate certificates to fail validation. With regard to exploring adverse actions, what I meant is that your draft describes an adverse action (possibly several depending on how one interprets your text) that can be done by a CA by error (or maliciously or because of an attack).  And I believe the adverse action draft covers this or could be extended to cover it, if the WG feels the current text does not adequately describe this case (or cases).
  2. Page 5-7  talks about resource transfers as a source of concern. The way in which resource transfers can/will cause problems and the resulting impact will depend on how the WG decides to handle the transfers, the order of the actions, who does what, etc.   So while your draft does not define how transfers should be done, Randy's draft struck me as potentially addressing the issue or at the very least providing the necessary basis for evaluating its seriousness and what to do about it. 

Karen




On 11/5/15 8:59 PM, Carlos M. Martinez wrote:
Karen,

I disagree with your position. Our draft does not explore adverse
actions nor discuses transfers.

It is not the same topic.

-Carlos

On 11/6/15 5:53 AM, Karen Seo wrote:

Folks,

I think the authors have brought up some pertinent issues which have
helped inspire other work which subsumes them.  So I thank them but
agree that it seems appropriate to drop this draft since those issues
are now being covered in other documents and those documents have
additional detail.  Randy's I-D discusses INR transfers.  Steve's draft
on adverse action provides a detailed analysis of the "operational
fragility" of the RPKI in the face of attacks and errors.  So, if the
adverse actions draft is adopted by the WG,  we (the WG) could use the
requirements stemming from these two IDs as the basis for a solution(s)
document.  Just personal preference, but I also find having one document
per topic/issue (at least when they're as complex as is the case with
the threat analysis) easier to follow and would also like to separate
defining of issues and their requirements from describing the solution.

Respectfully,
Karen

On 11/3/15 4:21 AM, Christopher Morrow wrote:

During the meeting today (tues 11/3/2015) one of the authors of:
   draft-ietf-sidr-rpki-validation-reconsidered

noted that after the last set of updates and over the history of the
document (2+yrs) there's been no real support nor direction from the
working-group. Additionally, all co-authors noted that the lack of
support and direction meant that abandoning the draft seemed like the
best current direction.

The primary author: Geoff Huston (gih@apnic.net) is willing to toss
the XML over the fence to another author/editor if there is interest,
or to let the draft expire/die if no one is willing to take up the
pencil.

Over the next three weeks let's discuss the direction/end-goal and
determine if 'abandon' or 'new author' is the best course of action
here.

-chris
sidr-co-chair

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

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

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

--------------080604000305020505020209-- From nobody Sat Nov 7 12:45:47 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3CB1B3667 for ; Sat, 7 Nov 2015 12:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4GN1m7J7vyQ for ; Sat, 7 Nov 2015 12:45:44 -0800 (PST) Received: from mail545c25.carrierzone.com (mail545c25.carrierzone.com [64.29.147.145]) (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 34DEA1B2FDD for ; Sat, 7 Nov 2015 12:45:43 -0800 (PST) Received: from mail545c25.carrierzone.com (localhost [127.0.0.1]) by mail545c25.carrierzone.com (8.14.9/8.13.1) with ESMTP id tA7KjgnQ009250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 7 Nov 2015 20:45:42 +0000 Received: (from webmail@localhost) by mail545c25.carrierzone.com (8.14.9/8.12.2/Submit) id tA7Kjfbq009249 for sidr@ietf.org; Sat, 7 Nov 2015 15:45:41 -0500 Received: from c-73-4-42-229.hsd1.ma.comcast.net (c-73-4-42-229.hsd1.ma.comcast.net [73.4.42.229]) by mailapp03.register.com (Webmail 5.0 V.V.I.) with HTTP for ; Sat, 07 Nov 2015 15:45:41 -0500 Message-ID: <20151107154541.betcqig8gogs8wo4@mailapp03.register.com> From: mcr@islandpeaksoftware.com To: sidr@ietf.org Date: Sat, 07 Nov 2015 15:45:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Webmail 6.0 X-CSC: 0 X-CHA: v=2.1 cv=Gb4uw2nL c=1 sm=1 tr=0 a=WkljmVdYkabdwxfqvArNOQ==:117 a=vYENOC+fU7OXnT2953Z2qQ==:17 a=g0qM3YM6AAAA:8 a=iA_LCt3nAAAA:8 a=GtTXk3Y1AAAA:8 a=C_IRinGWAAAA:8 a=IkcTkHD0fZMA:10 a=qtqOOiqGOCEA:10 a=QcEqIRuzC03UU9L4VWcA:9 a=QEXdDO2ut3YA:10 X-CTCH-RefID: str=0001.0A020206.563E62F6.00D1, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 Archived-At: Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 20:45:45 -0000 I am opposed to this document for the reasons stated by Steve Kent and others. From nobody Mon Nov 9 06:05:40 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739761B2C10; Mon, 9 Nov 2015 06:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLiERk5rbmQT; Mon, 9 Nov 2015 06:05:38 -0800 (PST) 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 0FB3E1B2BCE; Mon, 9 Nov 2015 06:05:38 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1Zvn4g-000BQS-V9; Mon, 09 Nov 2015 15:05:35 +0100 Received: from kitten.ripe.net ([193.0.1.240]) by nene.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1Zvn4f-00060I-NG; Mon, 09 Nov 2015 15:05:33 +0100 Received: from oleg by kitten.ripe.net with local (Exim 4.72) (envelope-from ) id 1Zvn4f-0003y3-L2; Mon, 09 Nov 2015 15:05:33 +0100 Date: Mon, 9 Nov 2015 15:05:33 +0100 From: Oleg Muravskiy To: Christopher Morrow Message-ID: <20151109140533.GK16219@kitten.ripe.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.2 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b745ed7ca6d893ff409792f17122b666ffd Archived-At: Cc: "sidr-ads@tools.ietf.org" , "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 14:05:39 -0000 On Fri, Nov 06, 2015 at 12:52:13PM +1100, Christopher Morrow wrote: > Please take 2 weeks time to consider: > > "This document was adopted as a WG work item, should we accept this > change and complete the work or not?" Yes, we should. > > where: > 'this document' is: > > > > I'll close the mic line on: 11/20/2015 > Nov 20, 2015 > > -Chris > sidr-co-chair > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > -- Oleg Muravskiy RIPE NCC From nobody Tue Nov 10 11:26:43 2015 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 900D31B3D6B; Tue, 10 Nov 2015 11:26:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151110192641.8664.35984.idtracker@ietfa.amsl.com> Date: Tue, 10 Nov 2015 11:26:41 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-origin-validation-signaling-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 19:26:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : BGP Prefix Origin Validation State Extended Community Authors : Pradosh Mohapatra Keyur Patel John Scudder Dave Ward Randy Bush Filename : draft-ietf-sidr-origin-validation-signaling-06.txt Pages : 5 Date : 2015-11-10 Abstract: As part of the origination AS validation process, it can be desirable to automatically consider the validation state of routes in the BGP decision process. The purpose of this document is to provide a specification for doing so. The document also defines a new BGP opaque extended community to carry the validation state inside an autonomous system to influence the decision process of the IBGP speakers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-origin-validation-signaling/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-origin-validation-signaling-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 10 13:30:13 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBEA1A908E for ; Tue, 10 Nov 2015 13:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17LxRiGzwODg for ; Tue, 10 Nov 2015 13:30:11 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 418D11A9081 for ; Tue, 10 Nov 2015 13:30:11 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 983ED28B0041; Tue, 10 Nov 2015 16:30:10 -0500 (EST) Received: from nova.tislabs.com (nova.tislabs.com [10.66.1.77]) by nova.tislabs.com (Postfix) with ESMTP id 81EB41F8035; Tue, 10 Nov 2015 16:30:10 -0500 (EST) Date: Tue, 10 Nov 2015 16:30:10 -0500 (EST) From: Samuel Weiler To: Sean Turner In-Reply-To: Message-ID: References: User-Agent: Alpine 2.03 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1107971329-130055578-1447190847=:19846" Content-ID: Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] WGLC on draft-ietf-sidr-bgpsec-algs-11 (ENDS 30-Oct-2015) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 21:30:12 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1107971329-130055578-1447190847=:19846 Content-Type: TEXT/PLAIN; CHARSET=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: Thanks to Sean for making the updates I suggested. I just sent a couple more editorial suggestions re: the new text that was just added, but I'm comfortable sending the doc forward. On Thu, 29 Oct 2015, Sean Turner wrote: >> Nail down the initial codepoint in the IANA registry (this doc is >> creating the registry, so we can be specific). I suggest "1â€. > > Do you think this is a blocking issue? No. If it were me, I would not reserve high/low values. It's a Standards Action registry, and we don't have to interoperate with legacy implementations - I don't see the need for reserved values. And I concur with the change to standards track. -- Sam --1107971329-130055578-1447190847=:19846-- From nobody Tue Nov 10 14:36:06 2015 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE83E1B4199; Tue, 10 Nov 2015 14:36:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151110223603.4340.13378.idtracker@ietfa.amsl.com> Date: Tue, 10 Nov 2015 14:36:03 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-14.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 22:36:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : BGPsec Algorithms, Key Formats, & Signature Formats Author : Sean Turner Filename : draft-ietf-sidr-bgpsec-algs-14.txt Pages : 7 Date : 2015-11-10 Abstract: This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key size and signature format used in BGPsec (Border Gateway Protocol Security). This document updates the Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure (ID.sidr-rfc6485bis). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 10 14:42:37 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7861B41E2 for ; Tue, 10 Nov 2015 14:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G20Awo5_feGv for ; Tue, 10 Nov 2015 14:42:34 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (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 55AA81B41E1 for ; Tue, 10 Nov 2015 14:42:33 -0800 (PST) Received: by ykfs79 with SMTP id s79so20931251ykf.1 for ; Tue, 10 Nov 2015 14:42:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=Rr+UeTL18WNNKmyIMBN91cqQioYaYuYdLZmseymBD+M=; b=nMUQswbgWbS2BnC/vpkBAY1lCG49hJyFTxgWGJLtjbhgJN4ErQZnNW3BfE1Vo8WyXO nJj6XlPGoS7G1Iuyb8gn/WZOp0IeYrobIul/hbZFE9vdiPtmCSatRIE7usSZOTSScOqV uc9xJ5dfK1gO7z/+j3hM4U0uuw7uyeRyzTDos= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=Rr+UeTL18WNNKmyIMBN91cqQioYaYuYdLZmseymBD+M=; b=i9BQIU8DW8emG4V3eHShcXSkbKpwChZsX+05kfZvf8+Skre9rtPkZyOmjqP13JwsDd 51+gY5wBYWUoNMAodhzlAmWBpKYzhX7oi/8pdcl9IVx7513e7+bWFy4HlX8ENFdDFf4t PFVmtiMCAsLsaMyUifpv/KbLG0w9Tbjts9f+bBkKUdiJBv2gccJomiV74qckitifE8kf zZYm54qpZ2fmEtokAdwMcTf0ez4NQiZWVg1JsggMP3sRVQ/sKcO71v+KkiVjiG4tIRLj dFCgg3QWgnuzSJvnkLp4vQ7bYM13Zu1JNO9aWoct3iGiOlrej6Hd/ZXacjmBBiHrvrsA Yxyg== X-Gm-Message-State: ALoCoQlhNyhJqletdDW5YnfjI7xi9SeRS+LQDR9heRlXV8+VP1F/ijqTycFcOPYSq2kCjkl74gaU X-Received: by 10.13.227.4 with SMTP id m4mr5609665ywe.72.1447195352632; Tue, 10 Nov 2015 14:42:32 -0800 (PST) Received: from [172.16.0.112] (pool-173-73-126-234.washdc.east.verizon.net. [173.73.126.234]) by smtp.gmail.com with ESMTPSA id z130sm578552ywb.18.2015.11.10.14.42.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Nov 2015 14:42:32 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Sean Turner In-Reply-To: <20151110223603.4340.13378.idtracker@ietfa.amsl.com> Date: Tue, 10 Nov 2015 17:42:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <295F9E94-A3C1-4738-A945-EB501F04B0A5@sn3rd.com> References: <20151110223603.4340.13378.idtracker@ietfa.amsl.com> To: sidr wg list X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-14.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 22:42:35 -0000 Just fixes two spelling mistakes. spt > On Nov 10, 2015, at 17:36, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Secure Inter-Domain Routing Working = Group of the IETF. >=20 > Title : BGPsec Algorithms, Key Formats, & Signature = Formats > Author : Sean Turner > Filename : draft-ietf-sidr-bgpsec-algs-14.txt > Pages : 7 > Date : 2015-11-10 >=20 > Abstract: > This document specifies the algorithms, algorithm parameters, > asymmetric key formats, asymmetric key size and signature format = used > in BGPsec (Border Gateway Protocol Security). This document updates > the Profile for Algorithms and Key Sizes for use in the Resource > Public Key Infrastructure (ID.sidr-rfc6485bis). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-14 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-algs-14 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Thu Nov 12 06:44:28 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF791B2F90 for ; Thu, 12 Nov 2015 06:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80KXMjNE-S4i for ; Thu, 12 Nov 2015 06:44:23 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5341B2F8F for ; Thu, 12 Nov 2015 06:44:23 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id 436A2213BE5; Thu, 12 Nov 2015 09:44:23 -0500 (EST) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id A6578213BCC; Thu, 12 Nov 2015 09:44:20 -0500 (EST) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.210.2; Thu, 12 Nov 2015 09:53:52 -0500 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0224.002; Thu, 12 Nov 2015 09:43:36 -0500 From: Andy Newton To: Karen Seo Thread-Topic: [sidr] Validation reconsidered draft status Thread-Index: AQHRFhkVChgw0O1sl02fqEXD+kGj6Z6OP8qAgAqZDQA= Date: Thu, 12 Nov 2015 14:43:36 +0000 Message-ID: References: <563BC1E3.40100@bbn.com> In-Reply-To: <563BC1E3.40100@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.0.139] Content-Type: text/plain; charset="utf-8" Content-ID: <214B66A1CF60D2488519973DC1187305@corp.arin.net> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sidr@ietf.org" Subject: Re: [sidr] Validation reconsidered draft status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 14:44:27 -0000 DQo+IE9uIE5vdiA1LCAyMDE1LCBhdCAzOjUzIFBNLCBLYXJlbiBTZW8gPGtzZW9AYmJuLmNvbT4g d3JvdGU6DQo+IA0KPiBGb2xrcywNCj4gDQo+IEkgdGhpbmsgdGhlIGF1dGhvcnMgaGF2ZSBicm91 Z2h0IHVwIHNvbWUgcGVydGluZW50IGlzc3VlcyB3aGljaCBoYXZlIGhlbHBlZCBpbnNwaXJlIG90 aGVyIHdvcmsgd2hpY2ggc3Vic3VtZXMgdGhlbS4gIFNvIEkgdGhhbmsgdGhlbSBidXQgYWdyZWUg dGhhdCBpdCBzZWVtcyBhcHByb3ByaWF0ZSB0byBkcm9wIHRoaXMgZHJhZnQgc2luY2UgdGhvc2Ug aXNzdWVzIGFyZSBub3cgYmVpbmcgY292ZXJlZCBpbiBvdGhlciBkb2N1bWVudHMgYW5kIHRob3Nl IGRvY3VtZW50cyBoYXZlIGFkZGl0aW9uYWwgZGV0YWlsLiAgUmFuZHkncyBJLUQgZGlzY3Vzc2Vz IElOUiB0cmFuc2ZlcnMuICBTdGV2ZSdzIGRyYWZ0IG9uIGFkdmVyc2UgYWN0aW9uIHByb3ZpZGVz IGEgZGV0YWlsZWQgYW5hbHlzaXMgb2YgdGhlICJvcGVyYXRpb25hbCBmcmFnaWxpdHkiIG9mIHRo ZSBSUEtJIGluIHRoZSBmYWNlIG9mIGF0dGFja3MgYW5kIGVycm9ycy4gIFNvLCBpZiB0aGUgYWR2 ZXJzZSBhY3Rpb25zIGRyYWZ0IGlzIGFkb3B0ZWQgYnkgdGhlIFdHLCAgd2UgKHRoZSBXRykgY291 bGQgdXNlIHRoZSByZXF1aXJlbWVudHMgc3RlbW1pbmcgZnJvbSB0aGVzZSB0d28gSURzIGFzIHRo ZSBiYXNpcyBmb3IgYSBzb2x1dGlvbihzKSBkb2N1bWVudC4gIEp1c3QgcGVyc29uYWwgcHJlZmVy ZW5jZSwgYnV0IEkgYWxzbyBmaW5kIGhhdmluZyBvbmUgZG9jdW1lbnQgcGVyIHRvcGljL2lzc3Vl IChhdCBsZWFzdCB3aGVuIHRoZXkncmUgYXMgY29tcGxleCBhcyBpcyB0aGUgY2FzZSB3aXRoIHRo ZSB0aHJlYXQgYW5hbHlzaXMpIGVhc2llciB0byBmb2xsb3cgYW5kIHdvdWxkIGFsc28gbGlrZSB0 byBzZXBhcmF0ZSBkZWZpbmluZyBvZiBpc3N1ZXMgYW5kIHRoZWlyIHJlcXVpcmVtZW50cyBmcm9t IGRlc2NyaWJpbmcgdGhlIHNvbHV0aW9uLg0KDQpJZiBJ4oCZbSByZWFkaW5nIHlvdXIgYXJndW1l bnQgY29ycmVjdGx5LCB5b3XigJlyZSBzYXlpbmcgdGhhdCB2YWxpZGF0aW9uLXJlY29uc2lkZXJl ZCBpcyBub3QgbmVjZXNzYXJ5IGJlY2F1c2UgS2VudOKAmXMgYWR2ZXJzZSBhY3Rpb25zIGRyYWZ0 IHByb3ZpZGVzIGEgc29sdXRpb24uDQoNCkV4Y2VwdCB0aGF0IGl0IGRvZXNu4oCZdC4gVmFsaWRh dGlvbiByZWNvbnNpZGVyZWQgc3RvcHMgdGhlIGhhcm0gYmVmb3JlIGl0IGhhcHBlbnMsIHdoZXJl IGFzIHRoZSBhZHZlcnNlIGFjdGlvbnMgZHJhZnQgc2F5cyB0d28gdGhpbmdzOiAxKSBtb25pdG9y IGFuZCBmaXggdGhlIGhhcm0gYWZ0ZXIgaXQgaGFzIGhhcHBlbmVkLCBhbmQgMikgUlBzIHNob3Vs ZCBiZSBzbWFydGVyLiBTZXR0aW5nIGFzaWRlIHRoZSBoYW5kLXdhdmluZyBhbmQgbGFjayBvZiBh IGNvbmNyZXRlIHNvbHV0aW9uLCB0aGVzZSBhcmUgbm90IGNvbXBhcmFibGUgcHJvcG9zYWxzLg0K DQotYW5keQ== From nobody Thu Nov 12 11:15:57 2015 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 402641B319F; Thu, 12 Nov 2015 11:15:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151112191554.28093.59606.idtracker@ietfa.amsl.com> Date: Thu, 12 Nov 2015 11:15:54 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-origin-validation-signaling-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 19:15:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : BGP Prefix Origin Validation State Extended Community Authors : Pradosh Mohapatra Keyur Patel John Scudder Dave Ward Randy Bush Filename : draft-ietf-sidr-origin-validation-signaling-07.txt Pages : 5 Date : 2015-11-12 Abstract: This document defines a new BGP opaque extended community to carry the origination AS validation state inside an autonomous system. IBGP speakers that receive this validation state can configure local policies allowing it to influence their decision process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-origin-validation-signaling/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-origin-validation-signaling-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 16 09:16:28 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DED1A7001 for ; Mon, 16 Nov 2015 09:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e29wBnZ1Dpc6 for ; Mon, 16 Nov 2015 09:16:25 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D0511A7000 for ; Mon, 16 Nov 2015 09:16:25 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:36945 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZyNOB-000Dpo-Uv for sidr@ietf.org; Mon, 16 Nov 2015 12:16:24 -0500 From: Stephen Kent To: sidr@ietf.org References: <563BC1E3.40100@bbn.com> Message-ID: <564A0F67.2090704@bbn.com> Date: Mon, 16 Nov 2015 12:16:23 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sidr] Validation reconsidered draft status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 17:16:27 -0000 Andy, >> On Nov 5, 2015, at 3:53 PM, Karen Seo wrote: >> >> Folks, >> >> I think the authors have brought up some pertinent issues which have h= elped inspire other work which subsumes them. So I thank them but agree = that it seems appropriate to drop this draft since those issues are now b= eing covered in other documents and those documents have additional detai= l. Randy's I-D discusses INR transfers. Steve's draft on adverse action= provides a detailed analysis of the "operational fragility" of the RPKI = in the face of attacks and errors. So, if the adverse actions draft is a= dopted by the WG, we (the WG) could use the requirements stemming from t= hese two IDs as the basis for a solution(s) document. Just personal pref= erence, but I also find having one document per topic/issue (at least whe= n they're as complex as is the case with the threat analysis) easier to f= ollow and would also like to separate defining of issues and their requir= ements from describing the solution. > If I=E2=80=99m reading your argument correctly, you=E2=80=99re saying t= hat validation-reconsidered is not necessary because Kent=E2=80=99s adver= se actions draft provides a solution. I can't say what Karen may be thinking, but my argument is that=20 validation-reconsidered contains vague arguments about RPKI fragility and a technically=20 ambiguous description of a proposed change to 6487. What I believe is needed is a more=20 rigorous description of the problems being solved and a clear proposal of how to solve them.=20 If the co-authors who said they will assume responsibility for this doc make=20 significant revisions along these lines, then maybe the result will be worth pursuing= =2E > Except that it doesn=E2=80=99t. Validation reconsidered stops the harm = before it happens, where as the adverse actions draft says two things: 1)= monitor and fix the harm after it has happened, and 2) RPs should be sma= rter. The harm described in validation-reconsidered is the generation and=20 publication of certs that over-claim. The I-D does not stop that harm.=20 It proposes to sweep it under the rug, with a bandaid approach (that, as noted earlier) is technically=20 ambiguous, as stated). Adverse actions focuses mostly on defining the problem, in a more=20 precise fashion. It alludes to solution approaches that prevent the harm from having=20 immediate, adverse impact. The "RPs should be smarter" comment seems totally out of = place. > Setting aside the hand-waving and lack of a concrete solution, these ar= e not comparable proposals. Your are right that they are not comparable. One is very badly written,=20 and could be described as hand waving, and offers a "solution" that isn't well-defined= =2E The other is well written, defines problems in a rigorous fashion, and,=20 after making the changes suggested during the meeting, does not offer a=20 remediation proposal. Steve From nobody Mon Nov 16 09:40:10 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8291A9105 for ; Mon, 16 Nov 2015 09:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqgbH3tUf4GE for ; Mon, 16 Nov 2015 09:40:08 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C991A90A7 for ; Mon, 16 Nov 2015 09:40:07 -0800 (PST) Received: from dhcp89-089-172.bbn.com ([128.89.89.172]:62617) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZyNl6-000OkP-3D; Mon, 16 Nov 2015 12:40:04 -0500 To: Andy Newton References: <563BC1E3.40100@bbn.com> From: Karen Seo Message-ID: <564A14F4.3090204@bbn.com> Date: Mon, 16 Nov 2015 12:40:04 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "sidr@ietf.org" Subject: Re: [sidr] Validation reconsidered draft status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 17:40:09 -0000 Hi, Andy, Sorry to take so long to reply... I was out of the office for much of=20 Thurs/Fri. Responses in line below.... On 11/12/15 9:43 AM, Andy Newton wrote: >> On Nov 5, 2015, at 3:53 PM, Karen Seo wrote: >> >> Folks, >> >> I think the authors have brought up some pertinent issues which have h= elped inspire other work which subsumes them. So I thank them but agree = that it seems appropriate to drop this draft since those issues are now b= eing covered in other documents and those documents have additional detai= l. Randy's I-D discusses INR transfers. Steve's draft on adverse action= provides a detailed analysis of the "operational fragility" of the RPKI = in the face of attacks and errors. So, if the adverse actions draft is a= dopted by the WG, we (the WG) could use the requirements stemming from t= hese two IDs as the basis for a solution(s) document. Just personal pref= erence, but I also find having one document per topic/issue (at least whe= n they're as complex as is the case with the threat analysis) easier to f= ollow and would also like to separate defining of issues and their requir= ements from describing the solution. > If I=E2=80=99m reading your argument correctly, you=E2=80=99re saying t= hat validation-reconsidered is not necessary because Kent=E2=80=99s adver= se actions draft provides a solution. Sorry, what I meant was that it would be a good idea for the WG to do a=20 threat analysis which could then be used to prioritize issues and shape=20 solutions but not contain solutions. Do you agree with this premise? = The adverse actions seems to me to be a good place to start. If=20 validation reconsidered identifies threats that aren't covered in the=20 threat analysis, I think we should add them to the threat analysis. > Except that it doesn=E2=80=99t. Validation reconsidered stops the harm = before it happens, where as the adverse actions draft says two things: 1)= monitor and fix the harm after it has happened, and 2) RPs should be sma= rter. Setting aside the hand-waving and lack of a concrete solution, thes= e are not comparable proposals. I defer to Steve on this, I believe he intends to remove the=20 remediation text. Thank you, Karen From nobody Mon Nov 16 23:54:39 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14891B2C01 for ; Mon, 16 Nov 2015 23:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCVQy4Tsg5fO for ; Mon, 16 Nov 2015 23:54:36 -0800 (PST) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B21B1B2C00 for ; Mon, 16 Nov 2015 23:54:36 -0800 (PST) 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) (envelope-from ) id 1Zyb5z-0000vG-3B; Tue, 17 Nov 2015 08:54:33 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-148.ripe.net) by titi.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Zyb5y-00026W-UM; Tue, 17 Nov 2015 08:54:31 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Tim Bruijnzeels In-Reply-To: <564A0F67.2090704@bbn.com> Date: Tue, 17 Nov 2015 09:54:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0A0BD210-5558-410B-A3A7-394872C7984E@ripe.net> References: <563BC1E3.40100@bbn.com> <564A0F67.2090704@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.2104) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.5 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07192818b74c22b824821814907444712192 Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] Validation reconsidered draft status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 07:54:37 -0000 > On 16 Nov 2015, at 19:16, Stephen Kent wrote: >=20 > Andy, >>> On Nov 5, 2015, at 3:53 PM, Karen Seo wrote: >>>=20 >>> Folks, >>>=20 >>> I think the authors have brought up some pertinent issues which have = helped inspire other work which subsumes them. So I thank them but = agree that it seems appropriate to drop this draft since those issues = are now being covered in other documents and those documents have = additional detail. Randy's I-D discusses INR transfers. Steve's draft = on adverse action provides a detailed analysis of the "operational = fragility" of the RPKI in the face of attacks and errors. So, if the = adverse actions draft is adopted by the WG, we (the WG) could use the = requirements stemming from these two IDs as the basis for a solution(s) = document. Just personal preference, but I also find having one document = per topic/issue (at least when they're as complex as is the case with = the threat analysis) easier to follow and would also like to separate = defining of issues and their requirements from describing the solution. >> If I=E2=80=99m reading your argument correctly, you=E2=80=99re saying = that validation-reconsidered is not necessary because Kent=E2=80=99s = adverse actions draft provides a solution. > I can't say what Karen may be thinking, but my argument is that = validation-reconsidered > contains vague arguments about RPKI fragility and a technically = ambiguous description > of a proposed change to 6487. What I believe is needed is a more = rigorous description > of the problems being solved and a clear proposal of how to solve = them. If the > co-authors who said they will assume responsibility for this doc make = significant > revisions along these lines, then maybe the result will be worth = pursuing. As I stated at the mic I am willing to work on making this document more = clear (and shorter) *if* the working group agrees that we can work on = this in a constructive manner. It is okay if we have different opinions = if we can all respect them and discuss the content, staying away from = hyperboles and personal remarks. Unfortunately this hasn't always been = the case. The second point I tried to make is that if it is already clear that = consensus will never be reached on this, then spending more effort on it = is a waste of everyone's time. I understand that there are no guarantees = that consensus will be reached, but if there is a guarantee that = consensus will *not* be reached, then the exercise is pointless. So far this discussion actually looks promising and more constructive = than it has been. Can I interpret your statement about 'maybe the result = will be worth pursuing' to mean that you agree that we can continue = discuss this constructively, and it is not certain a priori that it will = be rejected? Thanks, Tim= From nobody Tue Nov 17 07:32:40 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D2F1A912F for ; Tue, 17 Nov 2015 07:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFjGBPKFpKPi for ; Tue, 17 Nov 2015 07:32:38 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 6D8E31A9128 for ; Tue, 17 Nov 2015 07:32:38 -0800 (PST) Received: by vkbs1 with SMTP id s1so7729192vkb.3 for ; Tue, 17 Nov 2015 07:32:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=bj1b3L1eliZ53Ehcm5WOvBwM7EvMw9qVD3zUt/6Hf28=; b=PCMcCoocGLZkRzHxLyixVBAEPUCffGpvRrOb3uP3aoLZE0DLIPE9omBthsXQ0VX2mJ b84Aa13HeLxdjspN2megmA5uldmGuZiwczU3ypx+VO6PGXhqR4pQybK1scshu3dw4tmz DbAM1N4aBqH9FuICBs8LUgnEBOlIywgAx6QAXG8Kau8L9qEN56m1Q5vmECVdZrKnIjEt +4AQ9HkdfPxkCYWHoCk5R31sQcNxcLKXlt3YWpUy4jXlFjqzDMz7OVHvbc+heh/dpZ90 FB1CMfzdfkq5NseSw0UGztXh3nPHFU5ZSx0Ur5telFB8msdZiERstWYHDKN/TVbbjNRW uc7A== X-Received: by 10.31.156.130 with SMTP id f124mr4192848vke.52.1447774357440; Tue, 17 Nov 2015 07:32:37 -0800 (PST) Received: from erebus.local ([2001:13c7:7001:2128:2d5e:8e93:b8ba:df4d]) by smtp.googlemail.com with ESMTPSA id 86sm3376722vkq.28.2015.11.17.07.32.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Nov 2015 07:32:36 -0800 (PST) References: <563BC1E3.40100@bbn.com> To: Andy Newton , Karen Seo From: "Carlos M. Martinez" X-Enigmail-Draft-Status: N1110 Message-ID: <564B488F.8010608@gmail.com> Date: Tue, 17 Nov 2015 12:32:31 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "sidr@ietf.org" Subject: Re: [sidr] Validation reconsidered draft status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 15:32:40 -0000 Karen/Steve, Sorry for getting back to this late. Andy is right on the money: the text validation-reconsidered has possible 'things that can go wrong' could be removed but the main idea, as Andy says, is to engineer robustness into the system in a way that the system will be more resilient in the face of unexpected events that we might have or have not thought about. Now, if you are proposing that we could have a single document enumerating threats and 'other things that could go wrong', I thing I could agree with that on the understanding that we agree to clearly separate threats from remediation proposals. This means probably removing some text from Steve's draft as well. regards, -Carlos On 11/12/15 11:43 AM, Andy Newton wrote: > >> On Nov 5, 2015, at 3:53 PM, Karen Seo wrote: >> >> Folks, >> >> I think the authors have brought up some pertinent issues which have helped inspire other work which subsumes them. So I thank them but agree that it seems appropriate to drop this draft since those issues are now being covered in other documents and those documents have additional detail. Randy's I-D discusses INR transfers. Steve's draft on adverse action provides a detailed analysis of the "operational fragility" of the RPKI in the face of attacks and errors. So, if the adverse actions draft is adopted by the WG, we (the WG) could use the requirements stemming from these two IDs as the basis for a solution(s) document. Just personal preference, but I also find having one document per topic/issue (at least when they're as complex as is the case with the threat analysis) easier to follow and would also like to separate defining of issues and their requirements from describing the solution. > > If I’m reading your argument correctly, you’re saying that validation-reconsidered is not necessary because Kent’s adverse actions draft provides a solution. > > Except that it doesn’t. Validation reconsidered stops the harm before it happens, where as the adverse actions draft says two things: 1) monitor and fix the harm after it has happened, and 2) RPs should be smarter. Setting aside the hand-waving and lack of a concrete solution, these are not comparable proposals. > > -andy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From nobody Tue Nov 17 12:13:27 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FAA1A87D7 for ; Tue, 17 Nov 2015 12:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.785 X-Spam-Level: X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hq6eZ6O1HVkj for ; Tue, 17 Nov 2015 12:13:23 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AC361A87D5 for ; Tue, 17 Nov 2015 12:13:23 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:45846 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Zymcz-000FcD-Nn; Tue, 17 Nov 2015 15:13:21 -0500 From: Stephen Kent To: Tim Bruijnzeels References: <563BC1E3.40100@bbn.com> <564A0F67.2090704@bbn.com> <0A0BD210-5558-410B-A3A7-394872C7984E@ripe.net> Message-ID: <564B8A61.50302@bbn.com> Date: Tue, 17 Nov 2015 15:13:21 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <0A0BD210-5558-410B-A3A7-394872C7984E@ripe.net> Content-Type: multipart/alternative; boundary="------------030408090907090004010602" Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] Validation reconsidered draft status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 20:13:26 -0000 This is a multi-part message in MIME format. --------------030408090907090004010602 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Tim, > The second point I tried to make is that if it is already clear that consensus will never be reached on this, then spending more effort on it is a waste of everyone's time. I understand that there are no guarantees that consensus will be reached, but if there is a guarantee that consensus will *not* be reached, then the exercise is pointless. I understand your reluctance to invest time into a document that may or may not become an RFC. But, that is what all of us do when we write drafts. There are no guarantees; many I-Ds become RFCs, but not all. I cannot guarantee that the WG will reach consensus on this draft. First, the consensus call if made by the WG chairs, not by me. Second, I assume you and your colleagues plan to re-write the document, and so it's premature to comment on the likely success of a revised document. > So far this discussion actually looks promising and more constructive than it has been. Can I interpret your statement about 'maybe the result will be worth pursuing' to mean that you agree that we can continue discuss this constructively, and it is not certain a priori that it will be rejected? I am willing to discuss this constructively. I provided extensive comments, including numerous edits to try to improve the text several months ago. If you and Carlos and Andy are serious about going forward, I suggest two actions: 1. review the edits I suggested month ago and either adopt them or explain why they are rejected 2. reword the proposed solution so that it is technically unambiguous and aligned with RFC 6487. In rewording the solution description, please address the issues I noted, reproduced below. The text in step 6 seems a bit vague. It refers to a “resource set†but that phrase is not defined in this document. Looking at 6487, the phrase appears twice, in Sections 4.8.10 and 4.8.11. In those sections it is referring to the set of resources acquired from a parent when the inherit bit is set. If the intent is to use this phrase to refer to the set of resources extracted from an RPKI certificate, irrespective of whether the inherit bit is set, this text should say so. The security considerations section says “… the validation path encompass the resources that are included in the validation query.†One might read this and infer that a set of INRs is an input to the validation algorithm. But 6487 does not say INRs are a separate input to validation. A certificate to be validated is an input to this algorithm, and I assume that was what is implied in step 6 and in the text quoted above. If my assumption is correct, this should be stated clearly in both places. Thinking about this in more detail, I fear that the results from the modified algorithm will not yield what you seem to want, at least not in all cases. If one validates only router certificates and EE certificates for (non-PKI) signed objects, e.g., for ROAs or Manifests, then the outcome will yield what I think you want. However, when validating a CA certificate that “over claims†the certificate will be considered invalid by the revised step 6, just as with the current validation algorithm. (The over claiming could result from some types of CA errors or attacks, or during an “free style†resource transfer.) RP software may validate each CA certificate that it initially acquires, before fetching subordinate signed products. This is a reasonable strategy to avoid DoS attacks based on returning bogus certificates to an RP. Also, when a cached CA certificate is discovered to have changed, an RP probably will validate it before adding the certificate to the cache. In these cases, the revised step 6 will treat this certificate as invalid, because it contains resources not present in all parent certificates. Thus all certificates and signed products below it will become invalid. So, I don’t believe the change to step 6, as described in your I-D, and as interpreted above, will accommodate the motivations described in the I-D that you plan to replace with this one. --------------030408090907090004010602 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Tim,

The second point I tried to make is that if it is already clear that consensus will never be reached on this, then spending more effort on it is a waste of everyone's time. I understand that there are no guarantees that consensus will be reached, but if there is a guarantee that consensus will *not* be reached, then the exercise is pointless.
I understand your reluctance to invest time into a document that may or may
not become an RFC. But, that is what all of us do when we write drafts. There
are no guarantees; many I-Ds become RFCs, but not all.

I cannot guarantee that the WG will reach consensus on this draft. First, the consensus
call if made by the WG chairs, not by me. Second, I assume you and your colleagues
plan to re-write the document, and so it's premature to comment on the likely
success of a revised document.
So far this discussion actually looks promising and more constructive than it has been. Can I interpret your statement about 'maybe the result will be worth pursuing' to mean that you agree that we can continue discuss this constructively, and it is not certain a priori that it will be rejected?
I am willing to discuss this constructively.  I provided extensive comments,
including numerous edits to try to improve the text several months ago. If
you and Carlos and Andy are serious about going forward, I suggest two actions:
     1. review the edits I suggested month ago and either adopt them
       or explain why they are rejected

    2. reword the proposed solution so that it is technically unambiguous and
    aligned with RFC 6487. In rewording the solution description, please address
    the issues I noted, reproduced below.

The text in step 6 seems a bit vague. It refers to a “resource set†but that phrase is not defined in this document. Looking at 6487, the phrase appears twice, in Sections 4.8.10 and 4.8.11. In those sections it is referring to the set of resources acquired from a parent when the inherit bit is set. If the intent is to use this phrase to refer to the set of resources extracted from an RPKI certificate, irrespective of whether the inherit bit is set, this text should say so.

The security considerations section says “… the validation path encompass the resources that are included in the validation query.†One might read this and infer that a set of INRs is an input to the validation algorithm. But 6487 does not say INRs are a separate input to validation. A certificate to be validated is an input to this algorithm, and I assume that was what is implied in step 6 and in the text quoted above. If my assumption is correct, this should be stated clearly in both places.

Thinking about this in more detail, I fear that the results from the modified algorithm will not yield what you seem to want, at least not in all cases. If one validates only router certificates and EE certificates for (non-PKI) signed objects, e.g., for ROAs or Manifests, then the outcome will yield what I think you want. However, when validating a CA certificate that “over claims†the certificate will be considered invalid by the revised step 6, just as with the current validation algorithm. (The over claiming could result from some types of CA errors or attacks, or during an “free style†resource transfer.)

RP software may validate each CA certificate that it initially acquires, before fetching subordinate signed products. This is a reasonable strategy to avoid DoS attacks based on returning bogus certificates to an RP. Also, when a cached CA certificate is discovered to have changed, an RP probably will validate it before adding the certificate to the cache. In these cases, the revised step 6 will treat this certificate as invalid, because it contains resources not present in all parent certificates. Thus all certificates and signed products below it will become invalid. So, I don’t believe the change to step 6, as described in your I-D, and as interpreted above, will accommodate the motivations described in the I-D that you plan to replace with this one.



--------------030408090907090004010602-- From nobody Tue Nov 17 12:19:23 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA75F1A9231 for ; Tue, 17 Nov 2015 12:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZTG1lVhTRNV for ; Tue, 17 Nov 2015 12:19:20 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F4EE1A90D4 for ; Tue, 17 Nov 2015 12:19:17 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:45957 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Zymii-000FjT-9i for sidr@ietf.org; Tue, 17 Nov 2015 15:19:16 -0500 To: sidr@ietf.org References: <563BC1E3.40100@bbn.com> <564B488F.8010608@gmail.com> From: Stephen Kent Message-ID: <564B8BC4.2040009@bbn.com> Date: Tue, 17 Nov 2015 15:19:16 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564B488F.8010608@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sidr] Validation reconsidered draft status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 20:19:21 -0000 Carlos, > Karen/Steve, > > Sorry for getting back to this late. > > Andy is right on the money: the text validation-reconsidered has > possible 'things that can go wrong' could be removed but the main idea, > as Andy says, is to engineer robustness into the system in a way that > the system will be more resilient in the face of unexpected events that > we might have or have not thought about. I agree that improving system robustness is a generally good idea. However, if one argues for a major change to the existing system, the justification needs to be precise, and compelling, and well defined. Addressing unanticipated events is a good idea too, but addressing anticipated, clearly identified events seems even more important. That's why I believe we ought to take into account the events described in adverse actions when we consider making any significant change to the cert path validation algorithm. > Now, if you are proposing that we could have a single document > enumerating threats and 'other things that could go wrong', I thing I > could agree with that on the understanding that we agree to clearly > separate threats from remediation proposals. This means probably > removing some text from Steve's draft as well. I stated that I would remove the sections on detection and remediation during the meeting. By the end of this week I hope to have a new version posted which does that, and which adds a generic, additional concern that addresses the issue Sriram raised. The revised adverse actions document should meet the criteria you state above. Steve From nobody Tue Nov 17 17:22:00 2015 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 832DC1B36C3; Tue, 17 Nov 2015 17:21:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151118012157.23581.37854.idtracker@ietfa.amsl.com> Date: Tue, 17 Nov 2015 17:21:57 -0800 Archived-At: Cc: sidr@ietf.org, draft-ietf-sidr-rfc6485bis@ietf.org, sidr-chairs@ietf.org, sandy@tislabs.com Subject: [sidr] Kathleen Moriarty's No Objection on draft-ietf-sidr-rfc6485bis-04: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 01:21:57 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-sidr-rfc6485bis-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The SecDir reviewer picked up on a stray "/>" in section 6, just making a note of that here, but I'm sure the RFC editor would see it too. https://www.ietf.org/mail-archive/web/secdir/current/msg06151.html From nobody Tue Nov 17 18:09:10 2015 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B2F1B37D9; Tue, 17 Nov 2015 18:09:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Terry Manderson" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151118020907.790.34242.idtracker@ietfa.amsl.com> Date: Tue, 17 Nov 2015 18:09:07 -0800 Archived-At: Cc: sidr@ietf.org, draft-ietf-sidr-rfc6485bis@ietf.org, sidr-chairs@ietf.org, sandy@tislabs.com Subject: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rfc6485bis-04: (with DISCUSS) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 02:09:07 -0000 Terry Manderson has entered the following ballot position for draft-ietf-sidr-rfc6485bis-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'm not so sure that this will be an easy DISCUSS to work through as I view this in light of future sustainability/deployability of RPKI and any protocol wedded to it (eg BGPSEC). Section 5 "Additional Requirements" suggests that both CAs and RPs "SHOULD" be capable of supporting a transition and thus able to support multiple RPKI alg. and key profiles. To me this "SHOULD" seems like it invites fragility in any such transition. An immediate example would be the root DNSSEC ksk rollover. An rather large amount of work is underway to ascertain the impact. By leaving the SHOULDs in place is this walking the same path? Let me ask another way. Under what situations is it actually appropriate for a CA or RP to be able to ignore the requirement of being able to support a phased introduction/deprecation of new/different RPKI algorithm and key profiles? And if they ignore such a recommendation does this make the entire RPKI infrastructure a fractured PKI by algorithm? From nobody Wed Nov 18 06:40:10 2015 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D59771B2E6F; Wed, 18 Nov 2015 06:40:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151118144006.32269.75751.idtracker@ietfa.amsl.com> Date: Wed, 18 Nov 2015 06:40:06 -0800 Archived-At: Cc: sidr@ietf.org, draft-ietf-sidr-rfc6485bis@ietf.org, sidr-chairs@ietf.org, sandy@tislabs.com Subject: [sidr] Brian Haberman's No Objection on draft-ietf-sidr-rfc6485bis-04: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 14:40:07 -0000 Brian Haberman has entered the following ballot position for draft-ietf-sidr-rfc6485bis-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Terry's DISCUSS. From nobody Thu Nov 19 10:27:47 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644961A8ADE; Thu, 19 Nov 2015 10:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNFWdEnO5dvP; Thu, 19 Nov 2015 10:27:42 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565261A0143; Thu, 19 Nov 2015 10:27:39 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 90C4328B003D; Thu, 19 Nov 2015 13:27:38 -0500 (EST) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 73DB71F8035; Thu, 19 Nov 2015 13:27:38 -0500 (EST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E14FD9C0-3D5F-405E-B894-82B80A21E4D9"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.1 From: Sandra Murphy In-Reply-To: <20151118020907.790.34242.idtracker@ietfa.amsl.com> Date: Thu, 19 Nov 2015 13:27:31 -0500 Message-Id: <938892D5-919F-4C61-B518-7145CB40A05B@tislabs.com> References: <20151118020907.790.34242.idtracker@ietfa.amsl.com> To: Terry Manderson X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: draft-ietf-sidr-rfc6485bis@ietf.org, sidr-chairs@ietf.org, sidr wg list , The IESG , Sandra Murphy Subject: Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rfc6485bis-04: (with DISCUSS) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 18:27:45 -0000 --Apple-Mail=_E14FD9C0-3D5F-405E-B894-82B80A21E4D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 A bit of history here. After RFC6485 was published, it was discovered that it incorrectly used = the same OID for all RPKI crypto uses, which conflicts with CMS specs = and is inconsistent with known implementations. The wg decided to create RFC6485bis, to correct the OID problem and the = OID problem only, with emphasis on the =93only=94. The =93SHOULD=94 language in section 5 is inherited from RFC6485, except = for: The recommended procedures to implement such a transition of key sizes and algorithms is specified in [RFC6916] RFC6916, which was published a year after RFC6485, is "Algorithm Agility = Procedure for the Resource Public Key Infrastructure (RPKI)=94. It = describes the procedure to follow in transitioning from one = algorithm/key size to another. Does RFC6916 satisfy your concerns about a change of algorithm? Would you prefer that RFC6485bis remove the inherited =93SHOULD=94 = language and point only to RFC6916? =97Sandy On Nov 17, 2015, at 9:09 PM, Terry Manderson = wrote: > Terry Manderson has entered the following ballot position for > draft-ietf-sidr-rfc6485bis-04: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I'm not so sure that this will be an easy DISCUSS to work through as I > view this in light of future sustainability/deployability of RPKI and = any > protocol wedded to it (eg BGPSEC). >=20 > Section 5 "Additional Requirements" suggests that both CAs and RPs > "SHOULD" be capable of supporting a transition and thus able to = support > multiple RPKI alg. and key profiles. To me this "SHOULD" seems like it > invites fragility in any such transition. An immediate example would = be > the root DNSSEC ksk rollover. An rather large amount of work is = underway > to ascertain the impact. By leaving the SHOULDs in place is this = walking > the same path? >=20 > Let me ask another way. Under what situations is it actually = appropriate > for a CA or RP to be able to ignore the requirement of being able to > support a phased introduction/deprecation of new/different RPKI = algorithm > and key profiles? And if they ignore such a recommendation does this = make > the entire RPKI infrastructure a fractured PKI by algorithm? >=20 >=20 >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_E14FD9C0-3D5F-405E-B894-82B80A21E4D9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWThSZAAoJEHplpQeet0IZqbcP/RIh7+Gii5a4Ru6qpLYcU02o XS34dP8gJ+7C+W+qh+aKBxhvnzykcH2vU3Muje0zpO5dVEiLd5GZCouZAQfA6Y1M fTVLTDpompq6cCx4M8DIiNK8JEWKV6a+rpjyZHh2iCFq9F+ziewBkOhzcCZpmKMx XgECz30ynb8KEtRZ5qTGT8w0auPwRMtCBULle56vuE23E5OXmgwdILSpNifrg6Rj D7Ah9J4/iTpMYh95rUftWFnuqBMyjRt2mq0N/K7ab+sQnD3MCCt10Xvdit1IGkSw hvwCrxD301NbnaLvl37g6JBbM/vc1jS/uad/Vy8KydOCwk37E/+jL2nKkAH7dk2X CQv8woUoc95P3MCrxa+mxVYxQVhiBNyCRVvarrbZ5vn2T7Q4dyBltEj2mN2KjsUH Yf+H2ETu+3HVt0OaayO8+xVsE49RSo43om3zgDh1PxkIQJInxdVokGWBQ0S9pjS2 eDha1RQfA8U02w68QYFm2Z/D4Eh+H8EhUq+Zsr4WRyearN8mVw8MnOYitDrG1Rc/ 3REds7xLxQfsHzuEfha93hP+peXQmIVh9NI3ROoal94Ht21FL/8BHEXunRnjsoo7 OSqsecqlEkE92kcwjhLzWhN6Gfnx3XJ2QXC30GwKEKwTvCtqSrVy2hCRL5uD2N1x 0OQMtrsWc7OcH7i1oeCb =zyEQ -----END PGP SIGNATURE----- --Apple-Mail=_E14FD9C0-3D5F-405E-B894-82B80A21E4D9-- From nobody Thu Nov 19 12:47:38 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582A61B353E for ; Thu, 19 Nov 2015 12:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IY0nXjCVES_r for ; Thu, 19 Nov 2015 12:47:36 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C2151B353D for ; Thu, 19 Nov 2015 12:47:36 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 8FD6728B0041; Thu, 19 Nov 2015 15:47:35 -0500 (EST) Received: from nova.tislabs.com (nova.tislabs.com [10.66.1.77]) by nova.tislabs.com (Postfix) with ESMTP id 6DB4C1F801E; Thu, 19 Nov 2015 15:47:35 -0500 (EST) Date: Thu, 19 Nov 2015 15:47:35 -0500 (EST) From: Samuel Weiler To: Christopher Morrow In-Reply-To: Message-ID: References: User-Agent: Alpine 2.03 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: "sidr@ietf.org" Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 20:47:37 -0000 > "This document was adopted as a WG work item, should we accept this > change and complete the work or not?" Yes. I believe this change in the validation algorithm improves the operational robustness of the RPKI. If the WG chairs find themselves uncertain about the consensus on this quesiton, it might be helpful to ask ourselves: if we had chosen a certificate structure other than X.509, perhaps even something invented specifically for the purpose, would we be hesitating to make this change? At the very least, that could bring the discussion back to specific operational issues, which would, IMHO, be a good focus for it. Hopefully the chairs will see a consensus without needing to ask that question - the discussion I've read here suggests to me that we have at least a rough consensus. -- Sam From nobody Thu Nov 19 12:57:02 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1148F1B355D for ; Thu, 19 Nov 2015 12:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egyRf01vyj7r for ; Thu, 19 Nov 2015 12:56:59 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B94951B3558 for ; Thu, 19 Nov 2015 12:56:59 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 1C0DB28B0041; Thu, 19 Nov 2015 15:56:59 -0500 (EST) Received: from nova.tislabs.com (nova.tislabs.com [10.66.1.77]) by nova.tislabs.com (Postfix) with ESMTP id EFC301F801E; Thu, 19 Nov 2015 15:56:58 -0500 (EST) Date: Thu, 19 Nov 2015 15:56:58 -0500 (EST) From: Samuel Weiler To: Stephen Kent In-Reply-To: <563D1D0B.9030002@bbn.com> Message-ID: References: <563D1D0B.9030002@bbn.com> User-Agent: Alpine 2.03 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 20:57:01 -0000 On Fri, 6 Nov 2015, Stephen Kent wrote: > So, unless the folks who volunteered to assume responsibility for the > doc (all of whom were already listed as co-authors) are prepared to do a > much better job in addressing these shortcomings, I object to continuing > with this work. It sounds like you're objecting to the work because the editors of this WG draft have been insufficiently responsive to your criticisms. That sounds like a WG management issue, and I am disappointed that you would ask the WG to abandon useful work because of it. I take the view that document editors have been given the task of documenting the consensus of a WG. If you think the editors aren't documenting consensus correctly or are just doing a poor job with the writing, take it up with the chairs. It might be helpful to recruit some alternative editors, particularly ones who don't seem to have a strong bias re: the topic - finding good document editors is a persistent problem in many WGs. At the same time, recognize that if you're too far in the rough (which you might be), your own criticisms may not result in changes to the doc. -- Sam From nobody Thu Nov 19 20:00:24 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF131A0013; Thu, 19 Nov 2015 20:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.006 X-Spam-Level: X-Spam-Status: No, score=-4.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4h9z7Iu309To; Thu, 19 Nov 2015 20:00:20 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 736951A000D; Thu, 19 Nov 2015 20:00:20 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 19 Nov 2015 19:59:57 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Thu, 19 Nov 2015 19:59:57 -0800 From: Terry Manderson To: Sandra Murphy Thread-Topic: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rfc6485bis-04: (with DISCUSS) Thread-Index: AQHRIaYqmsaHDHQziEW3bXSM/x1U8J6kMreAgAFHjQA= Date: Fri, 20 Nov 2015 03:59:56 +0000 Message-ID: References: <20151118020907.790.34242.idtracker@ietfa.amsl.com> <938892D5-919F-4C61-B518-7145CB40A05B@tislabs.com> In-Reply-To: <938892D5-919F-4C61-B518-7145CB40A05B@tislabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3530872792_46719018" MIME-Version: 1.0 Archived-At: Cc: "sidr-chairs@ietf.org" , "draft-ietf-sidr-rfc6485bis@ietf.org" , The IESG , sidr wg list Subject: Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rfc6485bis-04: (with DISCUSS) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 04:00:22 -0000 --B_3530872792_46719018 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Sandy, On 20/11/2015 4:27 am, "Sandra Murphy" wrote: >A bit of history here. > >After RFC6485 was published, it was discovered that it incorrectly used >the same OID for all RPKI crypto uses, which conflicts with CMS specs and >is inconsistent with known implementations. I am aware of that. > >The wg decided to create RFC6485bis, to correct the OID problem and the >OID problem only, with emphasis on the =B3only=B2. Timeline leap is not your friend here. 6485 pre-dates 6916. 6485 is minimalist (and from a point of view, wrong) about algorithm changes. > >The =B3SHOULD=B2 language in section 5 is inherited from RFC6485, except for: > > The recommended > procedures to implement such a transition of key sizes and algorithms > is specified in [RFC6916] > >RFC6916, which was published a year after RFC6485, is "Algorithm Agility >Procedure for the Resource Public Key Infrastructure (RPKI)=B2. It >describes the procedure to follow in transitioning from one algorithm/key >size to another. Correct. It was this text that drew me to the section. And since the text pre-dates 6916, which takes a more encompassing view of an algorithm/profile change with a security section that adequately warns of invalidity due to a RP not supporting the new certificate profile, I view 6916 as more 'with the times' (YMMV). > >Does RFC6916 satisfy your concerns about a change of algorithm? It does a better job that allowing a CA or RP to opt out and fracture the RPKI. > >Would you prefer that RFC6485bis remove the inherited =B3SHOULD=B2 language >and point only to RFC6916? Yes, That is certainly one way to address this. And I would be OK with that. Cheers Terry > >=8BSandy > >On Nov 17, 2015, at 9:09 PM, Terry Manderson >wrote: > >> Terry Manderson has entered the following ballot position for >> draft-ietf-sidr-rfc6485bis-04: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to=20 >>https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/ >>=20 >>=20 >>=20 >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >>=20 >> I'm not so sure that this will be an easy DISCUSS to work through as I >> view this in light of future sustainability/deployability of RPKI and >>any >> protocol wedded to it (eg BGPSEC). >>=20 >> Section 5 "Additional Requirements" suggests that both CAs and RPs >> "SHOULD" be capable of supporting a transition and thus able to support >> multiple RPKI alg. and key profiles. To me this "SHOULD" seems like it >> invites fragility in any such transition. An immediate example would be >> the root DNSSEC ksk rollover. An rather large amount of work is underway >> to ascertain the impact. By leaving the SHOULDs in place is this walking >> the same path? >>=20 >> Let me ask another way. Under what situations is it actually appropriate >> for a CA or RP to be able to ignore the requirement of being able to >> support a phased introduction/deprecation of new/different RPKI >>algorithm >> and key profiles? And if they ignore such a recommendation does this >>make >> the entire RPKI infrastructure a fractured PKI by algorithm? >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > --B_3530872792_46719018 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIYwwYJKoZIhvcNAQcCoIIYtDCCGLACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FowwggV0MIIEXKADAgECAhAJ0fxYYYV36W1njUywVtW8MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNTAzMjYw MDAwMDBaFw0xODAzMjYxMjAwMDBaMIGQMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEYMBYGA1UEAxMPVGVycnkgTWFu ZGVyc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwTImt0Ol/9dOAbnm4lby 4RG1iQEnHVB5UJTYqwX8kqEhA5NPFHbMX22ChnP7M/zIlY+OP2TfKcwfdF5DJN4ybt4gFGzE 9ksigMe365F0uA2Q4+CskwqWo2fGIqrhgb0C68bg6EnZxj73KlJ0mvbQqzLBY8fVwr8srWpB BexjbYSeXp/+0W41ZOJPcdii59TDXRBGuziWjp+rd7yh8KCzKcj/Px1TzAE5U/TftZOfigYi h6KTTDZBGnN+4DDaaCnZ93rveayavI3hd4agqiIWe/gB78+0vHyk5DFoe6HkwuL0qJVaBW57 KIt8AYq+p0P+igNhiQoHkPx3VvS7ZViGdQIDAQABo4IB8jCCAe4wHwYDVR0jBBgwFoAU5wIj gABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFIXwv/ZX+K34v+mCL8g1Coo9c6lMMAwGA1Ud EwEB/wQCMAAwJAYDVR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYK YIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2Nh Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAH1Dvq3r4yh4+zU4t+5Rg3EzwMpSPxApBivVcW/KPq9uwdlu3yGBPJlG9 j4BXOT7fEUEGpCfyfRhBzTReyc2zask73fDRTzNFl5U3gqzOre5+Xtzv0qHyZGZ2EGcPTFv9 oaAVTug//Z6ZSr4dtDphV/7uSA4Hj1riFh5yxHErwUfrbCneIspVqwSVJqjkKWGID6W0YB0D cYJZGlyAH0FP/4+TMDxXOti2ypQrsZpNSfvc4TGC1p13Lyp4XEY+UysVtcypAgersTBN6gCb 7ueBt5KPTj9pH4w4C0lNO6rRIc6AGtJIuXHYyiy9CXUTOT5xLToXLZCyPXd+HFuWwdD9lzCC Bk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAw MFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr +Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQ elAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK 3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uC ig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j cmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgB hv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABD AGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBl AHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBD AFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBn AHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABp AHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQBy AGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8 lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrg YhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg 4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmw XZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1Y EhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3 MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBa Fw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg SUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfz t2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq 9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OM M9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJ fDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwO sLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1Ud IwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w 43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbG easS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59Pyvz tyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2 BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdh AbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIHAzCCBeugAwIBAgIQD89pSVGb AJQ9+ZeKCcX9BTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTEwHhcNMTIwMzI3MDAwMDAwWhcNMTUwMzI3MTIwMDAwWjCBrDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFzAVBgNVBAcTDk1hcmluYSBkZWwg UmV5MTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMg YW5kIE51bWJlcnMxFzAVBgNVBAsTDkROUyBPcGVyYXRpb25zMRgwFgYDVQQDEw9UZXJyeSBN YW5kZXJzb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkYWeFt1OjJ30tsKGB BQiMjfoNTDSC6JG1CpPj05eZpit0LVkMU0jrtrHczcRzMuqdkaE/QTBjmprbRatlrMEq7uv+ yU9U35crRmjx3yuZDD/6SOO4ZnMFBJvWdevSOWq+8wU4hAEANOnBirYCfF4oixVCBy1bkat1 hsY5xUx5QB12OpnYA0/57QJ6BL7z1ZuF6lJ4yYmU0qI88q9atkahb8l7Nm5TgEbpg6ryyN98 ixnFLmhC/gPoYKHczP3y+JHaMveuJl75hHq6ZuHeH2PyX20VFsXNBKJrvZ8BhTZOoozuNapP jiG6HLdqngPuTz3JVyTTR2FX809nclnxoMWjAgMBAAGjggNoMIIDZDAfBgNVHSMEGDAWgBQV ABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUs8L0dmF6T/V40vXJJzF+YNyzNo0wJAYD VR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDigNqA0hjJodHRw Oi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDCCAcUGA1Ud IASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0dHA6Ly93d3cu ZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEFBQcCAjCCAVYe ggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEA dABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8A ZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4AZAAgAHQA aABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUAbgB0ACAA dwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4AZAAgAGEA cgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIA ZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADggEBAGKcMSvyr3YW8kKqyqdspTEKTc6lR6H6OITyC056f6PlMmFZ+nWlkopWlflz QcxOUZv3+5rNogNcwczrxr+eaSx9J+pYCEU3rgBs3yiLDwsD72EJJDAD1x84fQOOJtfYb4oE 4Djzco83Dk4h6sMAiUg0xGcdewhJK80D6tb3xtS75PgFoxLcQrBprLghx2mY8EPErBiO1uXA NWOEU3EH+kvXiKUrDsFyGHQ4FqvVIYv2plu68ltOmBh+wR2oraoJpt9jGbond1MyVFOvi48e 7hgPRXupNbjxB4Wl0wKKGz0qT3ToBpp8VAkULtjiO/iPLx4knuwwvy5sRAwuZAfpVE4xggH/ MIIB+wIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQQIQCdH8WGGFd+ltZ41MsFbVvDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFGoj m/MnM4hbDHdVCqtA6cVPga6OMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE1MTEyMDAzNTk1MlowDQYJKoZIhvcNAQEBBQAEggEAmFut2A5OPEe5pQP0dJrk /4uajkGxxndjcOG5eT4LrHfrTvMKs1rKf7Z3/3TxmA/qqvzHwKatHOtz/kP0Ya8MLAwP7JV9 6heBQlriROUYdVkX5jAk2jCmq8rp+IbmLKvaDDK7ht14nC8vDeoUKP+KyvYixFXk/XR3Kljq JkU5wc39lY17qPPUQJPVNzXGVEaA1IbL/bERa0Rs50MaiZiVdPNuZUPtR3aMdwWKLFqFZIud dJr1I0bgqoYdaKGOtnC3FYF1GMwkgr+keGQPGClDGSGK7Ojq7fJlM4J2W2Kmv2iOcORs5Ldl ZjV2+FNNUmlr1/LrOFecxXFuZbWKI55VXA== --B_3530872792_46719018-- From nobody Fri Nov 20 08:34:20 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3451B3853 for ; Fri, 20 Nov 2015 08:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.887 X-Spam-Level: X-Spam-Status: No, score=-2.887 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCmrvyDcKXSz for ; Fri, 20 Nov 2015 08:34:18 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 183271B3855 for ; Fri, 20 Nov 2015 08:34:17 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:35295 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Zzoda-000OrU-Ew; Fri, 20 Nov 2015 11:34:14 -0500 From: Stephen Kent To: Samuel Weiler References: <563D1D0B.9030002@bbn.com> Message-ID: <564F4B86.4030104@bbn.com> Date: Fri, 20 Nov 2015 11:34:14 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 16:34:19 -0000 Sam, > On Fri, 6 Nov 2015, Stephen Kent wrote: > >> So, unless the folks who volunteered to assume responsibility for the >> doc (all of whom were already listed as co-authors) are prepared to >> do a much better job in addressing these shortcomings, I object to >> continuing with this work. > > It sounds like you're objecting to the work because the editors of > this WG draft have been insufficiently responsive to your criticisms. Non-responsive to specific suggested changes and noted technical flaws would be more accurate. > That sounds like a WG management issue, and I am disappointed that you > would ask the WG to abandon useful work because of it. Perhaps you have not been following this thread closely. Geoff said that he didn't want to continue as document editor, and that triggered the call by thew WG chairs as to whether the doc should die. I didn't initiate that question; I replied to it. > I take the view that document editors have been given the task of > documenting the consensus of a WG. If you think the editors aren't > documenting consensus correctly or are just doing a poor job with the > writing, take it up with the chairs. It might be helpful to recruit > some alternative editors, particularly ones who don't seem to have a > strong bias re: the topic - finding good document editors is a > persistent problem in many WGs. At the same time, recognize that if > you're too far in the rough (which you might be), your own criticisms > may not result in changes to the doc. Several folks who were listed as co-authors have offered to assume responsibility for the doc, so the "recruiting" task seems to have been done, at the behest of the WG chairs. As for their bias, I think they have an opportunity to revise the document in a way to avoid a perception of a strong bias, and they should be given a chance to do so. If I am in the rough, perhaps it's because I am one of the very few people who take time to read docs like this, in detail. I recall that Chris admitted, at the mic, that he had not read the adverse actions I-D, so I don't know if he also didn't read (or read carefully) the validation reconsidered doc. I get the sense that folks often express support for a doc based on a slide presentation, rather that reading the doc. Its a problem in many WGs, and this one probably is not an exception. Steve From nobody Fri Nov 20 10:17:08 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2E31B3B51 for ; Fri, 20 Nov 2015 10:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRK8jJejl2tV for ; Fri, 20 Nov 2015 10:17:05 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (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 C22C91B3B47 for ; Fri, 20 Nov 2015 10:17:05 -0800 (PST) Received: by ykdr82 with SMTP id r82so173052728ykd.3 for ; Fri, 20 Nov 2015 10:17:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jV7lqszIlq1wewDl6VOd9uxXTXnUtPMhAVS39/VzyIw=; b=d8pRrLawhBQO/HYogIJ1kbOMPXhA76nYZNPyLbEzdzVMR99kN/6a6wapjBMFHwAMrg 8BECyyK+NbiteItE6nw5fu6ir2kZf0auddICB0H8JvKD85+zrvCDUFsst8V8kKoZ7jo2 Ym9xSYFEIv9BJIGqSWvxD7uEfsRXizi1LqPmv+r36Gf9BYe/Ox55N9sAnUxmIjPfPFCn GGnJpu7ev1kqCJhL9AOl/cLpAy7vXSAO0NXJfC7WhxfAKWQIQfjkcLgCFkxZ/0wJWiC+ vf/iXbvgfQby5ASY5mIiFl6wn2nmPviKRJB+TfIyzReMFzKn5dLYQ+aJ9CP7rQ5AFfqD scRA== MIME-Version: 1.0 X-Received: by 10.13.232.2 with SMTP id r2mr10359234ywe.45.1448043425043; Fri, 20 Nov 2015 10:17:05 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.129.99.9 with HTTP; Fri, 20 Nov 2015 10:17:04 -0800 (PST) In-Reply-To: <564F4B86.4030104@bbn.com> References: <563D1D0B.9030002@bbn.com> <564F4B86.4030104@bbn.com> Date: Fri, 20 Nov 2015 13:17:04 -0500 X-Google-Sender-Auth: J-Blc1Zx6wOJLzSVBqnglCXBzBg Message-ID: From: Christopher Morrow To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Samuel Weiler , "sidr@ietf.org" Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 18:17:07 -0000 On Fri, Nov 20, 2015 at 11:34 AM, Stephen Kent wrote: > > If I am in the rough, perhaps it's because I am one of the very few people > who > take time to read docs like this, in detail. I recall that Chris admitted, > at the > mic, that he had not read the adverse actions I-D, so I don't know if he > also I didn't read the adverse actions well enough to matter, yes. > didn't read (or read carefully) the validation reconsidered doc. I get the > sense I did read the validation reconsidered doc a few times... most recently when making the presentation I gave. I didn't enjoy some of the text as much, and think a bunch of 'clean up the wording' has to happen, but I do think (as my slides said) that the intent is an appropriate change to improve robustness of the system. -chris From nobody Sat Nov 21 06:24:38 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540201AC3DB for ; Sat, 21 Nov 2015 06:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.215 X-Spam-Level: X-Spam-Status: No, score=0.215 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_OOubuX65Du for ; Sat, 21 Nov 2015 06:24:36 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 521ED1AC3BF for ; Sat, 21 Nov 2015 06:24:36 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1a095e-0006lH-JD; Sat, 21 Nov 2015 14:24:34 +0000 Date: Sat, 21 Nov 2015 15:24:33 +0100 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <563D1D0B.9030002@bbn.com> <564F4B86.4030104@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr wg list Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2015 14:24:37 -0000 > the intent is an appropriate change to improve robustness of the > system. i think it changes the robustness, not necessarily improves it. the loss of congruent hierarchic validation is exchanged for accepting some failures we have yet to see. being a bit of a naggumite, accepting errors is not big on my agenda. one of my disagreements with dr postel was the receiver side of the robustness principle. this way lies entropic death. randy From nobody Mon Nov 23 14:13:43 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1DF1B3B21 for ; Mon, 23 Nov 2015 14:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qs39ue0FXBMC for ; Mon, 23 Nov 2015 14:13:41 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::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 28A7E1B3B20 for ; Mon, 23 Nov 2015 14:13:41 -0800 (PST) Received: by ykdr82 with SMTP id r82so253720804ykd.3 for ; Mon, 23 Nov 2015 14:13:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=Nj0MUuI11Hu7fiOm8BHrxYlaWnJ/c72o2qLiQae4uro=; b=kAgv26bW5vKvmzetdRP1eAAyrg9RnYlrGMxGubIfnU4sGE5yV+xxHUMNCKFYHwgwT/ s9zsTWYfjAzRK5yhtp/PLPIyofA5xpFVveegv+W1hTk9LPT7pSUYX4UH0Kjp8Gj/ixxc der6O/nFQJ6DL/317SbzlHKaCgLSVRjhXaGXS8NBhN90sMpubLlK7ZCvy54SfAOEIsCb pADbOM90L69h2J/rOIqCk1lWnNoowgcS+7RhaYmzq2m+fT5CGNvN1v5r2UoVftts49wW J29bVCDl08liIUeW527sDK6YDAkoClTr1oHOJfP2c71qR4egHjrONFOZUH07smmY69S5 WQ9A== MIME-Version: 1.0 X-Received: by 10.13.232.2 with SMTP id r2mr22935604ywe.45.1448316820403; Mon, 23 Nov 2015 14:13:40 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.129.99.9 with HTTP; Mon, 23 Nov 2015 14:13:40 -0800 (PST) In-Reply-To: References: <563D1D0B.9030002@bbn.com> <564F4B86.4030104@bbn.com> Date: Mon, 23 Nov 2015 17:13:40 -0500 X-Google-Sender-Auth: 6RASVuNIgV8tHhku3bDV8SjMZsk Message-ID: From: Christopher Morrow To: sidr wg list Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 22:13:42 -0000 Pinging this thread to catch anyone who didn't reply but had thoughts I'd like to close this out tomorrow before 5pm EST (10pm UTC). thanks! -chris On Sat, Nov 21, 2015 at 9:24 AM, Randy Bush wrote: >> the intent is an appropriate change to improve robustness of the >> system. > > i think it changes the robustness, not necessarily improves it. the > loss of congruent hierarchic validation is exchanged for accepting some > failures we have yet to see. > > being a bit of a naggumite, accepting errors is not big on my agenda. > one of my disagreements with dr postel was the receiver side of the > robustness principle. this way lies entropic death. > > randy From nobody Tue Nov 24 07:11:36 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5204B1A8740 for ; Tue, 24 Nov 2015 07:11:34 -0800 (PST) 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgd7QIpJa28D for ; Tue, 24 Nov 2015 07:11:30 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0701.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::701]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E91251A8756 for ; Tue, 24 Nov 2015 07:11:29 -0800 (PST) Received: from SN1PR09MB0943.namprd09.prod.outlook.com (10.162.102.143) by SN1PR09MB0942.namprd09.prod.outlook.com (10.162.102.142) with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 24 Nov 2015 15:11:14 +0000 Received: from SN1PR09MB0943.namprd09.prod.outlook.com ([10.162.102.143]) by SN1PR09MB0943.namprd09.prod.outlook.com ([10.162.102.143]) with mapi id 15.01.0331.019; Tue, 24 Nov 2015 15:11:14 +0000 From: "Montgomery, Douglas" To: Christopher Morrow , sidr wg list Thread-Topic: [sidr] Validation Reconsidered (again/again) question Thread-Index: AQHRGDXGG4faZWVzbkuYHaiYQ3hDdJ6PhZeAgBRjpgCAAUjsAIAAHLwAgAFRXoCAA6e7AIAAyG4A Importance: low X-Priority: 5 Date: Tue, 24 Nov 2015 15:11:13 +0000 Message-ID: References: <563D1D0B.9030002@bbn.com> <564F4B86.4030104@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 authentication-results: spf=none (sender IP is ) smtp.mailfrom=dougm@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.140.29] x-microsoft-exchange-diagnostics: 1; SN1PR09MB0942; 5:dY1fiVvFGG0fwnRzd41IOhUg/kei1bMqmvPlgJ0s5UEIgVK1i9QarZj4ClKAvwQORgrbMe+5vJ+9Vj9KFkBoJwNahODe33CLwTU8XuITCrCx1exX2zwbQ979h3VWSR2ioql4yy0e3rM+ohmao5BKYg==; 24:53vjA33mZ/Tv4YAiAvI2QZRFVTQ7U5acbjaaG5Ml/0RGptJAV/vRVd+5BU+pZ6szazTmNCDxkCa/2IXF4u7N4eoaMNtm0VkmSAQk8wR7EL4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR09MB0942; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:SN1PR09MB0942; BCL:0; PCL:0; RULEID:; SRVR:SN1PR09MB0942; x-forefront-prvs: 0770F75EA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(479174004)(24454002)(377454003)(50986999)(122556002)(86362001)(40100003)(93886004)(10400500002)(5008740100001)(92566002)(105586002)(5002640100001)(106116001)(106356001)(101416001)(3846002)(586003)(81686999)(83506001)(5004730100002)(36756003)(87936001)(5007970100001)(6116002)(5001920100001)(76176999)(102836003)(15975445007)(54356999)(11100500001)(189998001)(81156007)(77096005)(5001770100001)(19580395003)(97736004)(4001350100001)(5001960100002)(107886002)(19580405001)(2950100001)(2900100001)(66066001)(99286002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR09MB0942; H:SN1PR09MB0943.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <785ABD3D56389F48B9E5679FEA2DEA92@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2015 15:11:13.9616 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR09MB0942 Archived-At: Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 15:11:34 -0000 SSB3b3VsZCBsaWtlIHRvIHNlZSB0aGlzIHdvcmsgY29udGludWUuICBFdmVyeSBwdWJsaWMvcHJp dmF0ZSB3b3JraW5nDQpncm91cCB0aGF0IEkgaGF2ZSBiZWVuIHBhcnQgb2YgdGhhdCBkaXNjdXNz ZXMgcG90ZW50aWFsIGluY3JlbWVudGFsIHJvbGwNCm91dCBvZiBSUEtJIGJhc2VkIG9yaWdpbiB2 YWxpZGF0aW9uIGdldHMgaHVuZyB1cCBvbiBGVUQgYWJvdXQgdGhlDQpicml0dGxlbmVzcyBvZiB0 aGUgc3lzdGVtLiAgIFdoaWxlIHZhbGlkYXRpb24gcmVjb25zaWRlcmVkIGRvZXMgbm90IHNvbHZl DQphbGwgcG90ZW50aWFsIHRocmVhdHMvZXJyb3JzLCBpdCBkb2VzIG1pdGlnYXRlIG9uZSBzY2Vu YXJpbywgd2l0aA0Kc2lnbmlmaWNhbnQgcG90ZW50aWFsIGFtcGxpZmljYXRpb24gZWZmZWN0cywg dGhhdCBJIGhhdmUgaGVhcmQgbWVudGlvbmVkDQppbiB0aGVzZSBkaXNjdXNzaW9ucy4NCg0KSSB3 b3VsZCBwcmVmZXIgdG8gYXZvaWQgYXMgbWFueSBmYWlsdXJlIHNjZW5hcmlvcyBhcyBwb3NzaWJs ZSwgcmF0aGVyIHRoYXQNCmZvY3VzIG9uIHdheXMgb2YgZGV0ZWN0aW5nIHRoZW0gd2hlbiB0aGV5 IGRvIG9jY3VyLg0KDQpkb3VnbQ0K4oCUIA0KRG91ZyBNb250Z29tZXJ5LCBNZ3IgSW50ZXJuZXQg JiBTY2FsYWJsZSBTeXN0ZW1zIFJlc2VhcmNoIGF0ICBOSVNUL0lUTC9BTlREDQoNCg0KDQoNCg0K T24gMTEvMjMvMTUsIDU6MTMgUE0sICJzaWRyIG9uIGJlaGFsZiBvZiBDaHJpc3RvcGhlciBNb3Jy b3ciDQo8c2lkci1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBtb3Jyb3djLmxpc3RzQGdt YWlsLmNvbT4gd3JvdGU6DQoNCj5QaW5naW5nIHRoaXMgdGhyZWFkIHRvIGNhdGNoIGFueW9uZSB3 aG8gZGlkbid0IHJlcGx5IGJ1dCBoYWQgdGhvdWdodHMNCj5JJ2QgbGlrZSB0byBjbG9zZSB0aGlz IG91dCB0b21vcnJvdyBiZWZvcmUgNXBtIEVTVCAoMTBwbSBVVEMpLg0KPg0KPnRoYW5rcyENCj4t Y2hyaXMNCj4NCj5PbiBTYXQsIE5vdiAyMSwgMjAxNSBhdCA5OjI0IEFNLCBSYW5keSBCdXNoIDxy YW5keUBwc2cuY29tPiB3cm90ZToNCj4+PiB0aGUgaW50ZW50IGlzIGFuIGFwcHJvcHJpYXRlIGNo YW5nZSB0byBpbXByb3ZlIHJvYnVzdG5lc3Mgb2YgdGhlDQo+Pj4gc3lzdGVtLg0KPj4NCj4+IGkg dGhpbmsgaXQgY2hhbmdlcyB0aGUgcm9idXN0bmVzcywgbm90IG5lY2Vzc2FyaWx5IGltcHJvdmVz IGl0LiAgdGhlDQo+PiBsb3NzIG9mIGNvbmdydWVudCBoaWVyYXJjaGljIHZhbGlkYXRpb24gaXMg ZXhjaGFuZ2VkIGZvciBhY2NlcHRpbmcgc29tZQ0KPj4gZmFpbHVyZXMgd2UgaGF2ZSB5ZXQgdG8g c2VlLg0KPj4NCj4+IGJlaW5nIGEgYml0IG9mIGEgbmFnZ3VtaXRlLCBhY2NlcHRpbmcgZXJyb3Jz IGlzIG5vdCBiaWcgb24gbXkgYWdlbmRhLg0KPj4gb25lIG9mIG15IGRpc2FncmVlbWVudHMgd2l0 aCBkciBwb3N0ZWwgd2FzIHRoZSByZWNlaXZlciBzaWRlIG9mIHRoZQ0KPj4gcm9idXN0bmVzcyBw cmluY2lwbGUuICB0aGlzIHdheSBsaWVzIGVudHJvcGljIGRlYXRoLg0KPj4NCj4+IHJhbmR5DQo+ DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zaWRy IG1haWxpbmcgbGlzdA0KPnNpZHJAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NpZHINCg0K From nobody Tue Nov 24 08:22:05 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB281A8BC1 for ; Tue, 24 Nov 2015 08:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljOjezjq3poL for ; Tue, 24 Nov 2015 08:22:01 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::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 1EDFD1A8BB7 for ; Tue, 24 Nov 2015 08:22:01 -0800 (PST) Received: by ykdv3 with SMTP id v3so24377045ykd.0 for ; Tue, 24 Nov 2015 08:22:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=IHPsg1KvcqaLH+cz4PmqIxY1ABvDjj1Bsxt/OZNqvBc=; b=kSh/aiaVuwfuErnxIlDppxuIi1+4LDT25LhpuNu4iLn5QTD6kAZmR6IaLSIZYVyQnU zEPkAsy2ht8EzWCEx2wHk6PRfYTImHIvestIK7LK2td47ifydaLhL1SjDSr9ZsMGsLOy FXPsR2D1xZ63dhP0BvuCY82xNg2Dfjyt0D3lMqhZJnv9QJuJX+JzraW6FT3WgI+9scrx 9BRd2MOTQdBvzitA5T3siMwNJfjWh9+BwcOTsoEaznPM0DplM8o2d6Kr+EwHqW2F8r6j DYMcvvfwyNx57Kxf2fx7TdYej06fbc3zz78kA4m+Pu+Q4nYzKOGqRDpW2R5Q+GxhOUgo yySQ== MIME-Version: 1.0 X-Received: by 10.129.113.84 with SMTP id m81mr13618360ywc.180.1448382120386; Tue, 24 Nov 2015 08:22:00 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.129.99.9 with HTTP; Tue, 24 Nov 2015 08:22:00 -0800 (PST) In-Reply-To: References: <563D1D0B.9030002@bbn.com> <564F4B86.4030104@bbn.com> Date: Tue, 24 Nov 2015 11:22:00 -0500 X-Google-Sender-Auth: -wxxq8svIKkt4yh12IlIbwYjaP4 Message-ID: From: Christopher Morrow To: sidr wg list Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 16:22:03 -0000 On Mon, Nov 23, 2015 at 5:13 PM, Christopher Morrow wrote: > Pinging this thread to catch anyone who didn't reply but had thoughts > I'd like to close this out tomorrow before 5pm EST (10pm UTC). > Damn my lack of date specificity!! To be clear, I'd like to make the call on this: 2015-11-25 10pm UTC (November 25 2015 10pm UTC) > thanks! > -chris > > On Sat, Nov 21, 2015 at 9:24 AM, Randy Bush wrote: >>> the intent is an appropriate change to improve robustness of the >>> system. >> >> i think it changes the robustness, not necessarily improves it. the >> loss of congruent hierarchic validation is exchanged for accepting some >> failures we have yet to see. >> >> being a bit of a naggumite, accepting errors is not big on my agenda. >> one of my disagreements with dr postel was the receiver side of the >> robustness principle. this way lies entropic death. >> >> randy From nobody Tue Nov 24 09:58:07 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AEDF1B306F for ; Tue, 24 Nov 2015 09:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jteIM6prxlcS for ; Tue, 24 Nov 2015 09:58:05 -0800 (PST) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) (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 E2D691B3066 for ; Tue, 24 Nov 2015 09:58:04 -0800 (PST) Received: from localhost (75-101-67-207.dsl.dynamic.omsoft.com [75.101.67.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 5AD3D2330C; Tue, 24 Nov 2015 09:58:03 -0800 (PST) From: Wes Hardaker To: Christopher Morrow References: <563D1D0B.9030002@bbn.com> <564F4B86.4030104@bbn.com> Date: Tue, 24 Nov 2015 09:58:03 -0800 In-Reply-To: (Christopher Morrow's message of "Mon, 23 Nov 2015 17:13:40 -0500") Message-ID: <0llh9ni8k4.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: sidr wg list Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 17:58:06 -0000 Christopher Morrow writes: > Pinging this thread to catch anyone who didn't reply but had thoughts > I'd like to close this out tomorrow before 5pm EST (10pm UTC). I've been considering the concept behind this document and whether the concept should be carried forward by the working group. To me the starting ID is frequently badly written or has too few editors, etc. That always changes over time, so I'm not concerned about that issue in particular until it is proven that no one will take it up (and many won't volunteer for a question mark). So, on to the concept: in my younger years I was very strict and I would have been against this concept from the beginning, because it does bring the status of a given certificate into question. But my older and wiser self has seen far too many difficult and failed protocol deployments because of the complexity associated with "everyone everywhere needs to do the right thing all the time". To me, the validation reconsidered proposal mitigates some of the very likely real-world, real-human deployment scenarios. And I don't think that the RPKI publicity side can take too many negative hits (again, because I've watched too many other protocols slow down at the minimum when negative publicity hits them). In short, the validation reconsidered concept reduces the real-world impact of necessary and accidental changes, which to me means a deployment base that will be stronger even though we're "allowing more". Does that do strange things to the status of a given certificate? Yes, it definitely does. I know this will ruffle some feathers: but I believe the goal of the RPKI was to make a decision, based on available data, about the ability to trust that origin's announcement. Everything else has come after, or more likely as a result of implementing, that goal. The RPKI makes use of PKIX and certificates to achieve that goal, and along the way became a fundamental staple that we're hesitant to change. In the end, however, when I look at the primary original goal, along with the need for a robust deployment, the validation reconsidered proposal seems well worth the trade offs. -- Wes Hardaker Parsons From nobody Tue Nov 24 14:35:43 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D0E1A90C2 for ; Tue, 24 Nov 2015 14:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUpbkuovbp1Y for ; Tue, 24 Nov 2015 14:35:40 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA9C71A90BC for ; Tue, 24 Nov 2015 14:35:40 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1a1MBW-0004ql-IH; Tue, 24 Nov 2015 22:35:38 +0000 Date: Tue, 24 Nov 2015 23:35:37 +0100 Message-ID: From: Randy Bush To: Douglas Montgomery In-Reply-To: References: <563D1D0B.9030002@bbn.com> <564F4B86.4030104@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr wg list Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 22:35:41 -0000 > Every public/private working group that I have been part of that > discusses potential incremental roll out of RPKI based origin > validation gets hung up on FUD about the brittleness of the system. universally, the brittleness that seems to concern operators is the hierarchy and the 'dutch court' attack. this does nothing for that. the brittleness this seems to address is perceived by rirs, who have already deployed. so i do not see this as solving a real deployment issue. otoh, i do not see it as being highly destructive. more of a not clearly needed change when there is plenty of other work to be done. randy From nobody Wed Nov 25 00:21:35 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB841A8A9C for ; Wed, 25 Nov 2015 00:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.085 X-Spam-Level: X-Spam-Status: No, score=-1.085 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzLIMj_M8CB3 for ; Wed, 25 Nov 2015 00:21:33 -0800 (PST) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FE561A8A6D for ; Wed, 25 Nov 2015 00:21:33 -0800 (PST) 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) (envelope-from ) id 1a1VKU-0000z3-DB for sidr@ietf.org; Wed, 25 Nov 2015 09:21:31 +0100 Received: from gibbon.ripe.net ([193.0.1.206] helo=[127.0.0.1]) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1a1VKU-0003OT-3f for sidr@ietf.org; Wed, 25 Nov 2015 09:21:30 +0100 References: <563D1D0B.9030002@bbn.com> <564F4B86.4030104@bbn.com> To: sidr wg list From: Robert Kisteleki X-Enigmail-Draft-Status: N1110 Organization: RIPE NCC Message-ID: <56556F89.1010206@ripe.net> Date: Wed, 25 Nov 2015 09:21:29 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ACL-Warn: Delaying message X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.5 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274f791872522fc40b27f5cc551ebb8453b Archived-At: Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 08:21:34 -0000 On 2015-11-24 23:35, Randy Bush wrote: >> Every public/private working group that I have been part of that >> discusses potential incremental roll out of RPKI based origin >> validation gets hung up on FUD about the brittleness of the system. > > universally, the brittleness that seems to concern operators is the > hierarchy and the 'dutch court' attack. this does nothing for that. Indeed it doesn't solve all possible problems. But it solves a real tangible one. > the brittleness this seems to address is perceived by rirs, who have > already deployed. RIRs are expected to be higher-than-average in the certificate chain, therefore any mistake made on this level could affect a large population. However, the issue addressed can happen on any level and will affect any descendants -- therefore benefits apply to them to. > so i do not see this as solving a real deployment issue. otoh, i do > not see it as being highly destructive. more of a not clearly needed > change when there is plenty of other work to be done. I don't think we should accept the situation that, for example, my certificate (and ROA, whatever) covering my precious prefix will become invalid because my grand-grand-grandparent, whom I never met, made a booboo about an ASN they never had. Therefore I think this draft, or the concept therein, should be completed. Robert From nobody Wed Nov 25 06:25:55 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2F01B2D56 for ; Wed, 25 Nov 2015 06:25:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBTtBR-RKxI6 for ; Wed, 25 Nov 2015 06:25:52 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AED01B2D54 for ; Wed, 25 Nov 2015 06:25:51 -0800 (PST) Received: by ykdr82 with SMTP id r82so56896773ykd.3 for ; Wed, 25 Nov 2015 06:25:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=5rfmcQA9hZgwiBG/uV1kcK7B2hdMWFkPdf8XWsiG4xY=; b=xa9fwS9YurKk5TSfR6nwXtfjypwqaYftcYMvwwcNk8ZZT9gv8bZt4QUjSPtXhbJM3n jmFhAXv3nUDq0PyqHaCF0UpspLmqoKqt78SQqjXK0q9Akir4e1iiBTna3q/Ca825JHCh wm/aT9h6hPegE4Ho7l6f7tVvwcJxJt8fjT1kSjQdiBZQ/Q67l7lrYkOMbh+scV+tRt4m khrr85gQlyRvdYC525P7tMXZlYaqVUhRDzy6n0gSSvdG1rsirBjd/Ys8O811oeNISsMI 1GcqeqDEdX15ATmIVuVp6mk9hFhy3o6nOaBiiXkHNp6sv3+Ih/Yj06cQ3teRQyeh1eo4 bjtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=5rfmcQA9hZgwiBG/uV1kcK7B2hdMWFkPdf8XWsiG4xY=; b=FUKLvrfka6D6rY8e4Dd3SvPhVWZiAvecU5XZGAB+ovZayWhIJ+DXadxpcP5I3Rs8bb tf1Rf9E6a3tXQeC+IKGl3gwIF3D1HEMbpNHBisrbD/RS/BpL81Mmc7+iLGftKOP4D+PD 3mkdOAG2rAM/rpkTIXk7uNGJMCFhu67//8uwmgc7W2OawVU/Lgb9yCVkpMArmpfvnUXW QrRs9kG1Ke3LvFZ5pcOLARBLKKcskxlZDstNSY4K6IKBhdDaJi5/orss+VrNAc6eKg5G 0AgwK85yDLdXRmjWWIv9991lVHYjiK2bHDbYWQA3AOrIxJ48+t6ed7gGc5FIfTrQsGBA zTDA== X-Gm-Message-State: ALoCoQlVognmRE+vFXfEenmjhWz2Pjnb+QPmhXZ7auePfbtiJxLCPUsRsZS46ZK74pM7yQorKKX/ X-Received: by 10.13.206.70 with SMTP id q67mr31967308ywd.249.1448461551054; Wed, 25 Nov 2015 06:25:51 -0800 (PST) MIME-Version: 1.0 References: <563D1D0B.9030002@bbn.com> <564F4B86.4030104@bbn.com> <0llh9ni8k4.fsf@wjh.hardakers.net> In-Reply-To: <0llh9ni8k4.fsf@wjh.hardakers.net> From: Warren Kumari Date: Wed, 25 Nov 2015 14:25:41 +0000 Message-ID: To: Wes Hardaker , Christopher Morrow Content-Type: multipart/alternative; boundary=001a114daf8238e2f605255e3c20 Archived-At: Cc: sidr wg list Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 14:25:54 -0000 --001a114daf8238e2f605255e3c20 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 24, 2015 at 12:58 PM Wes Hardaker wrote: > Christopher Morrow writes: > > > Pinging this thread to catch anyone who didn't reply but had thoughts > > I'd like to close this out tomorrow before 5pm EST (10pm UTC). > > I've been considering the concept behind this document and whether the > concept should be carried forward by the working group. To me the > starting ID is frequently badly written or has too few editors, etc. > That always changes over time, so I'm not concerned about that issue in > particular until it is proven that no one will take it up (and many > won't volunteer for a question mark). > > So, on to the concept: in my younger years I was very strict and I would > have been against this concept from the beginning, because it does bring > the status of a given certificate into question. But my older and wiser > self has seen far too many difficult and failed protocol deployments > because of the complexity associated with "everyone everywhere needs to > do the right thing all the time". To me, the validation reconsidered > proposal mitigates some of the very likely real-world, real-human > deployment scenarios. And I don't think that the RPKI publicity side > can take too many negative hits (again, because I've watched too many > other protocols slow down at the minimum when negative publicity hits > them). In short, the validation reconsidered concept reduces the > real-world impact of necessary and accidental changes, which to me means > a deployment base that will be stronger even though we're "allowing > more". > > Does that do strange things to the status of a given certificate? Yes, > it definitely does. I know this will ruffle some feathers: but I > believe the goal of the RPKI was to make a decision, based on available > data, about the ability to trust that origin's announcement. Everything > else has come after, or more likely as a result of implementing, that goal. > The RPKI makes use of PKIX and certificates to achieve that goal, and > along the way became a fundamental staple that we're hesitant to > change. > > In the end, however, when I look at the primary original goal, along > with the need for a robust deployment, the validation reconsidered > proposal seems well worth the trade offs. > I've been delaying responding because I wasn't sure how to articulate my thoughts (and because I got sidetracked!). Wes managed to capture what I was thinking nicely. We should complete this. Hopefully I'm not too late for my views to be taken into account. W > > -- > Wes Hardaker > Parsons > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --001a114daf8238e2f605255e3c20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Nov 24= , 2015 at 12:58 PM Wes Hardaker <wjhns1@hardakers.net> wrote:
morrowc.lists@gmail.com> writes:

> Pinging this thread to catch anyone who didn't reply but had thoug= hts
> I'd like to close this out tomorrow before 5pm EST (10pm UTC).

I've been considering the concept behind this document and whether the<= br> concept should be carried forward by the working group.=C2=A0 To me the
starting ID is frequently badly written or has too few editors, etc.
That always changes over time, so I'm not concerned about that issue in=
particular until it is proven that no one will take it up (and many
won't volunteer for a question mark).

So, on to the concept: in my younger years I was very strict and I would have been against this concept from the beginning, because it does bring the status of a given certificate into question.=C2=A0 But my older and wis= er
self has seen far too many difficult and failed protocol deployments
because of the complexity associated with "everyone everywhere needs t= o
do the right thing all the time".=C2=A0 To me, the validation reconsid= ered
proposal mitigates some of the very likely real-world, real-human
deployment scenarios.=C2=A0 And I don't think that the RPKI publicity s= ide
can take too many negative hits (again, because I've watched too many other protocols slow down at the minimum when negative publicity hits
them).=C2=A0 In short, the validation reconsidered concept reduces the
real-world impact of necessary and accidental changes, which to me means a deployment base that will be stronger even though we're "allowin= g
more".

Does that do strange things to the status of a given certificate?=C2=A0 Yes= ,
it definitely does.=C2=A0 I know this will ruffle some feathers: but I
believe the goal of the RPKI was to make a decision, based on available
data, about the ability to trust that origin's announcement.=C2=A0 Ever= ything
else has come after, or more likely as a result of implementing, that goal.=
The RPKI makes use of PKIX and certificates to achieve that goal, and
along the way became a fundamental staple that we're hesitant to
change.

In the end, however, when I look at the primary original goal, along
with the need for a robust deployment, the validation reconsidered
proposal seems well worth the trade offs.

I've been delaying responding because I wasn't sure how to artic= ulate my thoughts (and because I got sidetracked!).

Wes managed to capture what I was thinking nicely.=C2=A0

We should complete this.

Hopefully I'= m not too late for my views to be taken into account.
W
=C2=A0

--
Wes Hardaker
Parsons

_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
--001a114daf8238e2f605255e3c20-- From nobody Wed Nov 25 12:19:59 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23AA11B2F53 for ; Wed, 25 Nov 2015 12:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNd3mh2_HhbL for ; Wed, 25 Nov 2015 12:19:54 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A7961B2F59 for ; Wed, 25 Nov 2015 12:19:54 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:36966 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1a1gXg-000Ant-O6 for sidr@ietf.org; Wed, 25 Nov 2015 15:19:53 -0500 From: Stephen Kent To: sidr Message-ID: <565617E8.4070005@bbn.com> Date: Wed, 25 Nov 2015 15:19:52 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------000209060609000206050400" Archived-At: Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 20:19:58 -0000 This is a multi-part message in MIME format. --------------000209060609000206050400 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit None of those who believe that this draft is a good thing seem to have addressed an issue I raised a while ago; the proposed solution is ill-defined and, the most likely interpretation doesn't seem to work, in general. I'll try to explain this reasoning, again, and provide an example. Section 2 of the I-D says: Validation of signed resource data using a target resource certificate, and a specific set of number resources, consists of verifying that the digital signature of the signed resource data is valid, using the public key of the target resource certificate, and also validating the resource certificate in the context of the RPKI, using the path validation process. Personally, I have trouble understanding what that 5 1/2 line sentence means, in no small part because the phrase "signed resource data" is not defined anywhere in the I-D. The text that follows reproduces, with one exception, the path validation description from 6487, so I assume that the text is proposing a change to that path validation process. PowerPoint Presentation The one change made to the path validation procedure in RFC 6487 arises in step 6, which is reworded to be: The resource extension data contained in this certificate "encompasses" the entirety of the resources in the specific resource set ("encompass" in this context is defined in Section 7.1 of [RFC6487]). PowerPoint Presentation PowerPoint Presentation As I noted before, the phrase "_specific_ resource set" is undefined in the I-D. I'm guessing that many folks believe this term refers to any address space and ASN extensions in the cert being validated. That's a simple, reasonable interpretation of the text, and the authors have not stated a different intent, so let's proceed on that assumption. Consider the following example that, WLOG, focuses only on address space. Consider a cert path from a trust anchor TA, to CA1 to CA2 to an EE cert for a ROA. TA->CA 1->CA 2->ROA Assume the TA cert contains address space T, U, V, W, X, Y and Z. Assume the CA 1 cert contains address space T, U, V, and W. Assume the CA 2 cert contains address space V and W. Let's say that the ROA EE cert issued by CA 2 contains address space V. CA 2 is about to receive address space Z from some other ISP, so it has asked CA 1 to issue a new CA cert to it, in anticipation of the transfer. CA 1 agrees, and issues a new cert to CA 2 and that cert contains address space V and Z. Now, under the assumption about what "specific resource set" means, when an RP tries to validate CA 2's ROA, the "specific resource set" will be V, and so it will be valid, because V is in all of the certs from the TA through CA 1 to CA 2. Even though CA 2's cert contains Z, which is not contained in CA 1's cert, this will not be considered in the validation of the ROA EE cert. This is the desired outcome, because CA 2 has begun the process of getting its new address space (Z), but that process has not broken its CA cert. I assume this is an example of the reduced fragility that is so appealing. If CA 2 issued a ROA for Z, then validation of that ROA would fail, because the CA 1 cert does not contain Z. That's good, because the second ROA exmaple ought not be valid, since the transfer has not yet completed. So far, so good. But, let's look at the implications of this revised validation procedure in greater depth. What if CA 1, acting on the request from CA 2 asked the TA to add Z to CA 2's cert, in anticipation of the transfer? Then we have a problem, because Z is under the tree from this TA and if it agreed to add Z to CA 1's cert, then a ROA for Z, issued by CA 2, would be valid, even though the transfer had not yet been effected. So, when folks claim that this alg allows for transfers to not have to follow a strict ordering of RPKI actions, that is only partly true. Issuing a new CA cert with resources not yet transferred to the target can actually enable the target to generate bogus ROAs that will validate, unless certain precautions are taken. Every CA has to be sure that IF it issues a cert to a subordinate because of an anticipated transfer, that this act does not enable the subordinate (or a child of the subordinate ...) to issue bogus ROAs! Right now we have no agreed-upon resource transfer process for the RPKI, to ensure that this sort of vulnerability does not arise. Yet the suggestion is to change the validation procedure before having such a process in place. Not such a good idea. A bigger problem, IMHO, is that if an RP validates CA 2's (new) cert, the "specific resource set" will be V and Z (according to the interpretation cited above). However, using the revised step 6, validation will fail, because CA 1's cert does not contain Z. To avoid this problem, RPs would have to not validate CA certs that might contain address space that is not present in _all_ the certs along the path. This is a bad outcome, for two reasons. An RP should validate each CA cert it fetches, to minimize opportunities for DoS attacks. An RP also should be able to maintain a local cache where it need not walk the whole path to a TA every time a new cert (of any type) appears. Note, for example, that new manifest certs are issued daily. So, if one tries to take advantage of the reduced fragility promised by this change to step 6, a CA cert with resources not present in all if its parent certs will fal validation anyway. Not such a great outcome. Also recall that new CRLs tend to be issued at least daily. To validate a CRL an RP uses the public key from the CA cert under which the CRL was issued. That implies the RP has validated the CA cert before using the public key from it. Yet, as noted above, if the CA cert has address space not contained in all of its parents, that cert will be invalid. So, RPs would have to treat CRL validation as a special case, using a public key from a CA cert that has not been validated relative to the revised process, to avoid this problem. Again, I see this as not a great outcome, as it introduces additional complexity into the validation process. The bottom line is that the revised path validation algorithm, as (ill-)defined, does not work the way many folks seem to believe. I fear folks have a vague notion about what the revised validation algorithm is, and they like the benefits it claims to offer, but they have not examined in detail exactly what the I-D says and what that means in practice. That's why I suggest that the new editors of the I-D need to revise it, address the ambiguities, and then the WG can decide whether the resulting document is worth pursuing. Happy turkey day, Steve --------------000209060609000206050400 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit None of those who believe that this draft is a good thing seem to have addressed
an issue I raised a while ago; the proposed solution is ill-defined and, the most
likely interpretation doesn't seem to work, in general. I'll try to explain this
reasoning, again, and provide an example.

Section 2 of the I-D says:

   Validation of signed resource data using a target resource

   certificate, and a specific set of number resources, consists of

   verifying that the digital signature of the signed resource data is

   valid, using the public key of the target resource certificate, and

   also validating the resource certificate in the context of the RPKI,
   using the path validation process.


 
Personally, I have trouble understanding what that 5 1/2 line sentence means,
in no small part because the phrase "signed resource data" is not defined
anywhere in the I-D. The text that follows reproduces, with one exception, the
path validation description from 6487, so I assume that the text is proposing
a change to that path validation process.
PowerPoint Presentation
The one change made to the path validation procedure in RFC 6487 arises
in step 6, which is reworded to be:

        The resource extension data contained in this certificate

        "encompasses" the entirety of the resources in the specific

        resource set ("encompass" in this context is defined in

        Section 7.1 of [RFC6487]).

PowerPoint Presentation

       

PowerPoint Presentation As I noted before, the phrase "specific resource set" is undefined in the I-D.
I'm guessing that many folks believe this term refers to any address space and ASN
extensions in the cert being validated. That's a simple, reasonable interpretation
of the text, and the authors have not stated a different intent, so let's proceed
on that assumption. Consider the following example that, WLOG, focuses only on
address space.

Consider a cert path from a trust anchor TA, to CA1 to CA2 to an EE cert for a ROA.

TA->CA 1->CA 2->ROA


Assume the TA cert contains address space T, U, V, W, X, Y and Z.

Assume the CA 1 cert contains address space T, U, V, and W.

Assume the CA 2 cert contains address space V and W.

Let's say that the ROA EE cert issued by CA 2 contains address space V.

CA 2 is about to receive address space Z from some other ISP, so it has asked
CA 1 to issue a new CA cert to it, in anticipation of the transfer. CA 1 agrees,
and issues a new cert to CA 2 and that cert contains address space V and Z.

Now, under the assumption about what "specific resource set" means, when
an RP tries to validate CA 2's ROA, the "specific resource set" will be V, and
so it will be valid, because V is in all of the certs from the TA through CA 1
to CA 2. Even though CA 2's cert contains Z, which is not contained
in CA 1's cert, this will not be considered in the validation of the ROA EE cert.
This is the desired outcome, because CA 2 has begun the process of getting its
new address space (Z), but that process has not broken its CA cert. I assume this
is an example of the reduced fragility that is so appealing.

If CA 2 issued a ROA for Z, then validation of that ROA would fail, because
the CA 1  cert does not contain Z. That's good, because the second ROA exmaple
ought not be valid, since the transfer has not yet completed.

So far, so good. But, let's look at the implications of this revised validation
procedure in greater depth.

What if CA 1, acting on the request from CA 2 asked the TA to add Z to CA 2's cert,
in anticipation of the transfer? Then we have a problem, because Z is under the
tree from this TA and if it agreed to add Z to CA 1's cert, then a ROA for Z,
issued by CA 2, would be valid, even though the transfer had not yet been effected.

So, when folks claim that this alg allows for transfers to not have to follow
a strict ordering of RPKI actions, that is only partly true. Issuing a new CA
cert with resources not yet transferred to the target can actually enable the
target to generate bogus ROAs that will validate, unless certain precautions
are taken. Every CA has to be sure that IF it issues a cert to a subordinate
because of an anticipated transfer, that this act does not enable the subordinate
(or a child of the subordinate ...) to issue bogus ROAs! Right now we have no
agreed-upon resource transfer process for the RPKI, to ensure that this sort of
vulnerability does not arise. Yet the suggestion is to change the validation
procedure before having such a process in place. Not such a good idea.

A bigger problem, IMHO, is that if an RP validates CA 2's (new) cert,
the "specific resource set" will be V and Z (according to the interpretation
cited above). However, using the revised step 6, validation will fail,
because CA 1's cert does not contain Z. To avoid this problem, RPs would have
to not validate CA certs that might contain address space that is not present
in all the certs along the path.
 
This is a bad outcome, for two reasons. An RP should validate each CA cert it
fetches, to minimize opportunities for DoS attacks.  An RP also should be able
to maintain a local cache where it need not walk the whole path to a TA every time
a new cert (of any type) appears. Note, for example, that new manifest certs
are issued daily. So, if one tries to take advantage of the reduced fragility
promised by this change to step 6, a CA cert with resources not present in all
if its parent certs will fal validation anyway. Not such a great outcome.

Also recall that new CRLs tend to be issued at least daily. To validate a CRL
an RP uses the public key from the CA cert under which the CRL was issued. That
implies the RP has validated the CA cert before using the public key from it.
Yet, as noted above, if the CA cert has address space not contained in all of its
parents, that cert will be invalid. So, RPs would have to treat CRL validation
as a special case, using a public key from a CA cert that has not been validated
relative to the revised process, to avoid this problem. Again, I see this as
not a great outcome, as it introduces additional complexity into the validation
process.

The bottom line is that the revised path validation algorithm, as (ill-)defined,
does not work the way many folks seem to believe. I fear folks have a vague notion
about what the revised validation algorithm is, and they like the benefits it
claims to offer, but they have not examined in detail exactly what the I-D says
and what that means in practice. That's why I suggest that the new editors of
the I-D need to revise it, address the ambiguities, and then the WG can decide
whether the resulting document is worth pursuing.

Happy turkey day,

Steve --------------000209060609000206050400-- From nobody Wed Nov 25 17:11:44 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385A01A8793 for ; Wed, 25 Nov 2015 17:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id je6PiwCi-mXW for ; Wed, 25 Nov 2015 17:11:42 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (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 EE4FE1A8791 for ; Wed, 25 Nov 2015 17:11:41 -0800 (PST) Received: by pacej9 with SMTP id ej9so72997272pac.2 for ; Wed, 25 Nov 2015 17:11:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0xB2ZSoD6GSD8dlEjFVvn+IBD+8ObWlQK2Qwbx6fwO8=; b=VsEqCq+ondgOvUd1Zjh+vkKxFVVeLX9dRyug8Rs1fniPPiV5R+VIIxKuBlVfkvKRLh EdFXUn17tN1OEU9KGoWke6UONhU6Sw2dFbcANZb7EcTrcq2TNHcNeAhM68ej0y0LCDeA 4Pl9YVE/JYmX+aNf0xUvPUgtE9ryuYbZ/D7Wm9+IBz23kIJ9+UcnaXTnEOeR/cN8nuKL Rnm8eHL2ubk4prSJkToxLZyNF0psoFf2IX/VdQCclUZg0a1m5PUM8Bh/Pz0rtzqzHmJ4 zzz2CVB4XPMg+67YVpxRju1LtiN8gRWg/2dDqsZDM3XZ/J6zpSXRRFGsEkP6juQiPKx/ P4Hg== X-Received: by 10.98.75.142 with SMTP id d14mr36063685pfj.91.1448500301540; Wed, 25 Nov 2015 17:11:41 -0800 (PST) Received: from ?IPv6:2001:388:1000:110:5da2:ca38:b8af:66c0? ([2001:388:1000:110:5da2:ca38:b8af:66c0]) by smtp.gmail.com with ESMTPSA id q70sm23250142pfa.12.2015.11.25.17.11.39 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 25 Nov 2015 17:11:40 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Geoff Huston In-Reply-To: <565617E8.4070005@bbn.com> Date: Thu, 26 Nov 2015 12:11:36 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <565617E8.4070005@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: sidr Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 01:11:43 -0000 Hi, I=E2=80=99m working through this example and I can=E2=80=99t help but = observe that its "ill-defined and, the most likely interpretation doesn't seem to work=E2=80= =9D to borrow your words=E2=80=A6. >=20 > Consider a cert path from a trust anchor TA, to CA1 to CA2 to an EE = cert for a ROA. >=20 > TA->CA 1->CA 2->ROA >=20 >=20 > Assume the TA cert contains address space T, U, V, W, X, Y and Z. >=20 > Assume the CA 1 cert contains address space T, U, V, and W. >=20 > Assume the CA 2 cert contains address space V and W. >=20 > Let's say that the ROA EE cert issued by CA 2 contains address space = V. >=20 > CA 2 is about to receive address space Z from some other ISP, so it = has asked=20 > CA 1 to issue a new CA cert to it, in anticipation of the transfer. CA = 1 agrees,=20 > and issues a new cert to CA 2 and that cert contains address space V = and Z. CA1 has already issued a cert with subject =E2=80=9CCA2=E2=80=9D and = resources (V,W) - lets call this cert No 1 Do you mean:=20 a) CA 1 issues a cert with subject =E2=80=9CCA2=E2=80=9D and resources = (V,Z) - lets call this cert No 2 OR the combination of actions: b) CA 1 issues a SECOND cert with subject =E2=80=9CCA2=E2=80=9D and = resources (V,Z) - lets call this Cert No 2 AND CA1 revokes the cert with subject =E2=80=9CCA2=E2=80=9D and = resources (V,W) (which we call Cert No 1) >=20 > Now, under the assumption about what "specific resource set" means, = when > an RP tries to validate CA 2's ROA, Now I=E2=80=99m confused - originally the ROA was signed by an EE cert = issued by CA 2=E2=80=99s Cert No 1 so when you refer to CA 2=E2=80=99s ROA do you mean the ROA that was = signed by an EE cert issued by CA 2=E2=80=99s Cert No 1, or do you mean a new ROA signed by an EE issued by CA 2=E2=80=99s Cert = No 2? > the "specific resource set" will be V, and > so it will be valid, because V is in all of the certs from the TA = through CA 1 > to CA 2. Even though CA 2's cert contains Z, which is not contained > in CA 1's cert, this will not be considered in the validation of the = ROA EE cert. > This is the desired outcome, because CA 2 has begun the process of = getting its=20 > new address space (Z), but that process has not broken its CA cert. I = assume this > is an example of the reduced fragility that is so appealing.=20 So I _think_ you are assuming that there is a new ROA, signed by an EE = cert issued by=20 the CA that has a CA cert issued by CA 1 with resources (V,Z), and = evidently you are referring to this new ROA and its new EE cert. >=20 > If CA 2 issued a ROA for Z, then validation of that ROA would fail, = because=20 > the CA 1 cert does not contain Z. That's good, because the second ROA = exmaple > ought not be valid, since the transfer has not yet completed.=20 >=20 > So far, so good. But, let's look at the implications of this revised = validation=20 > procedure in greater depth. >=20 > What if CA 1, acting on the request from CA 2 asked the TA to add Z to = CA 2's cert, Huh????? The TA has issued a cert for subject =E2=80=9CCA 1=E2=80=9D - Since when = did Ca2 have a relationship with the TA? > =20 > in anticipation of the transfer? Then we have a problem, because Z is = under the=20 > tree from this TA and if it agreed to add Z to CA 1's cert, then a ROA = for Z,=20 > issued by CA 2, would be valid, even though the transfer had not yet = been effected. I=E2=80=99m having trouble following this - I think you have a typo of = otherwise confused the example at this point. I=E2=80=99ll stop here because I can=E2=80=99t see the point of the = ensuring text without some additional clarity and precision of the example scenario that does not invent = arbitrary relationships between CAs. regards, Geoff From nobody Thu Nov 26 04:30:27 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127031A1A88 for ; Thu, 26 Nov 2015 04:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QAFgIjEHNwL for ; Thu, 26 Nov 2015 04:30:24 -0800 (PST) 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 293B61A1A7D for ; Thu, 26 Nov 2015 04:30:24 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1a1vgq-000AlX-3h; Thu, 26 Nov 2015 13:30:21 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-67.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1a1vgp-0004BT-MJ; Thu, 26 Nov 2015 13:30:19 +0100 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: <565617E8.4070005@bbn.com> Date: Thu, 26 Nov 2015 13:29:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8FB9C3A7-0799-4CF7-80A5-7669070B3C91@ripe.net> References: <565617E8.4070005@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.2104) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07194c4a008b2764e57c74f9c6265b73f53c Archived-At: Cc: sidr Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 12:30:26 -0000 Hi, > On 25 Nov 2015, at 21:19, Stephen Kent wrote: >=20 > None of those who believe that this draft is a good thing seem to have = addressed > an issue I raised a while ago; the proposed solution is ill-defined = and, the most > likely interpretation doesn't seem to work, in general. I'll try to = explain this > reasoning, again, and provide an example. I believe the draft is being precise, but in the process has become = difficult to parse. Let me attempt once more to explain the proposal in = a different way: "When doing top-down validation of resource certificates in the RPKI we = propose that rather than rejecting a certificate that has resources not = held by the parent (but is valid on all other respects), we would accept = the certificate but keep note of the actual resources we believe it can = be authoritative for. I.e. the intersection of resources on this = certificate and the resources accepted for the parent. The RP SHOULD = however issue a warning in case certain resources are excluded because = of this, so that the responsible CA can fix the situation. Please note that for ROAs there is a requirement that all ROA prefixes = are included on the EE certificate of the (ROA) signed object CMS. This = proposal does not change this. A ROA that has prefixes that were removed = for whatever reason higher in the path would still become invalid using = this algorithm. We would therefore RECOMMEND that CAs issue 1 ROA for = each prefix, and avoid fate sharing. That way only ROAs for prefixes = that were removed will be affected." Essentially that really is all there is to it. If this is easier to = parse, and the co-chairs conclude that work should continue, then I am = happy to use this line of explanation in a next version of the document. = And no, I have no doubt that it will need more detail than above in an = I-D - but it's the basic principle that I am trying to convey here. Tim= From nobody Thu Nov 26 05:34:02 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4EA91A1AA6 for ; Thu, 26 Nov 2015 05:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.748 X-Spam-Level: * X-Spam-Status: No, score=1.748 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSR4M6YJl66l for ; Thu, 26 Nov 2015 05:33:58 -0800 (PST) Received: from mail.zdns.cn (smtp.knet.cn [202.173.10.15]) by ietfa.amsl.com (Postfix) with SMTP id 49D611A1A4A for ; Thu, 26 Nov 2015 05:33:57 -0800 (PST) X-TM-DID: 3a74911341fc26777be0861c054f199d Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Declan Ma In-Reply-To: <8FB9C3A7-0799-4CF7-80A5-7669070B3C91@ripe.net> Date: Thu, 26 Nov 2015 21:33:36 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <224A4F35-89AD-4CE2-B752-0DAA21508C5B@zdns.cn> References: <565617E8.4070005@bbn.com> <8FB9C3A7-0799-4CF7-80A5-7669070B3C91@ripe.net> To: Tim Bruijnzeels X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: sidr Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 13:34:00 -0000 Tim, Thanks for your explanations. Yet since the very draft keeps talking about Resource Transfer and deems = it as one of the =A1=B0Operational Considerations=A1=B1 in Section 3, = we might pay attention to Steve=A1=AFs statement as below:=20 So, when folks claim that this alg allows for transfers to not have to = follow=20 a strict ordering of RPKI actions, that is only partly true. Issuing a = new CA cert with resources not yet transferred to the target can actually = enable the target to generate bogus ROAs that will validate, unless certain = precautions are taken. Every CA has to be sure that IF it issues a cert to a = subordinate=20 because of an anticipated transfer, that this act does not enable the = subordinate (or a child of the subordinate ...) to issue bogus ROAs! Right now we = have no=20 agreed-upon resource transfer process for the RPKI, to ensure that this = sort of vulnerability does not arise. Yet the suggestion is to change the = validation=20 procedure before having such a process in place. Not such a good idea. As Randy=A1=AFs draft relating to Resource Transfer is still in = progress, it would be not wise to seek solutions to the so-called = fragility in validating certificates when we have no agreed-upon = resource transfer process for the RPKI.=20 Di > =D4=DA 2015=C4=EA11=D4=C226=C8=D5=A3=AC20:29=A3=ACTim Bruijnzeels = =D0=B4=B5=C0=A3=BA >=20 > Hi, >=20 >> On 25 Nov 2015, at 21:19, Stephen Kent wrote: >>=20 >> None of those who believe that this draft is a good thing seem to = have addressed >> an issue I raised a while ago; the proposed solution is ill-defined = and, the most >> likely interpretation doesn't seem to work, in general. I'll try to = explain this >> reasoning, again, and provide an example. >=20 > I believe the draft is being precise, but in the process has become = difficult to parse. Let me attempt once more to explain the proposal in = a different way: >=20 > "When doing top-down validation of resource certificates in the RPKI = we propose that rather than rejecting a certificate that has resources = not held by the parent (but is valid on all other respects), we would = accept the certificate but keep note of the actual resources we believe = it can be authoritative for. I.e. the intersection of resources on this = certificate and the resources accepted for the parent. The RP SHOULD = however issue a warning in case certain resources are excluded because = of this, so that the responsible CA can fix the situation. >=20 > Please note that for ROAs there is a requirement that all ROA prefixes = are included on the EE certificate of the (ROA) signed object CMS. This = proposal does not change this. A ROA that has prefixes that were removed = for whatever reason higher in the path would still become invalid using = this algorithm. We would therefore RECOMMEND that CAs issue 1 ROA for = each prefix, and avoid fate sharing. That way only ROAs for prefixes = that were removed will be affected." >=20 > Essentially that really is all there is to it. If this is easier to = parse, and the co-chairs conclude that work should continue, then I am = happy to use this line of explanation in a next version of the document. = And no, I have no doubt that it will need more detail than above in an = I-D - but it's the basic principle that I am trying to convey here. >=20 >=20 > Tim > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Nov 26 11:36:50 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D36B1B2D55 for ; Thu, 26 Nov 2015 11:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbC9Ifl-YbuN for ; Thu, 26 Nov 2015 11:36:47 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (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 E8FEC1B2D54 for ; Thu, 26 Nov 2015 11:36:46 -0800 (PST) Received: by padhx2 with SMTP id hx2so93219002pad.1 for ; Thu, 26 Nov 2015 11:36:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WLwbsOdZ3EZyup8CjE/IbIRaqAjc9M8HboCJrFGzZjs=; b=nZD7xGkv0WPs+fvFHuzPVHNArbUw0qP7W02bJuxvLfONjz1Edod2IoCqk72/g4J7CN gDRK8Dmwn/BFtvPLebenRot2e9IuLp2uN397lUHbebUqSwqypChyY/+kO3JKWI2llIyq 1Mjl4CcsNg4Is/Co6pEG3CAHqSllIGxNgP2kT5K0xvvO1lOXhR/QBz/CaXu5lOdTHO/4 JGZArvRL71QeHiOrwMXGHnczvcUikX5r8jlPDz4bk2VJs2kY217To4cnXcbvpFK7kIdk 6plmTkBg82+JeaBYOuuwUf5YnkAcqhnzHaok7Jib9fTRHQZSCAqykItxLvOiJLotVD// k/RQ== X-Received: by 10.98.42.209 with SMTP id q200mr42151671pfq.1.1448566606430; Thu, 26 Nov 2015 11:36:46 -0800 (PST) Received: from 2001-44b8-1121-1a00-552a-b1de-f3e9-0d24.static.ipv6.internode.on.net (2001-44b8-1121-1a00-552a-b1de-f3e9-0d24.static.ipv6.internode.on.net. [2001:44b8:1121:1a00:552a:b1de:f3e9:d24]) by smtp.gmail.com with ESMTPSA id by6sm29780460pab.25.2015.11.26.11.36.44 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 26 Nov 2015 11:36:45 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Geoff Huston In-Reply-To: <224A4F35-89AD-4CE2-B752-0DAA21508C5B@zdns.cn> Date: Fri, 27 Nov 2015 06:36:40 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <762B8B1A-3FE0-459B-B887-F5CBE639D3BE@gmail.com> References: <565617E8.4070005@bbn.com> <8FB9C3A7-0799-4CF7-80A5-7669070B3C91@ripe.net> <224A4F35-89AD-4CE2-B752-0DAA21508C5B@zdns.cn> To: Declan Ma X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: sidr Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 19:36:48 -0000 Declan, I=E2=80=99d pay more attention to this statement you are quoting if and = only if the justification for this statement made any sense. As far as I can tell = the example used to build to this point is confused and imprecise, so its a leap of faith that I=E2=80=99m not perform to then hold the conclusions = as valid. I find it equally challenging to then reach the conclusion that you = appear to be providing that that somehow all this is dependant on a draft relating to = certificate mediated resource transfer. Again I see what appears to be another leap = of faith=20 going on here. Geoff > On 27 Nov 2015, at 12:33 AM, Declan Ma wrote: >=20 > Tim, >=20 > Thanks for your explanations. >=20 > Yet since the very draft keeps talking about Resource Transfer and = deems it as one of the =E2=80=9COperational Considerations=E2=80=9D in = Section 3, we might pay attention to Steve=E2=80=99s statement as below:=20= >=20 >=20 > So, when folks claim that this alg allows for transfers to not have to = follow=20 > a strict ordering of RPKI actions, that is only partly true. Issuing a = new CA > cert with resources not yet transferred to the target can actually = enable the > target to generate bogus ROAs that will validate, unless certain = precautions > are taken. Every CA has to be sure that IF it issues a cert to a = subordinate=20 > because of an anticipated transfer, that this act does not enable the = subordinate > (or a child of the subordinate ...) to issue bogus ROAs! Right now we = have no=20 > agreed-upon resource transfer process for the RPKI, to ensure that = this sort of > vulnerability does not arise. Yet the suggestion is to change the = validation=20 > procedure before having such a process in place. Not such a good idea. >=20 >=20 > As Randy=E2=80=99s draft relating to Resource Transfer is still in = progress, it would be not wise to seek solutions to the so-called = fragility in validating certificates when we have no agreed-upon = resource transfer process for the RPKI.=20 >=20 >=20 > Di >=20 >=20 >> =E5=9C=A8 2015=E5=B9=B411=E6=9C=8826=E6=97=A5=EF=BC=8C20:29=EF=BC=8CTim= Bruijnzeels =E5=86=99=E9=81=93=EF=BC=9A >>=20 >> Hi, >>=20 >>> On 25 Nov 2015, at 21:19, Stephen Kent wrote: >>>=20 >>> None of those who believe that this draft is a good thing seem to = have addressed >>> an issue I raised a while ago; the proposed solution is ill-defined = and, the most >>> likely interpretation doesn't seem to work, in general. I'll try to = explain this >>> reasoning, again, and provide an example. >>=20 >> I believe the draft is being precise, but in the process has become = difficult to parse. Let me attempt once more to explain the proposal in = a different way: >>=20 >> "When doing top-down validation of resource certificates in the RPKI = we propose that rather than rejecting a certificate that has resources = not held by the parent (but is valid on all other respects), we would = accept the certificate but keep note of the actual resources we believe = it can be authoritative for. I.e. the intersection of resources on this = certificate and the resources accepted for the parent. The RP SHOULD = however issue a warning in case certain resources are excluded because = of this, so that the responsible CA can fix the situation. >>=20 >> Please note that for ROAs there is a requirement that all ROA = prefixes are included on the EE certificate of the (ROA) signed object = CMS. This proposal does not change this. A ROA that has prefixes that = were removed for whatever reason higher in the path would still become = invalid using this algorithm. We would therefore RECOMMEND that CAs = issue 1 ROA for each prefix, and avoid fate sharing. That way only ROAs = for prefixes that were removed will be affected." >>=20 >> Essentially that really is all there is to it. If this is easier to = parse, and the co-chairs conclude that work should continue, then I am = happy to use this line of explanation in a next version of the document. = And no, I have no doubt that it will need more detail than above in an = I-D - but it's the basic principle that I am trying to convey here. >>=20 >>=20 >> Tim >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Fri Nov 27 07:40:04 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DF01B354A for ; Fri, 27 Nov 2015 07:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.215 X-Spam-Level: X-Spam-Status: No, score=0.215 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u618iz2apAFi for ; Fri, 27 Nov 2015 07:40:02 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA3A21B325F for ; Fri, 27 Nov 2015 07:40:01 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1a2L7q-00017l-Qy; Fri, 27 Nov 2015 15:39:55 +0000 Date: Fri, 27 Nov 2015 07:39:54 -0800 Message-ID: From: Randy Bush To: Geoff Huston In-Reply-To: <762B8B1A-3FE0-459B-B887-F5CBE639D3BE@gmail.com> References: <565617E8.4070005@bbn.com> <8FB9C3A7-0799-4CF7-80A5-7669070B3C91@ripe.net> <224A4F35-89AD-4CE2-B752-0DAA21508C5B@zdns.cn> <762B8B1A-3FE0-459B-B887-F5CBE639D3BE@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 15:40:03 -0000 > I find it equally challenging to then reach the conclusion that you > appear to be providing that that somehow all this is dependant on a > draft relating to certificate mediated resource transfer. Again I see > what appears to be another leap of faith going on here. well, not that i makes a lot of difference, but my memory is somewhat otherwise. i thought we kind of agreed that we needed to better understand transfer before we know the constraints and features needed both in validation reconsidered and the stuff steve is pushing. but my memory is not all that i might desire. randy From nobody Fri Nov 27 15:53:06 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D9A1A8A1C for ; Fri, 27 Nov 2015 15:53:05 -0800 (PST) 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oj7r5eqA7WWy for ; Fri, 27 Nov 2015 15:52:57 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0728.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::728]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B112C1A89C4 for ; Fri, 27 Nov 2015 15:52:56 -0800 (PST) Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by CY1PR09MB0796.namprd09.prod.outlook.com (10.163.43.146) with Microsoft SMTP Server (TLS) id 15.1.331.20; Fri, 27 Nov 2015 23:52:39 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0331.023; Fri, 27 Nov 2015 23:52:39 +0000 From: "Sriram, Kotikalapudi" To: Tim Bruijnzeels , Stephen Kent , "gih902@gmail.com" Thread-Topic: [sidr] Validation Reconsidered (again/again) question Thread-Index: AQHRJ76kclsFhw+pBUOxgfRVH01CoJ6uPM2AgAJQQiA= Date: Fri, 27 Nov 2015 23:52:38 +0000 Message-ID: References: <565617E8.4070005@bbn.com>, <8FB9C3A7-0799-4CF7-80A5-7669070B3C91@ripe.net> In-Reply-To: <8FB9C3A7-0799-4CF7-80A5-7669070B3C91@ripe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.219.196] x-microsoft-exchange-diagnostics: 1; CY1PR09MB0796; 5:dIG3oH74CF+zoksFFsrj9xl4zntJkOwZLkAVyRGEoBPpJxGl21Wgq6l85SeHKEh3C2wO3iNr3TbXjfB4wotHb23pf7J2dkxzxNt0H45sJ3jhC9Ls5Bc9gI3YLOnYyyb4xEjplI1xII8tyWAN6pgfvQ==; 24:ENO+B7BeTbSaP0doB8YGyxtNh67BCqZPA8y8KrLNQnq10n9ELQOPNnDeqERhMMfARR7dpPVfzmKRuIVo5FEZeFqJgXxKXvPemXRk60S0dGc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0796; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:CY1PR09MB0796; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0796; x-forefront-prvs: 0773BB46AC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(189002)(199003)(66066001)(2900100001)(76176999)(81156007)(11100500001)(40100003)(50986999)(87936001)(122556002)(5001960100002)(5002640100001)(2501003)(54356999)(3846002)(19580395003)(74316001)(586003)(6116002)(102836003)(1096002)(19580405001)(15975445007)(86362001)(33656002)(5003600100002)(2950100001)(5008740100001)(97736004)(5001770100001)(10400500002)(561944003)(99286002)(92566002)(105586002)(76576001)(106356001)(101416001)(77096005)(106116001)(189998001)(5004730100002)(1220700001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0796; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 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: 27 Nov 2015 23:52:38.8810 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0796 Archived-At: Cc: sidr Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 23:53:05 -0000 Tim, Your explanation does lay it out more clearly, and it is consistent with ho= w I understood it before. However, I have two questions/suggestions: 1. A question/suggestion about the new validation algorithm: Consider the following cert-chain, ROA example: TA: {5.0.0.0/8, 8.0.0.0/12, AS1-AS100} CA1: {5.0.0.0/20, 8.0.0.0/18, AS1-AS400} CA2: {5.0.0.0/24, 8.0.0.0/20, AS1-AS50} <-- note the "narrowing" of sub-c= one in the 5.0.0.0/x space=20 CA3: {5.0.0.0/22, 8.0.0.0/22, AS1-AS500} <-- note the "widening" of sub-co= ne in the 5.0.0.0/x space=20 CA4: {5.0.0.0/24, 8.0.0.0/24, AS1-AS5} (Hint: picture specific-resource sub-cones within the broader cone of varie= d resources) The EE certs are: EE1: {5.0.0.0/24} generated from CA4 EE2: {8.0.0.0/24} generated from CA4 And the ROAs are: ROA1: {5.0.0.0/24, AS1000} (signed with EE1)=20 ROA2: {8.0.0.0/24, AS2000} (signed with EE2) I think your proposed validation algorithm would determine that EE1, EE2, ROA1 and ROA2 are all valid. However, if you require that the specific resource (e.g. 5.0.0.0/24) -- tha= t is relevant to the ROA or the EE cert being validated -- MUST have a =93non-narrowing s= ub-cone=94=20 in the cert chain resources, then EE2 and RAO2 will be still valid,=20 but EE1 and ROA1 will be invalid.=20 By =93non-narrowing sub-cone=94 (for a specific resource/prefix), I mean th= e following:=20 As we move up the cert-chain, the =93relevant=94 or =93corresponding=94=20 prefixes (relative to the specific prefix in consideration) seen at each le= vel=20 in the hierarchy of certs must be such that the same prefix or a less speci= fic=20 is found at each level relative to the level directly below. As you can see in the example, non-narrowing sub-cone is true for 8.0.0.0/2= 4 (EE2), but not for 5.0.0.0/24 (EE1). Hence, EE1 and ROA1 are invalid (under this e= nhancement). Do you think there merit in this approach over what you have now in validat= ion reconsidered?=20 This somewhat less lenient approach would seem a bit more sensible (at leas= t in my mind). 2. How do you perform the validation of a CRL? How is it similar to or different from how you validate a ROA? How do you walk the certificate hierarchy in the case of a CRL validation p= rocess? I.e. How are the "encompassing" rules applied? I think this should be explicitly explained/clarified in the document. Sriram =20 ________________________________________ From: sidr on behalf of Tim Bruijnzeels Sent: Thursday, November 26, 2015 7:29 AM To: Stephen Kent Cc: sidr Subject: Re: [sidr] Validation Reconsidered (again/again) question Hi, > On 25 Nov 2015, at 21:19, Stephen Kent wrote: > > None of those who believe that this draft is a good thing seem to have ad= dressed > an issue I raised a while ago; the proposed solution is ill-defined and, = the most > likely interpretation doesn't seem to work, in general. I'll try to expla= in this > reasoning, again, and provide an example. I believe the draft is being precise, but in the process has become difficu= lt to parse. Let me attempt once more to explain the proposal in a differen= t way: "When doing top-down validation of resource certificates in the RPKI we pro= pose that rather than rejecting a certificate that has resources not held b= y the parent (but is valid on all other respects), we would accept the cert= ificate but keep note of the actual resources we believe it can be authorit= ative for. I.e. the intersection of resources on this certificate and the r= esources accepted for the parent. The RP SHOULD however issue a warning in = case certain resources are excluded because of this, so that the responsibl= e CA can fix the situation. Please note that for ROAs there is a requirement that all ROA prefixes are = included on the EE certificate of the (ROA) signed object CMS. This proposa= l does not change this. A ROA that has prefixes that were removed for whate= ver reason higher in the path would still become invalid using this algorit= hm. We would therefore RECOMMEND that CAs issue 1 ROA for each prefix, and = avoid fate sharing. That way only ROAs for prefixes that were removed will = be affected." Essentially that really is all there is to it. If this is easier to parse, = and the co-chairs conclude that work should continue, then I am happy to us= e this line of explanation in a next version of the document. And no, I hav= e no doubt that it will need more detail than above in an I-D - but it's th= e basic principle that I am trying to convey here. Tim _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From nobody Fri Nov 27 16:09:12 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED661A9045; Fri, 27 Nov 2015 16:09:10 -0800 (PST) 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goilKkdxBtEK; Fri, 27 Nov 2015 16:09:06 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0703.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:703]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B66D91A9042; Fri, 27 Nov 2015 16:09:05 -0800 (PST) Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by CY1PR09MB0794.namprd09.prod.outlook.com (10.163.43.144) with Microsoft SMTP Server (TLS) id 15.1.331.20; Sat, 28 Nov 2015 00:08:38 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0331.023; Sat, 28 Nov 2015 00:08:38 +0000 From: "Sriram, Kotikalapudi" To: Christopher Morrow , "sidr@ietf.org" , "sidr-ads@tools.ietf.org" , "sidr-chairs@ietf.org" Thread-Topic: [sidr] Validation Reconsidered (again/again) question Thread-Index: AQHRGDXHclsFhw+pBUOxgfRVH01CoJ6wrngH Date: Sat, 28 Nov 2015 00:08:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.219.196] x-microsoft-exchange-diagnostics: 1; CY1PR09MB0794; 5:JF24rQcioBWN/GRot3V5IPakFt2DdaQULoarUnFvNMsnqusVyngJiMNWDABtJVY58dtE1xGN9wjMEKsfNXtkMFT+d7jNlyLB/W1KnwrGaMIv6YKDR+NcPLnQEjtP/aWFZKvxzhkPw3Bzoe/poMMaKg==; 24:vvpweVXkQ/hiTrwtpdylQ1TwhqFnDqXAJEmuTGpwJl+8bzKwybczeQxGHgF41Q0xbEdlkBdszMa3zZRlAQ7eNDPTfdmNzKMNE09+SlPVUQU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0794; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:CY1PR09MB0794; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0794; x-forefront-prvs: 07749F8C42 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(377454003)(189002)(479174004)(101416001)(189998001)(40100003)(2501003)(10400500002)(5008740100001)(15975445007)(54356999)(2900100001)(87936001)(2950100001)(76176999)(586003)(86362001)(2201001)(66066001)(97736004)(81156007)(102836003)(3846002)(6116002)(77096005)(1220700001)(122556002)(33656002)(105586002)(5001960100002)(5002640100001)(76576001)(5003600100002)(92566002)(74316001)(5001770100001)(106356001)(107886002)(99286002)(1096002)(5004730100002)(106116001)(19580405001)(19580395003)(11100500001)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0794; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2015 00:08:38.1479 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0794 Archived-At: Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 00:09:10 -0000 I think the discussion on the work should continue. New questions are being raised and the authors should address them in a rev= ised draft going forward. I also had a couple of new questions/suggestions (hopefully new!) about the= method. I have mentioned them in my other post replying to Tim's post. Sriram=20 ________________________________________ From: sidr on behalf of Christopher Morrow Sent: Thursday, November 5, 2015 8:52 PM To: sidr@ietf.org; sidr-ads@tools.ietf.org; sidr-chairs@ietf.org Subject: [sidr] Validation Reconsidered (again/again) question Please take 2 weeks time to consider: "This document was adopted as a WG work item, should we accept this change and complete the work or not?" where: 'this document' is: I'll close the mic line on: 11/20/2015 Nov 20, 2015 -Chris sidr-co-chair _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From nobody Sun Nov 29 11:37:42 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F291B329D for ; Sun, 29 Nov 2015 11:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQqIBbknqvPV for ; Sun, 29 Nov 2015 11:37:38 -0800 (PST) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (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 E265D1B329A for ; Sun, 29 Nov 2015 11:37:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=R2D2; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=6N+o6amu2UL5KpqCZmeCrhy15qkxMvmV5ce8AzNulHM=; b=QLZ+CY4bZa4ugcS83v//WWpq1r7GOJnl6dVJ6xW0e9Rm+brY245lbTQSluRaQaqLJyfhJpuIecgND cImOJV3d8Su7XnGH6VwE1bRbHy5GsjN318r9duOXY0f82krdYBDqYN1Y82DlHxAr8jcaqCazXypzyg KuRhmCSwyP93wjlU= Received: from NXMDA2.org.apnic.net (unknown [IPv6:2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS; Mon, 30 Nov 2015 05:39:29 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 30 Nov 2015 05:37:26 +1000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Geoff Huston In-Reply-To: Date: Mon, 30 Nov 2015 06:37:26 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <565617E8.4070005@bbn.com> <8FB9C3A7-0799-4CF7-80A5-7669070B3C91@ripe.net> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: sidr Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 19:37:41 -0000 Hi Sriram, > On 28 Nov 2015, at 10:52 AM, Sriram, Kotikalapudi = wrote: >=20 > Tim, >=20 > Your explanation does lay it out more clearly, and it is consistent = with how I understood it before. > However, I have two questions/suggestions: >=20 > 1. A question/suggestion about the new validation algorithm: >=20 > Consider the following cert-chain, ROA example: >=20 > TA: {5.0.0.0/8, 8.0.0.0/12, AS1-AS100} > CA1: {5.0.0.0/20, 8.0.0.0/18, AS1-AS400} > CA2: {5.0.0.0/24, 8.0.0.0/20, AS1-AS50} <-- note the "narrowing" of = sub-cone in the 5.0.0.0/x space=20 > CA3: {5.0.0.0/22, 8.0.0.0/22, AS1-AS500} <-- note the "widening" of = sub-cone in the 5.0.0.0/x space=20 > CA4: {5.0.0.0/24, 8.0.0.0/24, AS1-AS5} >=20 > (Hint: picture specific-resource sub-cones within the broader cone of = varied resources) >=20 > The EE certs are: > EE1: {5.0.0.0/24} generated from CA4 > EE2: {8.0.0.0/24} generated from CA4 >=20 > And the ROAs are: > ROA1: {5.0.0.0/24, AS1000} (signed with EE1)=20 > ROA2: {8.0.0.0/24, AS2000} (signed with EE2) >=20 > I think your proposed validation algorithm would determine that > EE1, EE2, ROA1 and ROA2 are all valid. yes in both cases > However, if you require that the specific resource (e.g. 5.0.0.0/24) = -- that is relevant > to the ROA or the EE cert being validated -- MUST have a = =93non-narrowing sub-cone=94=20 > in the cert chain resources, then EE2 and RAO2 will be still valid,=20 > but EE1 and ROA1 will be invalid.=20 > By =93non-narrowing sub-cone=94 (for a specific resource/prefix), I = mean the following:=20 > As we move up the cert-chain, the =93relevant=94 or =93corresponding=94=20= > prefixes (relative to the specific prefix in consideration) seen at = each level=20 > in the hierarchy of certs must be such that the same prefix or a less = specific=20 > is found at each level relative to the level directly below. > As you can see in the example, non-narrowing sub-cone is true for = 8.0.0.0/24 (EE2), > but not for 5.0.0.0/24 (EE1). Hence, EE1 and ROA1 are invalid (under = this enhancement). > Do you think there merit in this approach over what you have now in = validation reconsidered?=20 > This somewhat less lenient approach would seem a bit more sensible (at = least in my mind). qualitative judgment: no, not in my view >=20 > 2. How do you perform the validation of a CRL? RFC6487 provided no guidance, and referred to RFC5280, so that is still = the case. nothing changes herre. > How is it similar to or different from how you validate a ROA? There are no resources in a CRL so I presume that section 6.1 of RFC5280 = is a good procedure to follow. > How do you walk the certificate hierarchy in the case of a CRL = validation process? > I.e. How are the "encompassing" rules applied? huh - I=92ll say it again just to be sure: CRLs have no resources. > I think this should be explicitly explained/clarified in the document. I disagree. Geoff >=20 > Sriram =20 >=20 > ________________________________________ > From: sidr on behalf of Tim Bruijnzeels = > Sent: Thursday, November 26, 2015 7:29 AM > To: Stephen Kent > Cc: sidr > Subject: Re: [sidr] Validation Reconsidered (again/again) question >=20 > Hi, >=20 >> On 25 Nov 2015, at 21:19, Stephen Kent wrote: >>=20 >> None of those who believe that this draft is a good thing seem to = have addressed >> an issue I raised a while ago; the proposed solution is ill-defined = and, the most >> likely interpretation doesn't seem to work, in general. I'll try to = explain this >> reasoning, again, and provide an example. >=20 > I believe the draft is being precise, but in the process has become = difficult to parse. Let me attempt once more to explain the proposal in = a different way: >=20 > "When doing top-down validation of resource certificates in the RPKI = we propose that rather than rejecting a certificate that has resources = not held by the parent (but is valid on all other respects), we would = accept the certificate but keep note of the actual resources we believe = it can be authoritative for. I.e. the intersection of resources on this = certificate and the resources accepted for the parent. The RP SHOULD = however issue a warning in case certain resources are excluded because = of this, so that the responsible CA can fix the situation. >=20 > Please note that for ROAs there is a requirement that all ROA prefixes = are included on the EE certificate of the (ROA) signed object CMS. This = proposal does not change this. A ROA that has prefixes that were removed = for whatever reason higher in the path would still become invalid using = this algorithm. We would therefore RECOMMEND that CAs issue 1 ROA for = each prefix, and avoid fate sharing. That way only ROAs for prefixes = that were removed will be affected." >=20 > Essentially that really is all there is to it. If this is easier to = parse, and the co-chairs conclude that work should continue, then I am = happy to use this line of explanation in a next version of the document. = And no, I have no doubt that it will need more detail than above in an = I-D - but it's the basic principle that I am trying to convey here. >=20 >=20 > Tim > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Sun Nov 29 12:38:29 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7910D1B33FB for ; Sun, 29 Nov 2015 12:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBr13H-sLPcl for ; Sun, 29 Nov 2015 12:38:27 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C9131B3401 for ; Sun, 29 Nov 2015 12:38:19 -0800 (PST) Received: by ykfs79 with SMTP id s79so164629360ykf.1 for ; Sun, 29 Nov 2015 12:38:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=Eub8fFQ1NQSC1Huk9kbpYwpMPjWO/5ZrJCs0vdp1jL4=; b=HtLzvhbaH9IY6DFf0J/yU2fiZWyZt9ryt8PYZhNDO+sXrLD7IIezPm6p6As6/5tjmv 0YAXV8SB26TbTdSzrsxPSovfXdLAgI0CI2PKgr0cZHzPCbxA2vh1PFu6HsOkoO+Mx8pI PND+BrURFJJwe7d3VW+/MgGPH7EbmkrkPYSD282Gtue8YBk28YWoCQGF0GGlTYkEVjqb +/AMiMkqqjkxendEeWfVlU+WJv2K60zIwcksSMqHk0KFExUZCSRmjo6WPcY3MKx0RCuN 5ol+Fntlda9CezRQitCTXZ8skkUulgYXI7tINI/PwRV31lK8+vsdzyyu086pQWWRNVY1 v9sA== MIME-Version: 1.0 X-Received: by 10.13.212.203 with SMTP id w194mr6233194ywd.180.1448829498374; Sun, 29 Nov 2015 12:38:18 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.129.99.9 with HTTP; Sun, 29 Nov 2015 12:38:18 -0800 (PST) In-Reply-To: References: <563D1D0B.9030002@bbn.com> <564F4B86.4030104@bbn.com> Date: Sun, 29 Nov 2015 15:38:18 -0500 X-Google-Sender-Auth: mdDvrLoppRmiC1R3fjJQI_D9VYE Message-ID: From: Christopher Morrow To: sidr wg list Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 20:38:28 -0000 On Tue, Nov 24, 2015 at 11:22 AM, Christopher Morrow wrote: > On Mon, Nov 23, 2015 at 5:13 PM, Christopher Morrow > wrote: >> Pinging this thread to catch anyone who didn't reply but had thoughts >> I'd like to close this out tomorrow before 5pm EST (10pm UTC). >> > > Damn my lack of date specificity!! > To be clear, I'd like to make the call on this: > 2015-11-25 10pm UTC > (November 25 2015 10pm UTC) > Ok, with a few extra days to let some more chatter progress, I think the overall bent here is: "Please do more work on this." With that in mind, I'd like the authors not gih@ to ping me and i'll provide a pointer to the current xml, then I hope we can get moving along with this in the coming quarters. Thanks to those folk that replied to the question(s). -chris From nobody Sun Nov 29 13:58:11 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C509F1B3588 for ; Sun, 29 Nov 2015 13:58:10 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-upi9EA1Kbg for ; Sun, 29 Nov 2015 13:58:08 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0102.outbound.protection.outlook.com [65.55.169.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 4A8951B3584 for ; Sun, 29 Nov 2015 13:58:06 -0800 (PST) Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) with Microsoft SMTP Server (TLS) id 15.1.331.20; Sun, 29 Nov 2015 21:58:03 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0331.023; Sun, 29 Nov 2015 21:58:03 +0000 From: "Sriram, Kotikalapudi" To: Geoff Huston Thread-Topic: [sidr] Validation Reconsidered (again/again) question Thread-Index: AQHRJ76kclsFhw+pBUOxgfRVH01CoJ6uPM2AgAJQQiCAAt40AIAAEmYh Date: Sun, 29 Nov 2015 21:58:02 +0000 Message-ID: References: <565617E8.4070005@bbn.com> <8FB9C3A7-0799-4CF7-80A5-7669070B3C91@ripe.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.219.248] x-microsoft-exchange-diagnostics: 1; CY1PR09MB0793; 5:g/lLtCbis0nHGxqYQyc91T6YyqucihflBsiNMZw8Ibp2nL7wUKpYeD9wl/cr/PdX+wRiEE6SgAEZSCSmQdEUkHsn8ZIbg6z3Qk1Rkkm8Meo6rDJrUb38OvAlGn0XmojLO5rvv1ai4+pl03GR4nZV4A==; 24:7IJZ+GBK8xj2A8aylEwX5d6FfynmBaiv0pX8sRa5h12W6sBb7U0J1qIwbsOBzMlLwi24VRF9l/sahdyUlJBRpEiGIP8i4HW9X49/P5MH+MU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0793; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(10201501046)(3002001); SRVR:CY1PR09MB0793; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0793; x-forefront-prvs: 0775716B9D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(2950100001)(97736004)(2900100001)(74316001)(86362001)(92566002)(5002640100001)(15975445007)(19580395003)(5003600100002)(81156007)(586003)(101416001)(33656002)(189998001)(122556002)(87936001)(5001960100002)(110136002)(66066001)(106356001)(54356999)(1096002)(99286002)(105586002)(77096005)(76176999)(40100003)(93886004)(106116001)(5008740100001)(6116002)(102836003)(76576001)(5004730100002)(11100500001)(3846002)(1220700001)(50986999)(10400500002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0793; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 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: 29 Nov 2015 21:58:02.8150 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0793 Archived-At: Cc: sidr Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 21:58:10 -0000 Geoff, Thanks for your responses. Please see below for my further comments. >> 2. How do you perform the validation of a CRL? >RFC6487 provided no guidance, and referred to RFC5280, so that is still th= e case. >nothing changes herre. >> How is it similar to or different from how you validate a ROA? >There are no resources in a CRL so I presume that section 6.1 of RFC5280 i= s >a good procedure to follow. >> How do you walk the certificate hierarchy in the case of a CRL validatio= n process? >> I.e. How are the "encompassing" rules applied? >huh - I=92ll say it again just to be sure: CRLs have no resources. But what about the CA certificate under which the CRL was issued?=20 That certificate has resources in it. Don't you need to validate that certificate before you validate the CRL? Does the RP apply the revised (lenient) algorithm in that validation proces= s as well? Or, does the RP need to use two separate validation algorithms --=20 (1) the revised (lenient encompassing) algorithm for ROAs (or EE certs), an= d (2) the existing (strict encompassing) algorithm elsewhere? After re-reading Steve Kent's post, I realize that he asked a similar quest= ion earlier: http://www.ietf.org/mail-archive/web/sidr/current/msg07442.html=20 (Please see his 3rd last paragraph -- about CRLs) Sriram=20 =20 =20 From nobody Sun Nov 29 15:01:14 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22BD01B3895 for ; Sun, 29 Nov 2015 15:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6X6KBpnx6vjN for ; Sun, 29 Nov 2015 15:01:11 -0800 (PST) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) (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 706141B3897 for ; Sun, 29 Nov 2015 15:01:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=R2D2; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=RQK4A9jD/UEEEbych0plu2E82C/d5ZRISGx51AhdeuA=; b=UC0p4T/GeNIfZrD4S6GcTddgFwMp0EX9JDJEf1Kp3U4gCHJhu1xBJTStTT6abG0S3MT9srcYxxJDs zGsp8Q7soUeyWi4PYbtwikEZCiWtqScfOTSuwUKC+lLM0KXclnGF/3APxRb21hLVwutlL1zwSBJvTj VYA51wdvcAXqKkpY= Received: from NXMDA2.org.apnic.net (unknown [IPv6:2001:dd8:9:2::101:249]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS; Mon, 30 Nov 2015 09:03:15 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 30 Nov 2015 09:00:58 +1000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Geoff Huston In-Reply-To: Date: Mon, 30 Nov 2015 10:00:57 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <9277447F-2FA7-42D9-A794-632D8E2E2B4A@apnic.net> References: <565617E8.4070005@bbn.com> <8FB9C3A7-0799-4CF7-80A5-7669070B3C91@ripe.net> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: sidr Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 23:01:13 -0000 > On 30 Nov 2015, at 8:58 AM, Sriram, Kotikalapudi = wrote: >=20 > Geoff, >=20 > Thanks for your responses. Please see below for my further comments. >=20 >>> 2. How do you perform the validation of a CRL? >=20 >> RFC6487 provided no guidance, and referred to RFC5280, so that is = still the case. >> nothing changes herre. >=20 >>> How is it similar to or different from how you validate a ROA? >=20 >> There are no resources in a CRL so I presume that section 6.1 of = RFC5280 is >> a good procedure to follow. >=20 >>> How do you walk the certificate hierarchy in the case of a CRL = validation process? >>> I.e. How are the "encompassing" rules applied? >=20 >> huh - I=92ll say it again just to be sure: CRLs have no resources. >=20 > But what about the CA certificate under which the CRL was issued?=20 > That certificate has resources in it. > Don't you need to validate that certificate before you validate the = CRL? > Does the RP apply the revised (lenient) algorithm in that validation = process as well? > Or, does the RP need to use two separate validation algorithms --=20 > (1) the revised (lenient encompassing) algorithm for ROAs (or EE = certs), and > (2) the existing (strict encompassing) algorithm elsewhere? >=20 > After re-reading Steve Kent's post, I realize that he asked a similar = question earlier: > http://www.ietf.org/mail-archive/web/sidr/current/msg07442.html=20 > (Please see his 3rd last paragraph -- about CRLs) I would=92ve thought that if you can establish a chain of Issuer / = subject certs that connect a chosen Trust Anchor to the CA that issued the CRL then you = have a sound reason to accept the CRL. Given that the CRL has no resources there does not seem = to be any resource attribute test that can be applied here. Geoff