From nobody Wed Jun 1 11:52:35 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B8F12B05E; Wed, 1 Jun 2016 11:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-Nh5FHFtODY; Wed, 1 Jun 2016 11:52:31 -0700 (PDT) Received: from relay.kvm02.ops-netman.net (relay.ops-netman.net [192.110.255.59]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF9712D16C; Wed, 1 Jun 2016 11:52:31 -0700 (PDT) Received: from mail.ops-netman.net (unknown [208.76.12.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id 13B1E408C4; Wed, 1 Jun 2016 18:52:30 +0000 (UTC) Received: from donkey.her.corp.google.com.ops-netman.net (unknown [72.14.227.46]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id E01048801E5; Wed, 1 Jun 2016 18:52:29 +0000 (UTC) Date: Wed, 01 Jun 2016 14:52:29 -0400 Message-ID: From: Chris Morrow To: sidr@ietf.org,sidr-chairs@ietf.org,sidr-ads@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 18:52:33 -0000 Howdy WG folks, Please take this note as the start of the 2wk WGLC period for: Abstract: "Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present the most critical and universal. It is expected to evolve as BGPsec is formalized and initially deployed." This is a relatively short document, 8 pages, full of wonder and excitement! I hope that the wg members have read it (it's been through 8+ revisions) and that they will re-read it quickly, provide comments as appropriate and ideas on preparedness for publication or not. Thanks for you time and attention to this matter, -Chris co-chair-persona From nobody Wed Jun 1 12:11:08 2016 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 A53C912D0B1; Wed, 1 Jun 2016 12:11:06 -0700 (PDT) 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.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160601191106.16131.55765.idtracker@ietfa.amsl.com> Date: Wed, 01 Jun 2016 12:11:06 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-17.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 19:11:06 -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 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-17.txt Pages : 13 Date : 2016-06-01 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-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-pki-profiles-17 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 Jun 1 12:12:37 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4779812D0B1 for ; Wed, 1 Jun 2016 12:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34eVws6qtoKl for ; Wed, 1 Jun 2016 12:12:32 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 8DF3212B05E for ; Wed, 1 Jun 2016 12:12:32 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id c140so19729857qke.2 for ; Wed, 01 Jun 2016 12:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=SPu/xkutL0QkRNPDO+HHoxfFj5u3xpRwx+Ewbj6+I2k=; b=WF+HnWsMoOY67BaYupREj9A5toB9vEfgucHqtXOYexzudNbNES2CC/rEQ17vA4rYd+ Tkhs57pSWQlxBFpEIC66Z5BJT1T6LslVCBgaf3+zMZPVRFVGQ+7RVDMPoUDDwlai5aTz oyWmgZv83SG6d24S2zPkiQd7zjJub80QqIKbk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=SPu/xkutL0QkRNPDO+HHoxfFj5u3xpRwx+Ewbj6+I2k=; b=OUgXQq7kcep3b2XoTsHNyhwZAJjkH4wTTuZ9ifMsLmlWA6kFy6CWd06xmKEc4zlRkN bq03nDnLuYEYVR2dlej3Pnz8AmssuX+6qHMehX6Vq7TFAFDNXIS6mnmAc1su74/s5iqq wNgy50s4KcytWVUCAFOSqcWsmyjqz5f13pwAPMraEubCdMb5vfKPj9SILv3cDOiIYZ/K ttjKHwvLfWX5BHtZnSHVsKB8IZqpnjdBOfc46BGDs9EhxyMpK8KhgUiCcj17heE3RK/f RXaYnS6XoBqQ7Tlwgg5daJVGBS1NtZfFjvQ/YDG5PbakugQBMismOJl+A5YWOWOEuADt zV3g== X-Gm-Message-State: ALyK8tIpaJ539mHevd0xcFdwZOYVzke6aOrBLMev9HjN+gfZSmHts3jHnrEA7Wnruv04oQ== X-Received: by 10.200.54.43 with SMTP id m40mr5405811qtb.46.1464808351615; Wed, 01 Jun 2016 12:12:31 -0700 (PDT) Received: from [172.16.0.112] (pool-173-73-123-71.washdc.east.verizon.net. [173.73.123.71]) by smtp.gmail.com with ESMTPSA id f144sm12686065qhf.21.2016.06.01.12.12.30 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 01 Jun 2016 12:12:30 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <20160601191106.16131.55765.idtracker@ietfa.amsl.com> Date: Wed, 1 Jun 2016 15:12:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160601191106.16131.55765.idtracker@ietfa.amsl.com> To: sidr X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-17.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 19:12:35 -0000 Updated with a new 3.4 section as per Sandy=E2=80=99s direction. spt > On Jun 01, 2016, at 15:11, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Secure Inter-Domain Routing 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-17.txt > Pages : 13 > Date : 2016-06-01 >=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-17 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-pki-profiles-17= >=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 Jun 2 08:10:49 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A35512D757 for ; Thu, 2 Jun 2016 08:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfOvE_sAonWE for ; Thu, 2 Jun 2016 08:10:36 -0700 (PDT) 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 0B2A512D17E for ; Thu, 2 Jun 2016 08:10:36 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 5A54F28B0043; Thu, 2 Jun 2016 11:10:35 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 3A50D1F8055; Thu, 2 Jun 2016 11:10:35 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_90F4FE0D-42CD-4F13-BBF3-2C78CD8D735E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Sandra Murphy In-Reply-To: Date: Thu, 2 Jun 2016 10:54:39 -0400 Message-Id: <43EA7FA8-64EB-4FAA-BDE1-1153E62D62E5@tislabs.com> References: <20160601191106.16131.55765.idtracker@ietfa.amsl.com> To: Sean Turner X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: sidr , Sandra Murphy Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-17.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 15:10:42 -0000 --Apple-Mail=_90F4FE0D-42CD-4F13-BBF3-2C78CD8D735E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks for the new draft! I can do a pub request. This, algs, and protocol are a cluster, by normative refs. There are = others that are informative refs, but I think they can go later. =97Sandy On Jun 1, 2016, at 3:12 PM, Sean Turner wrote: > Updated with a new 3.4 section as per Sandy=92s direction. >=20 > spt >=20 >> On Jun 01, 2016, at 15:11, internet-drafts@ietf.org wrote: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Secure Inter-Domain Routing 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-17.txt >> Pages : 13 >> Date : 2016-06-01 >>=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-17 >>=20 >> A diff from the previous version is available at: >> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-pki-profiles-17= >>=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 --Apple-Mail=_90F4FE0D-42CD-4F13-BBF3-2C78CD8D735E 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 iQIcBAEBCgAGBQJXUEjGAAoJEHplpQeet0IZ+EoQALclh8bR/CDHnUJP6DMuBeCi 3lYXKksS4Tv59YtONOx9cO7iHEobe0eCTM28A6BrsZOXThvA6bxk0ntwnhJNzT0v Ol2NIPx1Bjy+ILyOY0Z/kpL7ON6BUGynWE8Cqs/QXUZM8goVK9s6sxbd4JwQqthB XEnzPvSlMLavYXP0NP6+d5Zby+zg03rYnZnJyOtmdP+i830lrWHqNPFAi7ddmNXG pHieNl2LIla5k00zqGmJ2cj1i1BzCgG2P68BYtPTJpmcEa7mlG+V6iBGLYTQHABP xvCkjfEtcvq17ptPX+n3Tvn/axBU90cTl4uJ+7ukuhlZq0pRrs7Vz7U2VM2u91EL GPQaK4Ur7joUWDzewICPZXAbEmmngnjmPPQ6WWNXvL18mEqh7Enx9dpVHSIVhiQb EdAadGhK4Dyrt5mK3FhOc3Kj5hDEe/jQJDYxH/CxRF1FM/ur0SfaiXBF54zlbw0k y7y8DL/Tdzx11kNS0sl/ihy+epxjWFpuXoIgxILK7/TssbDLmAQWLcUHdv5em81f IUSX3JYwc2V4rHA8mfZv1xNcquKOEj/TfctPBSiUeqad2Cb4XF7X3cMxVOE7DviE G4es6SgKEgOpWkcxLEi1n9zt0BX2SWaaGymnPoQykmgmYU4ecnVr+nWVGwKyz4uY P45i7upbsofhyWQxGVk1 =lxSw -----END PGP SIGNATURE----- --Apple-Mail=_90F4FE0D-42CD-4F13-BBF3-2C78CD8D735E-- From nobody Mon Jun 6 12:10:49 2016 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 3EC2C12B02C; Mon, 6 Jun 2016 12:10:46 -0700 (PDT) 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.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160606191046.20785.77186.idtracker@ietfa.amsl.com> Date: Mon, 06 Jun 2016 12:10:46 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-lta-use-cases-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 19:10:46 -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 of the IETF. Title : RPKI Local Trust Anchor Use Cases Author : Randy Bush Filename : draft-ietf-sidr-lta-use-cases-05.txt Pages : 5 Date : 2016-06-06 Abstract: There are a number of critical circumstances where a localized routing domain needs to augment or modify its view of the Global RPKI. This document attempts to outline a few of them. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-lta-use-cases/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-lta-use-cases-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-lta-use-cases-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 Mon Jun 6 12:15:19 2016 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 074D212D8C1; Mon, 6 Jun 2016 12:15:13 -0700 (PDT) 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.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160606191513.20854.10505.idtracker@ietfa.amsl.com> Date: Mon, 06 Jun 2016 12:15:13 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-08.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 19:15:13 -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 of the IETF. Title : BGPsec Operational Considerations Author : Randy Bush Filename : draft-ietf-sidr-bgpsec-ops-08.txt Pages : 8 Date : 2016-06-06 Abstract: Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present the most critical and universal. It is expected to evolve as BGPsec is formalized and initially deployed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-ops-08 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 Jun 7 03:32:24 2016 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 D774F12B03C; Tue, 7 Jun 2016 03:32:18 -0700 (PDT) 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.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160607103218.13772.36119.idtracker@ietfa.amsl.com> Date: Tue, 07 Jun 2016 03:32:18 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 10:32:19 -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 of the IETF. Title : RPKI Validation Reconsidered Authors : Geoff Huston George Michaelson Carlos M. Martinez Tim Bruijnzeels Andrew Lee Newton Alain Aina Filename : draft-ietf-sidr-rpki-validation-reconsidered-04.txt Pages : 11 Date : 2016-06-07 Abstract: This document proposes an update to the certificate validation procedure specified in RFC 6487 that reduces aspects of operational fragility in the management of certificates in the RPKI, while retaining essential security features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-rpki-validation-reconsidered-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-validation-reconsidered-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 7 04:15:28 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A028212B01F for ; Tue, 7 Jun 2016 04:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tg-pe-EvPn7y for ; Tue, 7 Jun 2016 04:15:23 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECA0712B022 for ; Tue, 7 Jun 2016 04:15:22 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1bAEyZ-000ARO-Sp; Tue, 07 Jun 2016 13:15:19 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-185.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1bAEyZ-00055K-Kw; Tue, 07 Jun 2016 13:15:15 +0200 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Tim Bruijnzeels In-Reply-To: <5707CB26.5060706@bbn.com> Date: Tue, 7 Jun 2016 13:15:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2230686E-8E41-42AF-BE34-E34B6B2B7FF5@ripe.net> References: <5707CB26.5060706@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ---------- X-RIPE-Spam-Report: Spam Total Points: -10.8 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.4 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: 784d7acfe6559f2a0b602ec6519a0719c4a3303c06a7fcd1ed0304c767c4651d Archived-At: Cc: sidr Subject: Re: [sidr] comments on validation reconsidered -03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 11:15:26 -0000 Dear Steve, WG Thank you for the review. I haven't had much time unfortunately, but I = finally managed to upload a new version -04 that I believe addresses = most of the comments you made. Generally speaking this new version: - Updates existing standards - We restructured somewhat to avoid back and forward referencing within = this document. We now have: Section 2: Certificate Validation in the RPKI (current status) Section 3: Operational Considerations (why we believe there is an = issue to address) Section 4: An Amended RPKI Certification Validation Process (the = proposal) - Uses documentation prefixes for IPv6, IPv4 and ASNs - Introduces concept of "Verified Resource Set" and "overclaims" more = explicitly=20 - Uses overclaims in IPv4 space only in example to make it clear that = this is unrelated to address family. Some specific replies inline below, but I would kindly ask to comment on = -04 going forward. Finally, since this document attempts to update existing standards, can = we change it from "Informational" to "Proposed Standard"? Thanks Tim > On 08 Apr 2016, at 17:15, Stephen Kent wrote: >=20 > First, let me say this this version of the document is much improved = relative to previous versions. I do have a few observations about this = version, and some suggested changes.=20 > =20 > Abstract: > =20 > There are 2 typos, and I think you want to assert that the revisions = don=E2=80=99t undermine security, right? > =20 > This document proposes an alternative to the certificate validation > procedure specified in RFC 6487 that reduces aspects of operational > fragility in the management of certificates in the RPKI, while = retaining > essential security features. > =20 >=20 > Also, presumably, this is not really "an alternative" but a proposal = to > UPDATE 6487 so that all RPs use the new pat validation algorithm, = right? indeed, updated accordingly >=20 > Section 2: > =20 > The final sentence here says:=20 > =20 > The roa "ROA1" is also considered valid here in this regard=20 > - the prefix is encompassed by the embedded EE certificate. > =20 > The example ROA is valid, but the final check on ROA validation is = specified in RFC 6482, not in 6488. Thus the text might say: > =20 > The ROA =E2=80=9CROA1=E2=80=9D is valid because the specified prefix = is encompassed by the embedded EE certificate, as required by RFC 6487. > =20 > Similar wording should be used when discussing the validity of ROAs = in other examples throughout the document. Ok, I modified the examples and should reference the correct RFCs. > Section 3: > =20 > The motivation cited here =E2=80=9Cresource allocations can change in = the RPKI=E2=80=9D is so terse as to be not very persuasive. Previous = versions of the draft mentioned resource transfers, for example. We have = no standard for how to perform a transfer, however one could state that = the proposed change would reduce the constraints imposed on the order = in which the CAs involved in a transfer re-issue certificates. Also, if = you believe that the proposed change will help minimize the impact of = some types of operational errors, then that too could be said. For = example: > =20 > The allocations recorded in the RPKI change as a result of resource = transfers and some types of operational errors. For example, the CAs = involved in transfer might choose to modify CA certificates in an order = that causes some of these certificates to =E2=80=9Cover-claim=E2=80=9D = temporarily. Some types of operational errors that may occur during = management of RPKI databases also may create CA certificates that, = temporarily, no longer encompass all of the resources in subordinate = certificates. Okay, I hope the new text is easier to parse. That being said, the point of this section is not to enumerate all the = possible ways that an "overclaim" can occur. The point is that an = "overclaim" can have an impact on other resources. And it's this = collateral damage that we wish to address. > The proposed changes (Section 4) to the validation procedure in = [RFC6487] are intended to avoid causing CA certificates to be treated as = invalid during transfers and as the result of some types of operational = errors. However, these changes are designed to not degrade the security = offered by the RPKI. Specifically, no ROAs or router certificates will = be treated as valid if they contain resources that are not encompassed = by all superior certificates along a path to a trust anchor. > =20 > If you believe this text matches your intent, I think it provides a = better rationale for making the proposed changes. I updated section 4 and included some of your text. >=20 > =20 > The text at the top of page 4 says: > =20 > It should be noted that CA2 is not claiming any resources on ROA1 > that it cannot receive on a new Certificate 3. =20 > =20 > I expected you to say that the EE certificate in ROA1 does not make = use of any of the address resources that were removed from CA1=E2=80=99s = certificate, and thus it would be desirable if ROA1 could still be = viewed as valid. This motivates the goal of the proposed changes, i.e., = to avoid having a ROA become =E2=80=9Ccollateral damage=E2=80=9D due to = over-claiming by a superior CA certificate. Saying that a new Cert3 can = be issued to fix this problem is true, but fails to focus on the goal of = minimizing the impact of an operational error of this sort.=20 > =20 > The paragraph that discusses how one might modify the text in 6492 to = avoid over-claiming by subordinate CAs, when resources are removed from = a CA certificate is problematic. Nothing prevents a CA from unilaterally = re-issuing a certificate to subordinate CAs with reduced resource sets, = when the CA itself requests (or is given) a certificate with a reduced = resource set. The next paragraph seems to say that, indirectly, but = it=E2=80=99s confusing (at least to me). The final paragraph of this = section introduces the notion that the reason for the reduction in scope = of CA1=E2=80=99s certificate is a dispute between the TA and that CA. = This is pretty late in the section to suggest that this is why the CA = certificate was reissued with reduced resources. And it doesn=E2=80=99t = align with the rationale you provided or that I suggested above.=20 > I suggest these paragraphs need to be revised. I removed forward and backward references between the sections of the = document that led to some imprecise text about current status, = motivation for change, and impact of change. > =20 > Section 4: > =20 > I don=E2=80=99t feel the revised text here is precise enough to = provide clear guidance to implementers. RFC 6487 does not mention the = term intersection in discussing path validation, so introducing that = term in one sentence seems too terse. The text I provided a few months = ago provided a more thorough discussion of the revised algorithm. For = example, it noted the need to maintain two sets of resource data as part = of the algorithm (one for addresses and one for ASNs), something not = specified here. Also, the paragraph describing how to interpret the = inherit flag is true, but I think it belongs as the beginning of the = description of the revised procedure, with the introduction of the two = working resource sets. In the current description its location of the = two paragraphs below is very confusing. > =20 > For any of the resource extensions that use the "inherit" > element as described in sections 2.2.3.5 and 3.2.3.3 of > [RFC3779], the corresponding resources of this type should be > taken from the parent certificate, where this issuer is the > subject. > =20 > For any other resources the intersection of the quoted > resources on this certificate and the parent certificate is > kept. If any resources were found on this certificate that > were not present on the parent certificate a warning SHOULD be > issued to help operators rectify this situation. > =20 > The second paragraph exempts the resources specified by an inherit = flag from the intersection operation. Do you really want that to happen? = Also, the term =E2=80=9Cquoted=E2=80=9D isn=E2=80=99t well-defined in = this context. Do you mean the resources specified in the certificate? > =20 > The last sentence/paragraph in the revised path validation description = says: > =20 > If the the [sic] set of verified resources obtained this way is = empty, > then the certificate MUST be considered invalid. > =20 > It=E2=80=99s unclear fro this statement whether a certificate is = invalid if either the address or ASN extensions yield an empty = intersection, or only if both intersections are empty, or what. This is = another example of why I think the proposed path validation algorithm = needs to include additional details. > =20 > Overall, I think you need to expand the description of the validation = algorithm revisions. The revised text should establish the fact that = there are two working sets and say that these sets are to be used in = lieu of the > 3779 extensions in a certificate (after performing the intersection = operation). If you don=E2=80=99t want to also revise RFC 6482, then you > need to state that the working set is to be used in lieu of the 3779 > extensions when performing further validation operations, and cite = 6482 as an example.=20 We revised section 4 quite a bit. We introduced an explicit "Verified = Resource Set" and provide text on how to use this in existing standards. > Section 5: > =20 > It=E2=80=99s nice to begin with a note stating that the concerns that = motivate the proposed revision to 6487 have not yet surfaced. However, = referring to over-claiming as an =E2=80=9Cinconsistency=E2=80=9D seems = needless indirect. You refer to over-claiming as the problem throughout = the document, so why not here?=20 > =20 > The next paragraph again refers to the over-claimed resources as being = =E2=80=9Cunder dispute.=E2=80=9D I think this is too narrow a = characterization of the circumstance that might result in a = over-claiming certificate being issued. Please revise this sentence to = better characterize the range of situations that might result in = over-claiming, or provide a back pointer to a section of the document = where that topic is discussed. > =20 > I find the opening sentence of the last paragraph here to be a bit = confusing: > =20 > It should be noted that although this is a problem with a low > probability today this is largely due to the fact that most current > RPKI systems use their own Trust Anchor and do not support any = large > number of delegated CAs. =E2=80=A6 > =20 > By =E2=80=9CRPKI systems=E2=80=9D do you the RIRs as high-tier CAs? = Relying parties select Trust Anchors, so this sentence is not quite = consistent with usual PKI terminology. How about this phrasing: > =20 > Although the concerns that motivates this revision to RPKI path = validation > has not yet been observed in practice, this may be largely due to = the fact > that most of the certificates have been issued directly by the = RIRs. Each > RIR operates its own Trust Anchor (or set of Trust Anchors) and = there are=20 > few (non-RIR) CAs that have established subordinate CAs with = distinct > resource holdings. When more CAs receive certificates from non-RIR = parents, > and when more transfers of resources involve more than three CAs = (source, > target, and common ancestor), the authors anticipate that these = concerns=20 > will become more commonplace. We shortened the security consideration section. The point we tried to make about how our proposal does not change the = probability of this problem, but aims to change this from a potentially = high impact to a *lower* impact problem, has been moved to the section = where we describe our proposal. > =20 > =20 > =20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Wed Jun 8 12:59:48 2016 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 E063112D7C4; Wed, 8 Jun 2016 12:59:46 -0700 (PDT) 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.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160608195946.19975.17861.idtracker@ietfa.amsl.com> Date: Wed, 08 Jun 2016 12:59:46 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-route-server-rpki-light-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 19:59: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 of the IETF. Title : Signaling Prefix Origin Validation Results from a Route-Server to Peers Authors : Thomas King Daniel Kopp Aristidis Lambrianidis Arnaud Fenioux Filename : draft-ietf-sidr-route-server-rpki-light-00.txt Pages : 6 Date : 2016-06-08 Abstract: This document defines the usage of the BGP Prefix Origin Validation State Extended Community [I-D.ietf-sidr-origin-validation-signaling] to signal prefix origin validation results from a route-server to its peers. Upon reception of prefix origin validation results peers can use this information in their local routing decision process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-route-server-rpki-light/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-route-server-rpki-light-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 8 19:31:19 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881E912D0BA; Wed, 8 Jun 2016 19:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWybdpuz7zo2; Wed, 8 Jun 2016 19:31:17 -0700 (PDT) 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 18AD012D12F; Wed, 8 Jun 2016 19:31:17 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 702BA28B0040; Wed, 8 Jun 2016 22:31:15 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 5FEAF1F8055; Wed, 8 Jun 2016 22:31:15 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F14FA577-71D1-4A6A-8654-64221DA155F5"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Sandra Murphy In-Reply-To: Date: Wed, 8 Jun 2016 22:19:54 -0400 Message-Id: <61339176-792E-4000-BBBD-D17D4962E249@tislabs.com> References: To: sidr X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: sidr-ads@ietf.org, sidr chairs , Sandra Murphy Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 02:31:18 -0000 --Apple-Mail=_F14FA577-71D1-4A6A-8654-64221DA155F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 No responses at all. Come on folks. It=92s a short document, like Chris says. You should be able to read and comment without much trouble. =97Sandy, speaking as one of the wg co-chairs On Jun 1, 2016, at 2:52 PM, Chris Morrow wrote: >=20 > Howdy WG folks, > Please take this note as the start of the 2wk WGLC period for: > >=20 > Abstract: > "Deployment of the BGPsec architecture and protocols has many > operational considerations. This document attempts to collect and > present the most critical and universal. It is expected to evolve = as > BGPsec is formalized and initially deployed." >=20 > This is a relatively short document, 8 pages, full of wonder and > excitement! I hope that the wg members have read it (it's been through > 8+ revisions) and that they will re-read it quickly, provide comments > as appropriate and ideas on preparedness for publication or not. >=20 >=20 > Thanks for you time and attention to this matter, >=20 > -Chris > co-chair-persona >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_F14FA577-71D1-4A6A-8654-64221DA155F5 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 iQIcBAEBCgAGBQJXWNJaAAoJEHplpQeet0IZcoQP/jsm7y4pAc1ZxdUaIUR0TdG8 mcLrZuFk+PTSwkDqOswgP3z1GN1uh+o+exQF+/IqMU/iS557ABvGalvF87xsMrXV kE4GnMFH+7HIoryMoxeKZ90ivT+GZ6maWtrp1xjEm0fj20IC6BGOmzkEq9Hgg9uw m1WhF1d0MNMEQPIcR/MItn/TUbBlXx3LnKcOBUzrirWnzI7TgJBjsBuvkyrH4hce s9b2fth1lBHtxKuFu+PL9tRp8QFCWOwpHs3SOC8dlD/7YxJ4sIPTY0ponx2Z9/mw RF6hIzrb4/tRLQYYkT3n8IBc1hbZfEmFyRQBjIVxfIVb55i2u/8ykxWTSYFF8NWP ZPtI7Wpfvmd2hcZSucdhw7cvymIMr7SxBcfTm8ExqmAy8lzDdx5dccu+0l3QZSMU 7+Xhg7iHJ/Hrce4R35DV66/2vX49+74aBqsSk1zfeL8s/yIJ6FqBPrgdBJmmx4KL MjGgmVcloqEsgJ+GyEg0W6wqmOPAbgxEBkVQtSOVd+oup65ikGQH/cqZLpef+fbR iuoa4Zy7frfCcjbyYWy9YJUHBF1rGX8NrlnIQWXhEOT7upCWVGOYMfW/e7hu8ybA Clld07pjQpWL8sc0Xyjnd0lhZ4OwWyBTUxjPWJEUUbMy5tPJsXBN7GZrQHxE6djY CQBLPFtfcHXTaRpjGQPJ =NebT -----END PGP SIGNATURE----- --Apple-Mail=_F14FA577-71D1-4A6A-8654-64221DA155F5-- From nobody Wed Jun 8 19:37:10 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FC712D12F for ; Wed, 8 Jun 2016 19:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIGreDUhbVBa for ; Wed, 8 Jun 2016 19:37:08 -0700 (PDT) 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 E98F512B029 for ; Wed, 8 Jun 2016 19:37:07 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 3BDEA28B0040; Wed, 8 Jun 2016 22:37:07 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 350491F805A; Wed, 8 Jun 2016 22:37:07 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_782EC7F3-C922-4A2C-ADD2-C001462474F5"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Sandra Murphy In-Reply-To: <1CD27ACC-F5D2-4F11-8DD5-2B1F42544406@ripe.net> Date: Wed, 8 Jun 2016 22:36:18 -0400 Message-Id: <6B1254FF-8A81-4923-BBE6-12536C6001C9@tislabs.com> References: <1CD27ACC-F5D2-4F11-8DD5-2B1F42544406@ripe.net> To: Tim Bruijnzeels X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: sidr , Sandra Murphy Subject: [sidr] come on people Re: The question about https certificates and frequency of mft/crl re-issuance X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 02:37:09 -0000 --Apple-Mail=_782EC7F3-C922-4A2C-ADD2-C001462474F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Tim=92s been waiting very patiently for any response to this. The discussion was energetic and lots of people commented during the = meeting and Tim promised to bring it to the list. Where it looks like it is dying. Those people who were speaking at this = mike so energetically should be responding. =97Sandy, speaking as one of the wg co-chairs and nagger On Apr 4, 2016, at 6:51 PM, Tim Bruijnzeels wrote: > Hi all, >=20 > I promised to take this to list. >=20 > So, as presented today, the volume of updates of MFTs and CRLs in the = RIPE NCC repository vs updates of ROAs is about 1000:1. This is a bad = signal -to-noise ratio that causes waste of cycles and bandwidth. >=20 > =3D Why this noisy? MITM.. > We get this, because we use a 'next update time' of 24 hours, but we = actually republish every 8 hours to make sure that we can fix issues = before things go stale. In my understanding we need this because of = man-in-the-middle attacks involving replay or withhold. And rsync is = vulnerable to this (clear text, and no authentication of server). If an = RP is being fed old data, they would notice that something is wrong = within 24 hours. A longer period seems scary.. If this understanding is = wrong I would love to be educated. >=20 > =3D Solved by https? > But assuming this does make sense, I wondered whether RRDP with httpS = offers a way out of this. With RRDP a CA signs a certificate with an = https URL like: https//my.repository.example.org/notification.xml. We = can trust this because it's on a signed certificate. Now, if we can also = exclude mitm, because we can trust the httpS certificate, this would = allow for a much longer period 'next update time'. And in the meantime = the RP would still learn about updates before this, because the = notification.xml is checked regularly and would include any changes = ahead of this. >=20 > =3D If so, how to handle https TAs? > This is a question for RPs. But trusting all https certificates or all = default TAs configured on a system is potentially problematic if the CA = assumes that RPs check against mitm. Some of the many TAs preconfigured = in browsers have been shown to have issues here. >=20 > Then again, RP software could be pre-configured with a smaller set of = TAs or even server certificates for know repositories and offer an = interface to operators to change this set. Or RPs could accept new = certificates for repositories, but require operators to confirm changes. = The number of expected repositories isn't great. But there clearly are = scaling issues here. >=20 > As I stated on the mic. I don't claim to have the answer. But I think = it's really worth thinking about ways to reduce the signal-to-noise = ratio mentioned. >=20 > Tim >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_782EC7F3-C922-4A2C-ADD2-C001462474F5 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 iQIcBAEBCgAGBQJXWNYzAAoJEHplpQeet0IZ5/YQAMNem2jdao21t4+BGfbo3iIO eUvW+scX/Oe39IXSKw6lhOT8ODwLW/cdoCsjsnMPyLgVRWfMCwLgL29ltuzoq1wA 8ejiIX8J84UiqIvFwQXXPnoo96uXGIuBqyXjCn5Sk8j2s3Chi36f/gR+anQYgtJ1 GyM3PZxTNb55JOMIiMUiME5vWXDuSw9LivppHzJQn5mBf8oIQo7BF8m1jciftF/z CeYcjG4No9tl6gZ6Qdp6bkbR9FeTAY5HN+cKn+vPct6fbJcGkWewzKUIySZCE7UF vPAz6QnM5anmYY4hoSml01lodnUI3J4NF+6BsF/1GsurPvwF3AYVkTloPhX/TBrw BjJ/kDjJ3ZOVHrFDZgsYX7Bd3FN7xT7Bs4xnr3xajpkPt5H9MHwU89P+Zxdgt6Ut 1KwN0str9WcRAUsVZ9az5vVX4enk49ktJKD6MWRcujaQniUqW6K9bDVMzOl+3eVo Nyw3vlXJPiHygzILZLwuweCC9xjZQjsUSju00S+QEq1AV6cALEdzkkHFPM1PMEMq rLVMqldOpIFttqnP3DK2J84MrF55ncPq/TdF3TPW4wFWfqXfysIlqSCG41xbdBw0 p1jkl9h0R4nDTth1jgOlTSiIs0s2eW6460Sbm/qG0GaIT+S9Sh7XgdS9+YfwNhvO vQQ9qdu1512QnYhyMl7h =wbAf -----END PGP SIGNATURE----- --Apple-Mail=_782EC7F3-C922-4A2C-ADD2-C001462474F5-- From nobody Mon Jun 13 12:53:47 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBDD12D9BE for ; Mon, 13 Jun 2016 12:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.627 X-Spam-Level: X-Spam-Status: No, score=-4.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEFa_xcKbtfx for ; Mon, 13 Jun 2016 12:53:44 -0700 (PDT) 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 4D27212D9CF for ; Mon, 13 Jun 2016 12:53:20 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:59935 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bCXvC-000BE3-Sf for sidr@ietf.org; Mon, 13 Jun 2016 15:53:19 -0400 To: sidr From: Stephen Kent Message-ID: <41005840-be6f-5612-af4e-a1bee67a9cfc@bbn.com> Date: Mon, 13 Jun 2016 15:53:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sidr] draft-ietf-sidr-adverse-actions-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 19:53:45 -0000 I realize that this is just a -00 draft, but we had a moderate amount of discussion before it became a WG document, and after the requested changes were made, many people expressed a support for its adoption. Thus, I am requesting that the chairs initiate WGLC, to encourage additional review for this doc. Thanks, Steve From nobody Mon Jun 13 13:10:48 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A771D12D614 for ; Mon, 13 Jun 2016 13:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.627 X-Spam-Level: X-Spam-Status: No, score=-4.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4ShQ5lTzutI for ; Mon, 13 Jun 2016 13:10:45 -0700 (PDT) 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 B009A12D62D for ; Mon, 13 Jun 2016 13:10:40 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:51682 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bCYBz-000PQW-Fx for sidr@ietf.org; Mon, 13 Jun 2016 16:10:39 -0400 To: sidr@ietf.org References: <1CD27ACC-F5D2-4F11-8DD5-2B1F42544406@ripe.net> From: Stephen Kent Message-ID: <396e87de-9ed6-a49d-2f17-68a1a43df60d@bbn.com> Date: Mon, 13 Jun 2016 16:10:39 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <1CD27ACC-F5D2-4F11-8DD5-2B1F42544406@ripe.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sidr] The question about https certificates and frequency of mft/crl re-issuance X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 20:10:47 -0000 Tim, Sorry to have not replied sooner. > Hi all, > > I promised to take this to list. > > So, as presented today, the volume of updates of MFTs and CRLs in the RIPE NCC repository vs updates of ROAs is about 1000:1. This is a bad signal -to-noise ratio that causes waste of cycles and bandwidth. > > = Why this noisy? MITM.. > We get this, because we use a 'next update time' of 24 hours, but we actually republish every 8 hours to make sure that we can fix issues before things go stale. In my understanding we need this because of man-in-the-middle attacks involving replay or withhold. And rsync is vulnerable to this (clear text, and no authentication of server). If an RP is being fed old data, they would notice that something is wrong within 24 hours. A longer period seems scary.. If this understanding is wrong I would love to be educated. I think an 8-hour cycle is very much overkill, despite the good intentions that motivated it. An RP should detect when a manifest is stale, since the manifest carries a next publication date. It's a local matter as to how stale a Manifest can be before an RP sounds an alarm. The actions an RP MAY take in the face of a stale Manifest are also largely a local matter, as per RFC 6486. So, I don't think an 8-hour re-pub rate is warranted given these local policy aspects of Manifest processing. Similarly, daily CRL publication strikes me as overkill as well. Yes, it's nice to be able to say that IF there were a need to revoke a cert, everyone could know about that in 24 hours. BUT, revocations in many PKIs are fairly rare, and in the RPKI they seem very infrequent as well, right? I'd suggest a default next update frequency for both CRLs and Manifests of 1 week. This should be shortened if a resource is about to be transferred, or there is a planned key rollover, etc. If we adopt 1 week as the default, then pushing out new versions every 3-4 days would be reasonable, IMHO. These changes would reduce churn by a factor of 10 or so. > = Solved by https? > But assuming this does make sense, I wondered whether RRDP with httpS offers a way out of this. With RRDP a CA signs a certificate with an https URL like: https//my.repository.example.org/notification.xml. We can trust this because it's on a signed certificate. Now, if we can also exclude mitm, because we can trust the httpS certificate, this would allow for a much longer period 'next update time'. And in the meantime the RP would still learn about updates before this, because the notification.xml is checked regularly and would include any changes ahead of this. I'm not sure I understand the analysis above. In the current scheme, the next update times for CRLs and Manifests are signed objects too. yes, an RP could learn about an earlier update IF there is no attack that prevents timely dissemination of the notification file. But, what prevents an attacker from delaying such notifications? I'll have to think about your TA questions some more before replying. Steve From nobody Tue Jun 14 20:38:55 2016 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 B327D12B041; Tue, 14 Jun 2016 20:38:53 -0700 (PDT) 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.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160615033853.31785.68837.idtracker@ietfa.amsl.com> Date: Tue, 14 Jun 2016 20:38:53 -0700 Archived-At: Cc: sidr@ietf.org, draft-ietf-sidr-rfc6485bis@ietf.org, sidr-chairs@ietf.org, sandy@tislabs.com Subject: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-rfc6485bis-05: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 03:38:54 -0000 Terry Manderson has entered the following ballot position for draft-ietf-sidr-rfc6485bis-05: 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: ---------------------------------------------------------------------- Thank you for amending the text in Section 5 (Additional Requirements) to reflect the work in RFC6916 and removing the explicit contradiction. Setting my ballot to No Objection. From nobody Wed Jun 15 06:35:53 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9EB12D615; Wed, 15 Jun 2016 06:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_zGSsl-kkO1; Wed, 15 Jun 2016 06:35:51 -0700 (PDT) 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 9DB5A12D60E; Wed, 15 Jun 2016 06:35:51 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id F187E28B0040; Wed, 15 Jun 2016 09:35:50 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id D3EE01F8056; Wed, 15 Jun 2016 09:35:50 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CE0B57E4-A494-441D-84D7-3B37E51F9D36"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Sandra Murphy In-Reply-To: <61339176-792E-4000-BBBD-D17D4962E249@tislabs.com> Date: Wed, 15 Jun 2016 09:35:43 -0400 Message-Id: References: <61339176-792E-4000-BBBD-D17D4962E249@tislabs.com> To: Sandra Murphy X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: sidr chairs , sidr Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 13:35:53 -0000 --Apple-Mail=_CE0B57E4-A494-441D-84D7-3B37E51F9D36 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 It is a short document. The sentences are not complicated. It reads = quickly. There=92s been little/no wg comment on this, certainly no controversy, = over the lifetime of the draft. But still. Please. Pretty please. Pretty please with sugar on top. Pretty please = with a cherry on top. Could we get some feedback that this document is ready for publication? =97Sandy, speaking as one of the wg co-chairs On Jun 8, 2016, at 10:19 PM, Sandra Murphy wrote: > No responses at all. >=20 > Come on folks. It=92s a short document, like Chris says. >=20 > You should be able to read and comment without much trouble. >=20 > =97Sandy, speaking as one of the wg co-chairs >=20 > On Jun 1, 2016, at 2:52 PM, Chris Morrow = wrote: >=20 >>=20 >> Howdy WG folks, >> Please take this note as the start of the 2wk WGLC period for: >> >>=20 >> Abstract: >> "Deployment of the BGPsec architecture and protocols has many >> operational considerations. This document attempts to collect and >> present the most critical and universal. It is expected to evolve = as >> BGPsec is formalized and initially deployed." >>=20 >> This is a relatively short document, 8 pages, full of wonder and >> excitement! I hope that the wg members have read it (it's been = through >> 8+ revisions) and that they will re-read it quickly, provide comments >> as appropriate and ideas on preparedness for publication or not. >>=20 >>=20 >> Thanks for you time and attention to this matter, >>=20 >> -Chris >> co-chair-persona >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 --Apple-Mail=_CE0B57E4-A494-441D-84D7-3B37E51F9D36 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 iQIcBAEBCgAGBQJXYVm2AAoJEHplpQeet0IZNgIP/i//DeeZ1/6+IzRC9/0M+PiT JadAqJcwvISXinimkzcHiwmE7TAI43vwUEBlq0V6YvguC/UzjR9nPY2Y/lcbRrP+ +IpxhWJsGP8Wki4KuBhmTo0GA/mTGjcv46EyDUd6yd8QcMfEtdV2hNDKSpaeXn+t PErZjLvCs4KSOlq+j4i2iE+taMu6EgcJr2BvOXPR2efRWxX2fWJPooqN4nhzQJFm lWFsYMR0BePb5CblWeNfGnKJztECJAbRwE9L/pATr+jHEbfTObMcE5QbUqBreyfP DZuVIJJmmPaCvsQzZboLMm2Rs3nHcAgYd/9rgso2rU6CRRCgQXP2WjO2alBSwPEc SawuHLV8WJVy3oHOt5QfFUJICQMmeh34F2zhBtlATtS2i1gzbXeI5wJS/xBg9DP2 tjLIfsfGYqSzjEpSeXyqb8IWZMlmMjLdn7Vyru3YONu5HCUGXQQnMfIK3pphev9H P43PPoEoAUbbSNKVc0MQM2h5e94wA2FAnVL2xRS6CrerHdQkvjdbs85EdAFwhxTC 4xBBZ+QGinadVe5ZBgtmOAbzBtayLCTTZ+qJa9LBAhp3qDJUYMg7+6N/qumUInuk nfbqU0v7NGHWmf7nMBlfN5Y/A+lGugHCTTXELusP9s5rWGl0yOyqLpG174SIFdpj 0WrhDcgzO0/UbwQ1Gf29 =qLwo -----END PGP SIGNATURE----- --Apple-Mail=_CE0B57E4-A494-441D-84D7-3B37E51F9D36-- From nobody Wed Jun 15 07:58:23 2016 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 C285312D689; Wed, 15 Jun 2016 07:58:21 -0700 (PDT) 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.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160615145821.20248.72879.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2016 07:58:21 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-11.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 14:58:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : Router Keying for BGPsec Authors : Randy Bush Sean Turner Keyur Patel Filename : draft-ietf-sidr-rtr-keying-11.txt Pages : 13 Date : 2016-06-15 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-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-11 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 Jun 15 07:59:36 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF6112D79C for ; Wed, 15 Jun 2016 07:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRI04RPzMPaX for ; Wed, 15 Jun 2016 07:59:34 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 3050012D689 for ; Wed, 15 Jun 2016 07:59:34 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id a186so21155401qkf.0 for ; Wed, 15 Jun 2016 07:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=vocCFobUM8Br/y3fqO50FNTAAcyUK3X2mKZ6ZfKGhm8=; b=J0EzhYVvhHQ3TZQZ5rt7EL4z8jPv5CVYbbD5DhZP6m18ztu3bm8vjE1rmoeDs9xxIy wtlRwXsV7iiSjZtmkixJEKvPhHWuF/oQSp+ecGiZhudT6M+2YeralV/d4+1xJ9QxgG+i NYmeSB6N1sPZaNK/7WUx3hxam9E5bD/9ivVr8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=vocCFobUM8Br/y3fqO50FNTAAcyUK3X2mKZ6ZfKGhm8=; b=QFa8fgKWXRWG7eWY2tOU1/+4z4F2Hpdh4CtttItHeTQTMvp/KfUZ615dFUuqizSSR5 l9yESl4QeyjdVQ2g+ff+1VCcKlgMzwQYLy9VinXbvZFtiGZoeqvhNd/VuuWgkAii/0Rf OU27f85nyGkyH6gQoV4KKv/rpZnqBWAKwLFMemphqXc4w6MK+VhmLpNe/SZmn2kFhzfv JmzGB9JOAjPFCT3J4QQBANEygSsbqR9zNLRM+OWWyvl/XRO8jsDqrGA9p3eMmPECd1tU VdEFCnvaqt/ll60aClprArzurm9BM8X0CR28Fv4DC3xb2jOKWxT2738bNa63e6rbgRSz kXWw== X-Gm-Message-State: ALyK8tKbY8jX0+dxTCYvVfB9sdMWqZI9GwnAoRxnczV97vve+xD6Bbg/tijYMASiXD+k8w== X-Received: by 10.55.154.136 with SMTP id c130mr25392719qke.79.1466002773348; Wed, 15 Jun 2016 07:59:33 -0700 (PDT) Received: from ?IPv6:2620::ce0:101:450b:5ea4:2945:a10a? ([2620:0:ce0:101:450b:5ea4:2945:a10a]) by smtp.gmail.com with ESMTPSA id a28sm1517193qte.6.2016.06.15.07.59.32 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 15 Jun 2016 07:59:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <20160615145821.20248.72879.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2016 09:59:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160615145821.20248.72879.idtracker@ietfa.amsl.com> To: sidr X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-11.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 14:59:36 -0000 This is just a resurrection draft: = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-sidr-rtr-keying-10&url2=3Dd= raft-ietf-sidr-rtr-keying-11 spt > On Jun 15, 2016, at 09:58, 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 of the = IETF. >=20 > Title : Router Keying for BGPsec > Authors : Randy Bush > Sean Turner > Keyur Patel > Filename : draft-ietf-sidr-rtr-keying-11.txt > Pages : 13 > Date : 2016-06-15 >=20 > Abstract: > BGPsec-speaking routers are provisioned with private keys in order = to > sign BGPsec announcements. The corresponding public keys are > published in the global Resource Public Key Infrastructure, enabling > verification of BGPsec messages. This document describes two = methods > of generating the public-private key-pairs: router-driven and > operator-driven. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-11 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rtr-keying-11 >=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 Jun 15 08:27:23 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D272112D68B; Wed, 15 Jun 2016 08:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJhJU_Bw3r8u; Wed, 15 Jun 2016 08:27:21 -0700 (PDT) Received: from deliverix.ams-ix.net (deliverix.ams-ix.net [IPv6:2001:67c:1a8:a101::70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1203212D8EB; Wed, 15 Jun 2016 08:27:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at ams-ix.net Received: from hq-40.office.ams-ix.net (hq-40.office.ams-ix.net [91.200.19.40]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: aristidis) by deliverix.ams-ix.net (Postfix) with ESMTPSA id B27F6412FD; Wed, 15 Jun 2016 17:27:15 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_5FBA58F0-C276-4C2B-A9B6-2B4B81D98A9B"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Aris Lambrianidis In-Reply-To: Date: Thu, 16 Jun 2016 00:27:12 +0900 Message-Id: References: <61339176-792E-4000-BBBD-D17D4962E249@tislabs.com> To: sidr X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sidr chairs , Sandra Murphy Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 15:27:23 -0000 --Apple-Mail=_5FBA58F0-C276-4C2B-A9B6-2B4B81D98A9B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On 15 Jun 2016, at 22:35 , Sandra Murphy wrote: >=20 > Could we get some feedback that this document is ready for = publication? Hi, My 0.02 of your favourite currency denomination: Nits: Line 94: There=92s a typo: =93twp=94 instead of =93two=94 Line 202: Grammatical error: =93it=92s=94 instead of =93its=94 Line 317: Typo: =93see see=94 instead of =93see=94 Content: The middle paragraph of section 6. feels a bit foggy to me: > BGPsec protocol capability negotiation provides for a speaker signing > the data it sends without being able to accept signed data. Thus a > smallish edge router may hold only its own signing key(s), sign = it's > announcements, but not receive signed announcements and therefore = not > need to deal with the majority of the RPKI. Thus such routers CPU, > RAM, and crypto needs are trivial and additional hardware should = not > be needed. Here=92s what my take of the situation described would be: =93Operators might be utilising hardware with limited resources. In such cases, BGPsec protocol capability negotiation allows for a resource = constrained edge router to just hold its own signing key(s) and sign its announcements, = but not receive signed announcements. Therefore, the router would not have to deal with = the majority of the RPKI, potentially saving the need for additional hardware." What is =93smallish" is more relative than, say, =93resource = constrained=94. Perhaps an operator uses a large edge router that is overloaded or just wants to keep their processing overhead low. Kind regards, Aris Lambrianidis --Apple-Mail=_5FBA58F0-C276-4C2B-A9B6-2B4B81D98A9B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXYXPQAAoJEA9B3v9ltRqs3WUQANPZD1H+YUCgwo2zbF7RnjuJ JCBz/1hp1BCDUFwOkbTcru8c88fvz2OnKFCkMvL5L2AL/5ST1OcnL3s9aT9bapFh FjrV3suebbGWx1soh3JQaDWBMOqiQRqMcMziIp0cnvB6ASB5ymBaAacEqILrPGAK nbxu6XRu9jrCCZPvqSEdyKZb+mxHnfMYod+rOg3+NVo7o3UxCoBSuYFY0F0Qmsvc NkJ8C1c7a6imbLRZCcybwcUUsqRvWQZKx5MA63+jfpPD5ZQNWhLVQi97z6NOoy2d aYVuWsosHsXi+tzC7zAO1bjOEmn02P94zWGjAMwNv8ed71IEhDYBkylBlrSiOFqC 60+pbwRnaQ6BEVg6vD5PyMocI83iOead/KvhY/2JNPZLUtyh0yQTXoOFpJXAZA1W ST+0EbBbZbabuZgFXze7BMky4/Yhki1dmU2SiBaldNuSj82Dd0VFuDsbNKTAXCLT KUEzaELQdp+RjJaq4+74tI3ZWSVrgYhZo7vW39zojmdA5azC61Lgbr6IHXl2Bsoh IDhDnWk+mwS/wRU7WE7CGsy2KeEilSgLqUYn3OB6StSl6jBBSOZJfm1w85SXnxaJ EuiBuH+RaEbKv5FhNFhBvr+91L/ZuQZ+l6+r6UOhsD0Rim1nH/uew2Gaq4SljLrx iTmEqkgkJcZZGSMlm1Lw =oYDj -----END PGP SIGNATURE----- --Apple-Mail=_5FBA58F0-C276-4C2B-A9B6-2B4B81D98A9B-- From nobody Wed Jun 15 12:45:18 2016 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 650FD12D911; Wed, 15 Jun 2016 12:45:13 -0700 (PDT) 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.22.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160615194513.26128.54965.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2016 12:45:13 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-12.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 19:45:13 -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 of the IETF. Title : Router Keying for BGPsec Authors : Randy Bush Sean Turner Keyur Patel Filename : draft-ietf-sidr-rtr-keying-12.txt Pages : 13 Date : 2016-06-15 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-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-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 Wed Jun 15 12:48:34 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877FA12DB6B for ; Wed, 15 Jun 2016 12:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrI0seGeZTFj for ; Wed, 15 Jun 2016 12:48:30 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::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 677FD12DB67 for ; Wed, 15 Jun 2016 12:48:27 -0700 (PDT) Received: by mail-qg0-x22f.google.com with SMTP id v76so17907123qgv.3 for ; Wed, 15 Jun 2016 12:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=EOflL+tbR0JOZqxhr4SCw4MdyjOaKLJE+mm9wiYSnv0=; b=RZCcW0I7X3r6KljH+jsbuCcSn5nv20X/ERtD5bN0eEY9sEgo39VQHdWCxyeWzTI77d inoi4woBp/baY3IowtqqoNW+DX3yq+ztWtDaWA2t/VnMNt/F/z1u9A7ryKGYItT636gS j35FawycK+rYnayok6suLMkDuBFwv1xkP+Ih8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=EOflL+tbR0JOZqxhr4SCw4MdyjOaKLJE+mm9wiYSnv0=; b=iE8vppufKZGFxbOQQ+2Jte5kspRiuNeE9Upl5ZMnaAQSJc9hGAZ6pEKW+WxbRPcGCZ J+FgJCimXUmKrU7qAPE58E8CvMwdtx0ZQlcIfX/LWKvE3UWJN0ud04WG+ZcjW4Ru4Nju wsXwsBj8k0UpMmjmj3LdmWUuCQa0X4bU8+P6bludjfLdnWmGt7u6vMKHPoIg3XieBqQm WGUHeQTzVvVlEFHUBPblZVk5BAf62NJXX6nm/4Pw9vVZ2YsK9pBQth9bsBPUzlgGVuoy fQrzpWalmUujL/bWqFUzHINi6JkIRDBiFhKciPGieqnW6gw3MNxuQAV9W8Vam8ifLfjT llew== X-Gm-Message-State: ALyK8tJLTjwwCjlZLf+O12ejg0JdWPlyQeisQ5Fxfb6bjrWZK2WPyv/7wjQzZMeApomSog== X-Received: by 10.140.202.137 with SMTP id x131mr490458qha.27.1466020106478; Wed, 15 Jun 2016 12:48:26 -0700 (PDT) Received: from ?IPv6:2620::ce0:101:1164:8abc:4669:f430? ([2620:0:ce0:101:1164:8abc:4669:f430]) by smtp.gmail.com with ESMTPSA id p13sm8764198qkh.21.2016.06.15.12.48.25 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 15 Jun 2016 12:48:26 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <20160615194513.26128.54965.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2016 14:48:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6FC9A5D3-0DB3-4E7A-A024-B0357A4F94D5@sn3rd.com> References: <20160615194513.26128.54965.idtracker@ietfa.amsl.com> To: sidr X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-12.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 19:48:32 -0000 This draft is intended to address Wes=E2=80=99 comment about providing = pointers to the formats for keys, certs, car requests/responses. = Originally, I proposed that the text go in an appendix, but most of the = formats were already included somewhere in this draft so I put a summary = in s1: = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-sidr-rtr-keying-11&url2=3Dd= raft-ietf-sidr-rtr-keying-12 I=E2=80=99m hoping this answers the mail. spt > On Jun 15, 2016, at 14:45, 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 of the = IETF. >=20 > Title : Router Keying for BGPsec > Authors : Randy Bush > Sean Turner > Keyur Patel > Filename : draft-ietf-sidr-rtr-keying-12.txt > Pages : 13 > Date : 2016-06-15 >=20 > Abstract: > BGPsec-speaking routers are provisioned with private keys in order = to > sign BGPsec announcements. The corresponding public keys are > published in the global Resource Public Key Infrastructure, enabling > verification of BGPsec messages. This document describes two = methods > of generating the public-private key-pairs: router-driven and > operator-driven. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-12 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rtr-keying-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 > _______________________________________________ > 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 Jun 15 13:40:16 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB35B12D94A for ; Wed, 15 Jun 2016 13:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ys-DdTJA0y7P for ; Wed, 15 Jun 2016 13:40:13 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 3356612D947 for ; Wed, 15 Jun 2016 13:40:13 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id p10so35332487qke.3 for ; Wed, 15 Jun 2016 13:40:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=w+d3xPT78dXyQEeYDxC7KEX7wSJKGBMPcdgAo4FGhFQ=; b=AKCXMrbwrA2yODlrjnOc9f7YJYKflgYt9JHLTuA0lBxOMO6zhDLp6mNpVaRCF3WVRu O2jt0NLIqO8m51tbTWApJzEyDFayQcBtv5yj78dphwoEN7G+2drgVIsf8fa2GVuUdwWk nvBSQQNgIRSBY/dUojVVjzsqwb36nxR0PKYEE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=w+d3xPT78dXyQEeYDxC7KEX7wSJKGBMPcdgAo4FGhFQ=; b=mjIAi4iadyyMaFqSe3rUBG3iuzZezvsj9nWsp5uKiyjJVg/XJtYRKEXYsoAQmrAy1e lCDAZyATMVGIPXRjaAbtAEnYrnLPLogmPHpOVQjy91wQwDWW3yMHWeYFrO2diDs5cqSg AhupnliZlwFx8R9o/ZJFq3YHGmqBMiCybgU9/T0A3BAQpoD9BJ2QuPvrGVch1VraHXKv C3+vTByHy9QIxYGXaFk/qm8fkM38MFvuerRZtS/tz+ieaLaShfzcDD37Ns0Dz08clel7 JBpViKvY7ry6Z39TYMfWfq87246M+T1IKHRLijBGKYNgpMQJnXhi7KPbFWjbWcxACdZS A7RQ== X-Gm-Message-State: ALyK8tIlJNsGO+y2+CvFALnIF2QkHb5M/77vbw+8Bmz9OKSEuxb7T0N5vUjRiEW7RSo45w== X-Received: by 10.55.214.194 with SMTP id p63mr780071qkl.130.1466023212343; Wed, 15 Jun 2016 13:40:12 -0700 (PDT) Received: from [5.5.33.238] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id e7sm10011219qgd.45.2016.06.15.13.40.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 15 Jun 2016 13:40:11 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Wed, 15 Jun 2016 15:40:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61339176-792E-4000-BBBD-D17D4962E249@tislabs.com> To: Sandra Murphy X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sidr chairs , sidr Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 20:40:15 -0000 I read it and think it answer the mail. Ship it. spt > On Jun 15, 2016, at 08:35, Sandra Murphy wrote: >=20 > It is a short document. The sentences are not complicated. It reads = quickly. >=20 > There=92s been little/no wg comment on this, certainly no controversy, = over the lifetime of the draft. >=20 > But still. >=20 > Please. Pretty please. Pretty please with sugar on top. Pretty = please with a cherry on top. >=20 > Could we get some feedback that this document is ready for = publication? >=20 > =97Sandy, speaking as one of the wg co-chairs >=20 >=20 > On Jun 8, 2016, at 10:19 PM, Sandra Murphy wrote: >=20 >> No responses at all. >>=20 >> Come on folks. It=92s a short document, like Chris says. >>=20 >> You should be able to read and comment without much trouble. >>=20 >> =97Sandy, speaking as one of the wg co-chairs >>=20 >> On Jun 1, 2016, at 2:52 PM, Chris Morrow = wrote: >>=20 >>>=20 >>> Howdy WG folks, >>> Please take this note as the start of the 2wk WGLC period for: >>> >>>=20 >>> Abstract: >>> "Deployment of the BGPsec architecture and protocols has many >>> operational considerations. This document attempts to collect and >>> present the most critical and universal. It is expected to evolve = as >>> BGPsec is formalized and initially deployed." >>>=20 >>> This is a relatively short document, 8 pages, full of wonder and >>> excitement! I hope that the wg members have read it (it's been = through >>> 8+ revisions) and that they will re-read it quickly, provide = comments >>> as appropriate and ideas on preparedness for publication or not. >>>=20 >>>=20 >>> Thanks for you time and attention to this matter, >>>=20 >>> -Chris >>> co-chair-persona >>>=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 Wed Jun 15 17:36:39 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90FC12DC48; Wed, 15 Jun 2016 17:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6Xgjmzritiy; Wed, 15 Jun 2016 17:36:35 -0700 (PDT) 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 BB4A212DC3F; Wed, 15 Jun 2016 17:36:35 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bDLIO-00016a-9e; Thu, 16 Jun 2016 00:36:32 +0000 Date: Thu, 16 Jun 2016 09:36:29 +0900 Message-ID: From: Randy Bush To: Aris Lambrianidis In-Reply-To: References: <61339176-792E-4000-BBBD-D17D4962E249@tislabs.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=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Sandra Murphy , sidr chairs , sidr Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 00:36:37 -0000 > Line 94: There=E2=80=99s a typo: =E2=80=9Ctwp=E2=80=9D instead of =E2=80= =9Ctwo=E2=80=9D > Line 202: Grammatical error: =E2=80=9Cit=E2=80=99s=E2=80=9D instead of = =E2=80=9Cits=E2=80=9D > Line 317: Typo: =E2=80=9Csee see=E2=80=9D instead of =E2=80=9Csee=E2=80=9D >> BGPsec protocol capability negotiation provides for a speaker signing >> the data it sends without being able to accept signed data. Thus a >> smallish edge router may hold only its own signing key(s), sign it's >> announcements, but not receive signed announcements and therefore not >> need to deal with the majority of the RPKI. Thus such routers CPU, >> RAM, and crypto needs are trivial and additional hardware should not >> be needed. >=20 > =E2=80=9COperators might be utilising hardware with limited resources. In= such > cases, BGPsec protocol capability negotiation allows for a resource > constrained edge router to just hold its own signing key(s) and sign > its announcements, but not receive signed announcements. Therefore, > the router would not have to deal with the majority of the RPKI, > potentially saving the need for additional hardware." eenie meenie. but if it makes you happy, i'll use yours. randy From nobody Wed Jun 15 17:40:24 2016 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 A70F612DC56; Wed, 15 Jun 2016 17:40:22 -0700 (PDT) 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.22.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160616004022.26141.28875.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2016 17:40:22 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-09.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 00:40:23 -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 of the IETF. Title : BGPsec Operational Considerations Author : Randy Bush Filename : draft-ietf-sidr-bgpsec-ops-09.txt Pages : 9 Date : 2016-06-15 Abstract: Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present the most critical and universal. It is expected to evolve as BGPsec is formalized and initially deployed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-ops-09 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 Jun 15 17:43:50 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F3F12DC62 for ; Wed, 15 Jun 2016 17:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZEE92AOulxb for ; Wed, 15 Jun 2016 17:43:48 -0700 (PDT) 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 186D812DC5C for ; Wed, 15 Jun 2016 17:43:48 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bDLPP-00018r-0G for sidr@ietf.org; Thu, 16 Jun 2016 00:43:47 +0000 Date: Thu, 16 Jun 2016 09:43:45 +0900 Message-ID: From: Randy Bush To: sidr wg list In-Reply-To: <20160616004022.26141.28875.idtracker@ietfa.amsl.com> References: <20160616004022.26141.28875.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: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-09.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 00:43:49 -0000 aris's fixes. nest person to find bugs pays the publication fees :) randy From nobody Thu Jun 16 07:00:37 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5464F12D66E for ; Thu, 16 Jun 2016 07:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.626 X-Spam-Level: X-Spam-Status: No, score=-4.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvb09RaNdhbn for ; Thu, 16 Jun 2016 07:00:33 -0700 (PDT) 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 5C15512D66A for ; Thu, 16 Jun 2016 07:00:33 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:54958 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bDXqS-000MQ6-6g for sidr@ietf.org; Thu, 16 Jun 2016 10:00:32 -0400 To: sidr From: Stephen Kent Message-ID: <90d48391-49d1-3f63-80a6-694e49df91e2@bbn.com> Date: Thu, 16 Jun 2016 10:00:33 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------7C912640673D400A3E82586B" Archived-At: Subject: [sidr] draft-ietf-sidr-lta-use-cases-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 14:00:35 -0000 This is a multi-part message in MIME format. --------------7C912640673D400A3E82586B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I read the latest version of this document and have a few comments, some of which I have made before, to no avail ;-). I still find the wording of the three examples in Section 4 to be unnecessarily informal. I’ve provided suggested text for previous versions of this document that probably is still applicable, since the examples do not seem to have changed much. It seems preferable to describe the first motivating case without reference to a specific RIR. (Including a parenthetical note about the historical precedent of a Dutch court order involving RIPE is relevant and might be included.) There is language in the adverse actions document that could be used here to be more formal, less folksy. Since adverse actions is now a Wg document, one might even cite sections of it to support the examples. In the second example, the term “borrowed” is not defined. I think I know what is implied, and it seems inappropriate to possibly condone advertisement of address space allocated to another party, just because that party is not advertising the space to the global Internet. Why not just stick with private address space in this example? The third example is a six-line, run-on sentence, so it’s not easy for a reader to be certain what the example really implies. The Notes section (5) seems to offer an analysis of requirement for potential solutions to address the use cases. Maybe a better section title is warranted. David’s SLURM document describes a mechanism that seems to address the local, customized view requirements described in Section 4. (David says that it addresses the second and maybe third uses cases, but I think he was modest in his assertion.) SLURM could support the first use case, if the community decided on a mechanism to distribute SLURM files in response to a CA being compelled to modify RPKI data. (It would be easy to ad a digital signature to the files, to provide authentication and integrity, but the there’s the little issue of key management and a suitable trust model …) The design accommodates merging of multiple SLURM files, meeting that requirement as stated in this section. Note that SLURM does not require modifying ROAs or GB records. It is a post-processing mechanism using “local” configuration data that overrides the global data acquired from the RPKI. This suggests that some of the comments in Section 5 are not accurate, e.g., ones that allude to the problems posed by not having keys to sign ROAs, etc. Although there is a need to achieve the effect of modifying, creating and/or replacing ROAs and GB records, that effect does not have to involve signatures on the affected data, as suggested in the first and third paragraphs of Section 5. Typos: … to be a formally formally defined set … (repeated word) … 'recipes' should be mergable (mergeable?) The Security Considerations text seems unduly negative. The approach being proposed here is not violating global security, because the results are intended to be local. How about the following wording: The use cases described in Section 4, and the notes for suggested solution approaches in Section 5, are not intended to undermine the security provided by the RPKI. Rather they identify potential obstacles to widespread adoption of the RPKI, and suggest changes that would enable network operators to generate custom “views” of the RPKI for use on a local basis. Providing the ability to create local RPKI views does not adversely affect global routing security. --------------7C912640673D400A3E82586B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I read the latest version of this document and have a few comments, some of which I have made before, to no avail ;-).

 

I still find the wording of the three examples in Section 4 to be unnecessarily informal. I’ve provided suggested text for previous versions of this document that probably is still applicable, since the examples do not seem to have changed much. It seems preferable to describe the first motivating case without reference to a specific RIR. (Including a parenthetical note about the historical precedent of a Dutch court order involving RIPE is relevant and might be included.) There is language in the adverse actions document that could be used here to be more formal, less folksy. Since adverse actions is now a Wg document, one might even cite sections of it to support the examples.  In the second example, the term “borrowed” is not defined. I think I know what is implied, and it seems inappropriate to possibly condone advertisement of address space allocated to another party, just because that party is not advertising the space to the global Internet. Why not just stick with private address space in this example? The third example is a six-line, run-on sentence, so it’s not easy for a reader to be certain what the example really implies.

 

The Notes section (5) seems to offer an analysis of requirement for potential solutions to address the use cases. Maybe a better section title is warranted.

 

David’s SLURM document describes a mechanism that seems to address the local, customized view requirements described in Section 4. (David says that it addresses the second and maybe third uses cases, but I think he was modest in his assertion.) SLURM could support the first use case, if the community decided on a mechanism to distribute SLURM files in response to a CA being compelled to modify RPKI data. (It would be easy to ad a digital signature to the files, to provide authentication and integrity, but the there’s the little issue of key management and a suitable trust model …)  The design accommodates merging of multiple SLURM files, meeting that requirement as stated in this section. Note that SLURM does not require modifying ROAs or GB records. It is a post-processing mechanism using “local” configuration data that overrides the global data acquired from the RPKI. This suggests that some of the comments in Section 5 are not accurate, e.g., ones that allude to the problems posed by not having keys to sign ROAs, etc. Although there is a need to achieve the effect of modifying, creating and/or replacing ROAs and GB records, that effect does not have to involve signatures on the affected data, as suggested in the first and third paragraphs of Section 5.

 

Typos:

     … to be a formally formally defined set … (repeated word)

     … 'recipes' should be mergable (mergeable?)

 

 

 

The Security Considerations text seems unduly negative. The approach being proposed here is not violating global security, because the results are intended to be local. How about the following wording:

 

The use cases described in Section 4, and the notes for suggested solution approaches in Section 5, are not intended to undermine the security provided by the RPKI. Rather they identify potential obstacles to widespread adoption of the RPKI, and suggest changes that would enable network operators to generate custom “views” of the RPKI for use on a local basis. Providing the ability to create local RPKI views does not adversely affect global routing security.

--------------7C912640673D400A3E82586B-- From nobody Thu Jun 16 13:02:09 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F328D12DC1B; Thu, 16 Jun 2016 13:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoqG5qIKD7W9; Thu, 16 Jun 2016 13:02:06 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3E6112DBFF; Thu, 16 Jun 2016 13:02:05 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bDdUJ-00093X-2U>; Thu, 16 Jun 2016 22:02:03 +0200 Received: from x55b23b10.dyn.telefonica.de ([85.178.59.16] helo=mw-PC.fritz.box) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1:AES256-SHA:256) (envelope-from ) id <1bDdUI-002RVF-My>; Thu, 16 Jun 2016 22:02:02 +0200 Date: Thu, 16 Jun 2016 22:00:45 +0200 From: Matthias Waehlisch To: Sandra Murphy In-Reply-To: Message-ID: References: <61339176-792E-4000-BBBD-D17D4962E249@tislabs.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) X-X-Sender: waehl@mail.zedat.fu-berlin.de MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="14682584-17852-1466087669=:6316" Content-ID: X-Originating-IP: 85.178.59.16 Archived-At: Cc: sidr chairs , sidr Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 20:02:08 -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. --14682584-17852-1466087669=:6316 Content-Type: TEXT/PLAIN; CHARSET=UTF-8 Content-Transfer-Encoding: 8BIT Content-ID: Hi, I read v09. No objections only minor comments: line 102: BGPsec need*s* *to* be spoken only line 104: s/by small edge routers/by resource constrained edge routers/ line 119: *see* [RFC4271] line 159: s/..../etc./ lines 200-206 seem redudant to lines 208-213 line 202 s/smallish/resource constrained/ line 215: I don't know where the 84% comes from, I suppose it's just a more or less arbitrary illustration of "vast majority". I would remove the number. line 234: I would be more explicit: "How this is used in routing is up to the operator's local policy, similar to origin validation [RFC6811]." lines 243-250: This paragraph confused me. What about: Operators should be aware that controlling Invalid announcements by local preference might be delusive. Local preference affects only routes to the same set of destinations. Consider having a Valid announcement from neighbor V for prefix 10.0.0.0/16 and an Invalid announcement for 10.0.66.0/24 from neighbor I. If the local policy on a router is configured to accept Invalid announcements, then both routes will be installed, no matter of the value of local preference. (Btw, I suppose that routes to .666 will be discarded anyway ;) line 252: It sounds that only edge routers are allowed to speak BGPsec. I would weaken and say "Validation of signed paths is usually deployed at the eBGP edge." line 292: s/BGPSEC_Path/BGPsec_Path/ lines 288-295: The paragraph seems to mix transparent operation and the question of validation. What about: A route server is usually 'transparent'. To operate transparently in an environment in which the route server connects BGPsec-enabled peers, the route server needs to run BGPsec as well. This implies that the route server creates signatures per client including its own AS in the BGPsec_Path and the target ASes. However, increasing the AS hop count reduces the likelihood of best path selection. See 2.2.2 of [I-D.ietf-idr-ix-bgp-route-server]. To overcome this problem, the route server uses pCount of zero to not increase the effective AS hop count. Furthermore, a BGPsec-aware route server needs to validate the incoming BGPsec_Path but should not drop invalids. In case the client speaks BGPsec the route server should just forward updates to clients which then validate . In case the client does not speak BGPsec, the route server reconstructs the AS_PATH and may signal the validation outcome using communities. line 300: s/Routers should default to this knob disallowing pCount 0./Routers should disallow pCount 0 by default./ line 346: I would rephrase: "Operators should deploy servers that provide time service, such as [RFC5905], to client routers." Cheers matthias On Wed, 15 Jun 2016, Sandra Murphy wrote: > It is a short document. The sentences are not complicated. It reads quickly. > > There’s been little/no wg comment on this, certainly no controversy, over the lifetime of the draft. > > But still. > > Please. Pretty please. Pretty please with sugar on top. Pretty please with a cherry on top. > > Could we get some feedback that this document is ready for publication? > > —Sandy, speaking as one of the wg co-chairs > > > On Jun 8, 2016, at 10:19 PM, Sandra Murphy wrote: > > > No responses at all. > > > > Come on folks. It’s a short document, like Chris says. > > > > You should be able to read and comment without much trouble. > > > > —Sandy, speaking as one of the wg co-chairs > > > > On Jun 1, 2016, at 2:52 PM, Chris Morrow wrote: > > > >> > >> Howdy WG folks, > >> Please take this note as the start of the 2wk WGLC period for: > >> > >> > >> Abstract: > >> "Deployment of the BGPsec architecture and protocols has many > >> operational considerations. This document attempts to collect and > >> present the most critical and universal. It is expected to evolve as > >> BGPsec is formalized and initially deployed." > >> > >> This is a relatively short document, 8 pages, full of wonder and > >> excitement! I hope that the wg members have read it (it's been through > >> 8+ revisions) and that they will re-read it quickly, provide comments > >> as appropriate and ideas on preparedness for publication or not. > >> > >> > >> Thanks for you time and attention to this matter, > >> > >> -Chris > >> co-chair-persona > >> > >> _______________________________________________ > >> sidr mailing list > >> sidr@ietf.org > >> https://www.ietf.org/mailman/listinfo/sidr > > > > -- Dr. Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:m.waehlisch@fu-berlin.de .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.haw-hamburg.de .. http://www.link-lab.net --14682584-17852-1466087669=:6316-- From nobody Mon Jun 20 11:17:11 2016 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 053AE12D629; Mon, 20 Jun 2016 11:17:11 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160620181710.30166.84595.idtracker@ietfa.amsl.com> Date: Mon, 20 Jun 2016 11:17:10 -0700 Archived-At: Cc: sidr@ietf.org, sidr-chairs@ietf.org, The IESG , sandy@tislabs.com, draft-ietf-sidr-rfc6485bis@ietf.org, rfc-editor@rfc-editor.org Subject: [sidr] Protocol Action: 'The Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure' to Proposed Standard (draft-ietf-sidr-rfc6485bis-05.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 18:17:11 -0000 The IESG has approved the following document: - 'The Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure' (draft-ietf-sidr-rfc6485bis-05.txt) as Proposed Standard This document is the product of the Secure Inter-Domain Routing Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/ Technical Summary This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate Revocation Lists (CRLs), Cryptographic Message Syntax (CMS) signed objects and certification requests as well as for the relying parties (RPs) that verify these digital signatures. Working Group Summary The need for the new version of RFC6485 was identified in the working group, and there was wide consensus that it was necessary. Document Quality There are at least four widely used implementations of the RPKI which must implement these cryptographic algorithms. All already support the changes this document makes to RFC6485. The RPKI is in production in all five Regional Internet Registries. Personnel The Document Shepherd is Sandra Murphy. The Responsible Area Director is Alvaro Retana From nobody Tue Jun 21 13:24:12 2016 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 65CE912DDC6; Tue, 21 Jun 2016 13:24:11 -0700 (PDT) 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.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160621202411.17171.27278.idtracker@ietfa.amsl.com> Date: Tue, 21 Jun 2016 13:24:11 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-16.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 20:24:11 -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 of the IETF. Title : BGPsec Protocol Specification Authors : Matthew Lepinski Kotikalapudi Sriram Filename : draft-ietf-sidr-bgpsec-protocol-16.txt Pages : 34 Date : 2016-06-21 Abstract: This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of autonomous systems through which a BGP update message passes. BGPsec is implemented via a new optional non-transitive BGP path attribute that carries a digital signature produced by each autonomous system that propagates the update message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-protocol-16 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 Jun 21 13:40:07 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238FE12D928; Tue, 21 Jun 2016 13:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhytT0JiznWL; Tue, 21 Jun 2016 13:40:04 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0091.outbound.protection.outlook.com [23.103.201.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B40AB12D75F; Tue, 21 Jun 2016 13:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OIT88sGYzwE6WBXsnNzphstdGZHI0Z3XjOEAZqWzpEw=; b=MjrdQ6GF+CrviCGtxCXTWt29fGNaBQa6zKXwspSvBtUVpLfJd7cmxWEw2k89SvJihHCyeT80HPpuDLp7Rfr8DiWo1txLYXRMT1gP3bFtktO9eqCROz0kXqYl+/EYPuz3pE047W8rae8E6A8vSB628IKrnGxqrGP2l+a9iP3aWEc= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0447.namprd09.prod.outlook.com (10.161.252.146) with Microsoft SMTP Server (TLS) id 15.1.523.12; Tue, 21 Jun 2016 20:40:02 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0523.015; Tue, 21 Jun 2016 20:40:02 +0000 From: "Sriram, Kotikalapudi (Fed)" To: sidr wg list Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-16.txt Thread-Index: AQHRy/rjOH4a8/iC8EqP8HWs1+vWc5/0X/sk Date: Tue, 21 Jun 2016 20:40:01 +0000 Message-ID: References: <20160621202411.17171.27278.idtracker@ietfa.amsl.com> In-Reply-To: <20160621202411.17171.27278.idtracker@ietfa.amsl.com> 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.220.134] x-ms-office365-filtering-correlation-id: 95196f10-1c5d-4c1c-1c99-08d39a143846 x-microsoft-exchange-diagnostics: 1; DM2PR09MB0447; 6:jH+rRXVZU21bHWH8iDlkRJ5MNzcYPJXFioStKO0tqy7I+nlulE5Uo281C3pqf/uTFx4GEzgFZ7fqVwRoqO3yg6nXMKjoWF+mrd7pKqjiq61qwMMCkHYiXxh7eH+wkWLtbo2gWuVDEmOnerLTEUPNX9eFBdVzU7qFgEevVEA/aa559V6Eayqb6FDVSwavIMGn8rAYLQAZg6+PsEOCqZ9xpdUC4vhMMcwaAHrygePmbiYoI37tT9o2gWsuKtCPsmWLuOMzkfqixMDrykTC33ZfzeLHmcZ3PVnfVdkaFInsWSTe0Yo54/Kz4tgKoaeOYppsYo5fNiTFWw3OsY+D89q24Q==; 5:bUDkbHCHq5sEGE9AeGv4LHVqisCReBfv99m2Lp1PqccvAw0iDQx4OYyyMrQIMPoy0Eb0L3nvoTdxbHDJ+8YLvxuSAyhC8ZAVOhgi0ImX1vWcBrctkeNVzBZoT3rgI5lyLu4du62Ti0ipIBdKkQfkHg==; 24:BZEKGyFZpzE3hqxkezDY0MT2I/Cb008J/dOjCXQXy4NwX4gxyjxfnOVtC3jJ93c+vS/YF+qqRN20EhP3BPCsxUqhEItPB7xfe7Ea3tvbbBg=; 7:a8x1WtYHFP5hj+QoEBTm71yI5R3/S41pAaxjuF15/sU+/E3NiWhuAQr/U8GWBB6K59VUeEqGrRY8DSZ5JlZkJ2DDoLfh6qEJDxBSQ9fEMNgJEBI5VQ33/bqlsqhBKJ7VJ8lJv9HjIf1zxCtmcsE+fCc0I7VSloBP+e5FtRogJAi3chbvujNjNdAM9qz9F9bQ+1J4XBLGgy53eAYEsdlgsLjKHot7iC0nf5qkLzcLN79K5yeB3/zjTbQaGPQqmuoy x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0447; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:DM2PR09MB0447; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0447; x-forefront-prvs: 098076C36C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(7916002)(189002)(377454003)(377424004)(199003)(86362001)(9686002)(106116001)(105586002)(10400500002)(92566002)(19580405001)(7696003)(5003600100003)(7736002)(19580395003)(5002640100001)(11100500001)(68736007)(189998001)(15975445007)(77096005)(99286002)(76576001)(122556002)(2906002)(97736004)(3280700002)(33656002)(81166006)(102836003)(6116002)(50986999)(586003)(2900100001)(3900700001)(54356999)(3846002)(2950100001)(110136002)(76176999)(81156014)(230783001)(87936001)(3660700001)(4326007)(8936002)(66066001)(101416001)(106356001)(74316001)(8676002)(7846002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0447; H:DM2PR09MB0446.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:99 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: 21 Jun 2016 20:40:01.9811 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0447 Archived-At: Cc: "sidr-chairs@ietf.org" , Matthias Waehlisch Subject: [sidr] Fw: I-D Action: draft-ietf-sidr-bgpsec-protocol-16.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 20:40:06 -0000 This new version incorporates some editorial changes based on comments=20 received from Matthias Waehlisch (shepherd for this document). All the references have been updated. In couple of places, there were repetitions of some sentences. That has als= o been fixed. Sriram ________________________________________ From: sidr on behalf of internet-drafts@ietf.org Sent: Tuesday, June 21, 2016 4:24 PM To: i-d-announce@ietf.org Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-16.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : BGPsec Protocol Specification Authors : Matthew Lepinski Kotikalapudi Sriram Filename : draft-ietf-sidr-bgpsec-protocol-16.txt Pages : 34 Date : 2016-06-21 Abstract: This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of autonomous systems through which a BGP update message passes. BGPsec is implemented via a new optional non-transitive BGP path attribute that carries a digital signature produced by each autonomous system that propagates the update message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-protocol-16 = From nobody Thu Jun 23 07:34:12 2016 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 E933212B071; Thu, 23 Jun 2016 07:34:06 -0700 (PDT) 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.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160623143406.31136.80197.idtracker@ietfa.amsl.com> Date: Thu, 23 Jun 2016 07:34:06 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-17.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 14:34:07 -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 of the IETF. Title : BGPsec Protocol Specification Authors : Matthew Lepinski Kotikalapudi Sriram Filename : draft-ietf-sidr-bgpsec-protocol-17.txt Pages : 34 Date : 2016-06-23 Abstract: This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of autonomous systems through which a BGP update message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries a digital signature produced by each autonomous system that propagates the update message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-protocol-17 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 Jun 23 07:42:10 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0601712D177; Thu, 23 Jun 2016 07:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4GRwK9JciS1; Thu, 23 Jun 2016 07:42:05 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0132.outbound.protection.outlook.com [23.103.200.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5876E126B6D; Thu, 23 Jun 2016 07:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=anfuZ9RD819OlLeZRyCU0qhQLFGqVXJsW4CiTl7biTQ=; b=L57IOaugT+DJb2NoVQbv6RK3JmX3Q8qhT6uWTMcS3SQNKV8sfnKr1f6dPGShgici1k6auH68XPkDHvx5+68g6tY4P4wBZUZql8hJj8Wzq5Fk7M1DZOeJ9ms0HZZ9NM+zV0CzbE3zKHXCdbLD9mcepP9pyeMYc9D+GIe6tPrKL2U= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) with Microsoft SMTP Server (TLS) id 15.1.523.12; Thu, 23 Jun 2016 14:42:03 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0523.019; Thu, 23 Jun 2016 14:42:03 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "John Scudder (jgs@juniper.net)" , Matthias Waehlisch Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-17.txt Thread-Index: AQHRzVxff+MGkbUcrkyj1xhvsb7QTp/3Hipg Date: Thu, 23 Jun 2016 14:42:02 +0000 Message-ID: References: <20160623143406.31136.80197.idtracker@ietfa.amsl.com> In-Reply-To: <20160623143406.31136.80197.idtracker@ietfa.amsl.com> 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.140.122] x-ms-office365-filtering-correlation-id: e0e65619-02b8-4202-77ae-08d39b748a8a x-microsoft-exchange-diagnostics: 1; DM2PR09MB0446; 6:uL+bnOzUHi7FVzo3Q1rmCYmx4m1PfU4mIxTqeU0/SIWkNB0UC49CqSu54TGQpKw1aBE1fLPYDXpSDk/e/jplxKmXd/WqyEOCLVq4lReFtnsjQX5N/oMEbnzeb0KT9u3lRhwOUGYP+cNAakTPEiBclAxgymoCODEste6YMyuBoiTgWLibYLmE3Kdq2bIDYyjrgwSc9Fm1K5BKoAy0iwnVgP7ZKAsVQX6XI9PJ1YueKWpOPCjrOKGkvzTeiRQ8coO8KHFqIAdEtHIpCcamIwRhM67ZVNsyJsJO1DTp4/RzOhKMoKBN/wbMcZuen0sUyHy57JZqxV2amCoC//jaCAbJqZ4RT6K+Cj1G6jakFQjOjUY=; 5:B+aNVpA0vRXm+nggbXpSt1k8zGPZ805wLHkzdzRa5f2bxR2i1Cl45ROd83pfPitWE6/jVzV9uOHW/ICmfuykmlbW0Agrr7UmYa20SJ8jSH7k3Yc0AjqRxf7W2nEJtApH8LJWvdMo2CUnxKNiUgvVBg==; 24:iHvKP5o3eMqKUCQwnI+ZmCZkniyTDywSXsH0ul4zNQ852J8UAQrk0YVuWPt1xg8M5MmGIXCxr3DYEJ39Qj/dLEM8nSY/P0WicvOTFW7sTOU=; 7:y6ptm6/dTGY4ICnhYYo0PfjC+FNwZNYKnB83EDgTM8oR0NtQAAl6fEclJWydQL451ISVR1ROniteewDdf/yrVFSfD2cHJ1PDZW/p9cDXIp0HHgX29er2BzviU6F8aMOd4PH1TsmunEBmy1WopbS+TrylT7ka8kjqA9Fuo93Ppn6G7vIDOjJ4nFnShDDwxdC6EWxqiAJ1RBxSCH/iaBedLgBCiX5ixUI/+GJTUeeKyJGUTOcsCT8qDUZWqsC7S5ny3rxxaGjS4p1NBKJlLVklVA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0446; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:DM2PR09MB0446; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0446; x-forefront-prvs: 098291215C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(66654002)(377454003)(377424004)(13464003)(199003)(189002)(11100500001)(76576001)(9686002)(3660700001)(99286002)(189998001)(6116002)(8666005)(3280700002)(102836003)(586003)(3846002)(101416001)(97736004)(74316001)(19580395003)(19580405001)(87936001)(1941001)(92566002)(122556002)(230783001)(5001770100001)(68736007)(86362001)(2906002)(4326007)(15975445007)(54356999)(77096005)(2950100001)(305945005)(2900100001)(76176999)(33656002)(7846002)(5003600100003)(7696003)(7736002)(10400500002)(50986999)(8676002)(81166006)(81156014)(5002640100001)(8936002)(106356001)(105586002)(66066001)(106116001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0446; H:DM2PR09MB0446.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:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2016 14:42:02.8500 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0446 Archived-At: Cc: "sidr-chairs \(sidr-chairs@ietf.org\)" , "sidr wg list \(sidr@ietf.org\)" Subject: [sidr] FW: I-D Action: draft-ietf-sidr-bgpsec-protocol-17.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 14:42:08 -0000 Many thanks to John Scudder for a very careful review of version-15 of the = draft. He offered an excellent set of editorial comments to the document editors a= nd shepherd. His email came in literally milliseconds after I had uploaded version-16 tw= o days ago. Matthias asked if the editors could make another pass at updating the draft= in accordance with=20 John's comments before he submits his shepherd report. The answer was - yes= . This new version-17 incorporates John's comments (all editorial in nature). Sriram -----Original Message----- From: sidr [mailto:sidr-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Thursday, June 23, 2016 10:34 AM To: i-d-announce@ietf.org Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-17.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : BGPsec Protocol Specification Authors : Matthew Lepinski Kotikalapudi Sriram Filename : draft-ietf-sidr-bgpsec-protocol-17.txt Pages : 34 Date : 2016-06-23 Abstract: This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of autonomous systems through which a BGP update message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries a digital signature produced by each autonomous system that propagates the update message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-protocol-17 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Jun 23 07:52:38 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE7012B063; Thu, 23 Jun 2016 07:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwtwTpo2tAKR; Thu, 23 Jun 2016 07:52:34 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5883128E18; Thu, 23 Jun 2016 07:52:34 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id l125so72864584ywb.2; Thu, 23 Jun 2016 07:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=YTMvQYRSzrUmvRrXQ3u6TnPPSQSnsNmPtj69aJ6fnbQ=; b=khjg9ZIGhtxLMPSJF4LiOy6xZgy/7oACpZGLhiPAdSz+Qa+DOBDqs8hf5jYGANTfCO i2Onhp/JTQ96eewUradyedt+AaKF3mJCUG6TCKYnQoKFWnVmGMoxwG//tITiO8p32LaD xGgskW+AqbR68rvmcLrQgyQr8X/wiKFquLLwzfzzmXYTb4rCqvGH5YdxzjVdWw7UGvIT 33oRWf12nG4rB8RnZCPvDdZqjnvzT0pyU84ZIQrl0iuCD1rvsfIQ4CqhYBDEZN2/G/gq efN5Xsjozl/20fWUNMzoH0xZYUd4lPnZTDuyYHilUkIUMrHA1sN08wiOUlljnMVu8PfM IjIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=YTMvQYRSzrUmvRrXQ3u6TnPPSQSnsNmPtj69aJ6fnbQ=; b=hJ+M2dPJrYR0fuVF+fTR7CTE6f45KcxkFi+AGSeCBwnnnNQnbMsmYV6OO1MeBHFfhD aDRNhRiYX0vmD4OLAOyoP6B+hta1O5aDVaUAS35/kkFWGQZjvVNoXJSngLebcVhpA8MK SbgZ3yIrEKXSG+hHCxOe/1vkI80/442DhT6YIWglhy8VOjbK5WLoAe5685J+e9dk4Mve IkkP8FVD5CAJaY8CVxqdg4B2XhKNjX5KTBt8y8cLM6EDow+41BlOyvNvq6qBUEu95GQp ZCT0Sam5nEIuvMfM5qULnqnhNyQTUSkcdnByvm/ZaL2vvpWiv3sWYiEnnf8KbynMEdSx HDpA== X-Gm-Message-State: ALyK8tJqU9BCxhK5su+PiDhQ9MA/GN/Kn4fj8zB0BZUF5GbBtfGNym9O31ujYb+nBA15nLhSfhF4mVU4R6qz9g== X-Received: by 10.13.207.129 with SMTP id r123mr22056096ywd.274.1466693553879; Thu, 23 Jun 2016 07:52:33 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.13.217.200 with HTTP; Thu, 23 Jun 2016 07:52:33 -0700 (PDT) In-Reply-To: References: <20160623143406.31136.80197.idtracker@ietfa.amsl.com> From: Christopher Morrow Date: Thu, 23 Jun 2016 10:52:33 -0400 X-Google-Sender-Auth: xPxNIK7dVRMyDdCFwxkTax4f5Ok Message-ID: To: "Sriram, Kotikalapudi (Fed)" Content-Type: multipart/alternative; boundary=001a114e688646013d0535f334f9 Archived-At: Cc: "John Scudder \(jgs@juniper.net\)" , "sidr-chairs \(sidr-chairs@ietf.org\)" , Matthias Waehlisch , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] FW: I-D Action: draft-ietf-sidr-bgpsec-protocol-17.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 14:52:37 -0000 --001a114e688646013d0535f334f9 Content-Type: text/plain; charset=UTF-8 thanks! :) On Thu, Jun 23, 2016 at 10:42 AM, Sriram, Kotikalapudi (Fed) < kotikalapudi.sriram@nist.gov> wrote: > Many thanks to John Scudder for a very careful review of version-15 of the > draft. > He offered an excellent set of editorial comments to the document editors > and shepherd. > His email came in literally milliseconds after I had uploaded version-16 > two days ago. > Matthias asked if the editors could make another pass at updating the > draft in accordance with > John's comments before he submits his shepherd report. The answer was - > yes. > This new version-17 incorporates John's comments (all editorial in nature). > > Sriram > > -----Original Message----- > From: sidr [mailto:sidr-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Thursday, June 23, 2016 10:34 AM > To: i-d-announce@ietf.org > Cc: sidr@ietf.org > Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-17.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Secure Inter-Domain Routing of the IETF. > > Title : BGPsec Protocol Specification > Authors : Matthew Lepinski > Kotikalapudi Sriram > Filename : draft-ietf-sidr-bgpsec-protocol-17.txt > Pages : 34 > Date : 2016-06-23 > > Abstract: > This document describes BGPsec, an extension to the Border Gateway > Protocol (BGP) that provides security for the path of autonomous > systems through which a BGP update message passes. BGPsec is > implemented via an optional non-transitive BGP path attribute that > carries a digital signature produced by each autonomous system that > propagates the update message. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-17 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-protocol-17 > > > 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 > --001a114e688646013d0535f334f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
tha= nks! :)=C2=A0

On Thu, Jun 23, 2016 at 10:42 AM, Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram@nist.gov> wrote:
Many thanks to John Scudder for a very careful review of v= ersion-15 of the draft.
He offered an excellent set of editorial comments to the document editors a= nd shepherd.
His email came in literally milliseconds after I had uploaded version-16 tw= o days ago.
Matthias asked if the editors could make another pass at updating the draft= in accordance with
John's comments before he submits his shepherd report. The answer was -= yes.
This new version-17 incorporates John's comments (all editorial in natu= re).

Sriram

-----Original Message-----
From: sidr [mailto:sidr-bounces@ie= tf.org] On Behalf Of intern= et-drafts@ietf.org
Sent: Thursday, June 23, 2016 10:34 AM
To: i-d-announce@ietf.org
Cc: sidr@ietf.org
Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-17.txt


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Secure Inter-Domain Routing of the IETF.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= BGPsec Protocol Specification
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Matt= hew Lepinski
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Kotikalapudi Sriram
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-sidr-bgpsec-protocol-17.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 34
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-06-23

Abstract:
=C2=A0 =C2=A0This document describes BGPsec, an extension to the Border Gat= eway
=C2=A0 =C2=A0Protocol (BGP) that provides security for the path of autonomo= us
=C2=A0 =C2=A0systems through which a BGP update message passes.=C2=A0 BGPse= c is
=C2=A0 =C2=A0implemented via an optional non-transitive BGP path attribute = that
=C2=A0 =C2=A0carries a digital signature produced by each autonomous system= that
=C2=A0 =C2=A0propagates the update message.



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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf= -sidr-bgpsec-protocol-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-ietf-sidr-bgpsec-protocol-17


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

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

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

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

--001a114e688646013d0535f334f9-- From nobody Thu Jun 23 10:07:43 2016 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 949CA12D08E; Thu, 23 Jun 2016 10:07:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160623170741.12596.54395.idtracker@ietfa.amsl.com> Date: Thu, 23 Jun 2016 10:07:41 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-overview-08.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 17:07: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 of the IETF. Title : An Overview of BGPsec Authors : Matt Lepinski Sean Turner Filename : draft-ietf-sidr-bgpsec-overview-08.txt Pages : 10 Date : 2016-06-23 Abstract: This document provides an overview of a security extension to the Border Gateway Protocol (BGP) referred to as BGPsec. BGPsec improves security for BGP routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-overview/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-overview-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-overview-08 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 Jun 23 10:32:58 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACB812D125 for ; Thu, 23 Jun 2016 10:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-PZj3H0srCc for ; Thu, 23 Jun 2016 10:32:54 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1167112D0EC for ; Thu, 23 Jun 2016 10:32:53 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id a186so115786550qkf.0 for ; Thu, 23 Jun 2016 10:32:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=8mgolfFY7CUcRj3FKYoMpZ+durVCE4YRgkqvSF7qims=; b=i0IqubtnjVMQ7F2d+ScenWbOvXiwjXMRjr6vICociNGbyz66oViX8NL0TlTd8A2EVW 1ghW5J8Fd7OAzFqcgkOTqn3jNcOaOGMy74DFW07Fqe7eUWnSfG8b28J7lhdisN/x8beE O80lp36xlhh4pCzmhobueBDkGFubyU3sc4ako= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=8mgolfFY7CUcRj3FKYoMpZ+durVCE4YRgkqvSF7qims=; b=CrZcgjycXO/4X/OzmG40Qn7HSk/e3Och+V4s/7oecGF9k8WNiLJ65L0gejhWjdZwJj XpdQjcTBG86fES8haUAaFqdXVOYTnU95EYkmcU2OHOyIu0BIosBNV1bdlK+5/C/9XHLX rXV3fh9UylgQyfB8+VOy2gWwOb0A2l2sE8+1B0fpRf3Xze5Mdf/6d+qeiPHP5Jxaej35 1c8KPd7dw11+tRxcj/zJ3YeOEhWrIhlfCdr/QjvIhCFv+VJdvJz19uAkHzpq6DUhu/DU pqPN/pR/Bm0Lfzp06h80UMVf9fGKkdfqgpJ1t5sSzmkwPPV1n3XRY0BOb1M6gVnGtUFd oXzg== X-Gm-Message-State: ALyK8tL0Q+B8EZ44MzDsMOoxXMD2PPknNlib/aIuXtkgOb4pNS5EWFU4VqKFkno/8rFLyw== X-Received: by 10.55.215.27 with SMTP id m27mr13914347qki.145.1466703172981; Thu, 23 Jun 2016 10:32:52 -0700 (PDT) Received: from [172.16.0.112] ([96.231.230.69]) by smtp.gmail.com with ESMTPSA id t27sm457073qtc.30.2016.06.23.10.32.51 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 23 Jun 2016 10:32:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <20160623170741.12596.54395.idtracker@ietfa.amsl.com> Date: Thu, 23 Jun 2016 13:32:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <72BB980C-4FCB-4407-AC5E-7101AF6767B1@sn3rd.com> References: <20160623170741.12596.54395.idtracker@ietfa.amsl.com> To: sidr X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-overview-08.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 17:32:57 -0000 We added 3 paragraphs at the end of s3.2 to address Wes=E2=80=99 WGLC = comment. There=E2=80=99s also editorial tweaks as suggested by Wes and Steve K = (off-list) as well as additional editorial tweaks the author team found. We believe this version addresses the known WGLC issues. Obviously, = we=E2=80=99ll have to see if Wes agrees :) spt > On Jun 23, 2016, at 13:07, 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 of the = IETF. >=20 > Title : An Overview of BGPsec > Authors : Matt Lepinski > Sean Turner > Filename : draft-ietf-sidr-bgpsec-overview-08.txt > Pages : 10 > Date : 2016-06-23 >=20 > Abstract: > This document provides an overview of a security extension to the > Border Gateway Protocol (BGP) referred to as BGPsec. BGPsec = improves > security for BGP routing. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-overview/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-overview-08 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-overview-08 >=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 Jun 23 11:00:48 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B549412D508; Thu, 23 Jun 2016 11:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVGsx2dceblf; Thu, 23 Jun 2016 11:00:45 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE08712D125; Thu, 23 Jun 2016 11:00:44 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bG8vi-001WdW-0w>; Thu, 23 Jun 2016 20:00:42 +0200 Received: from x5ce7e2b8.dyn.telefonica.de ([92.231.226.184] helo=mw-PC.fritz.box) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1:AES256-SHA:256) (envelope-from ) id <1bG8vh-002dBY-Lm>; Thu, 23 Jun 2016 20:00:41 +0200 Date: Thu, 23 Jun 2016 19:59:15 +0200 From: Matthias Waehlisch To: Sandra Murphy In-Reply-To: Message-ID: References: <61339176-792E-4000-BBBD-D17D4962E249@tislabs.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) X-X-Sender: waehl@mail.zedat.fu-berlin.de MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="631769442-14006-1466704756=:6316" X-Originating-IP: 92.231.226.184 Archived-At: Cc: sidr chairs , sidr Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 18:00:48 -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. --631769442-14006-1466704756=:6316 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT Hi Randy, one more: Can you please replace "Invalid" by "Not Valid", because this is the notation defined in draft-ietf-sidr-bgpsec-protocol-17. Thanks matthias On Thu, 16 Jun 2016, Matthias Waehlisch wrote: > Hi, > > I read v09. No objections only minor comments: > > line 102: BGPsec need*s* *to* be spoken only > > line 104: s/by small edge routers/by resource constrained edge routers/ > > line 119: *see* [RFC4271] > > line 159: s/..../etc./ > > lines 200-206 seem redudant to lines 208-213 > > line 202 s/smallish/resource constrained/ > > line 215: I don't know where the 84% comes from, I suppose it's just a > more or less arbitrary illustration of "vast majority". I would remove > the number. > > line 234: I would be more explicit: "How this is used in routing is up > to the operator's local policy, similar to origin validation [RFC6811]." > > lines 243-250: This paragraph confused me. What about: > > Operators should be aware that controlling Invalid announcements by > local preference might be delusive. Local preference affects only routes > to the same set of destinations. Consider having a Valid announcement > from neighbor V for prefix 10.0.0.0/16 and an Invalid announcement for > 10.0.66.0/24 from neighbor I. If the local policy on a router is > configured to accept Invalid announcements, then both routes will be > installed, no matter of the value of local preference. > > (Btw, I suppose that routes to .666 will be discarded anyway ;) > > line 252: It sounds that only edge routers are allowed to speak BGPsec. > I would weaken and say "Validation of signed paths is usually deployed > at the eBGP edge." > > line 292: s/BGPSEC_Path/BGPsec_Path/ > > lines 288-295: The paragraph seems to mix transparent operation and the > question of validation. What about: > > A route server is usually 'transparent'. To operate transparently in an > environment in which the route server connects BGPsec-enabled peers, the > route server needs to run BGPsec as well. This implies that the route > server creates signatures per client including its own AS in the > BGPsec_Path and the target ASes. However, increasing the AS hop count > reduces the likelihood of best path selection. See 2.2.2 of > [I-D.ietf-idr-ix-bgp-route-server]. To overcome this problem, the route > server uses pCount of zero to not increase the effective AS hop count. > > Furthermore, a BGPsec-aware route server needs to validate the incoming > BGPsec_Path but should not drop invalids. In case the client speaks > BGPsec the route server should just forward updates to clients which > then validate . In case the client does not speak BGPsec, the route > server reconstructs the AS_PATH and may signal the validation outcome > using communities. > > line 300: s/Routers should default to this knob disallowing pCount 0./Routers should disallow pCount 0 by default./ > > line 346: I would rephrase: "Operators should deploy servers that > provide time service, such as [RFC5905], to client routers." > > > > Cheers > matthias > > On Wed, 15 Jun 2016, Sandra Murphy wrote: > > > It is a short document. The sentences are not complicated. It reads quickly. > > > > There’s been little/no wg comment on this, certainly no controversy, over the lifetime of the draft. > > > > But still. > > > > Please. Pretty please. Pretty please with sugar on top. Pretty please with a cherry on top. > > > > Could we get some feedback that this document is ready for publication? > > > > —Sandy, speaking as one of the wg co-chairs > > > > > > On Jun 8, 2016, at 10:19 PM, Sandra Murphy wrote: > > > > > No responses at all. > > > > > > Come on folks. It’s a short document, like Chris says. > > > > > > You should be able to read and comment without much trouble. > > > > > > —Sandy, speaking as one of the wg co-chairs > > > > > > On Jun 1, 2016, at 2:52 PM, Chris Morrow wrote: > > > > > >> > > >> Howdy WG folks, > > >> Please take this note as the start of the 2wk WGLC period for: > > >> > > >> > > >> Abstract: > > >> "Deployment of the BGPsec architecture and protocols has many > > >> operational considerations. This document attempts to collect and > > >> present the most critical and universal. It is expected to evolve as > > >> BGPsec is formalized and initially deployed." > > >> > > >> This is a relatively short document, 8 pages, full of wonder and > > >> excitement! I hope that the wg members have read it (it's been through > > >> 8+ revisions) and that they will re-read it quickly, provide comments > > >> as appropriate and ideas on preparedness for publication or not. > > >> > > >> > > >> Thanks for you time and attention to this matter, > > >> > > >> -Chris > > >> co-chair-persona > > >> > > >> _______________________________________________ > > >> sidr mailing list > > >> sidr@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sidr > > > > > > > > > > -- Dr. Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:m.waehlisch@fu-berlin.de .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.haw-hamburg.de .. http://www.link-lab.net --631769442-14006-1466704756=:6316-- From nobody Thu Jun 23 13:12:55 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5968312D195; Thu, 23 Jun 2016 13:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34sTGlFwKBDj; Thu, 23 Jun 2016 13:12:53 -0700 (PDT) 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 0B59B12D0C3; Thu, 23 Jun 2016 13:12:53 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bGAzZ-0002Bv-O2; Thu, 23 Jun 2016 20:12:49 +0000 Date: Thu, 23 Jun 2016 22:12:50 +0200 Message-ID: From: Randy Bush To: Matthias Waehlisch In-Reply-To: References: <61339176-792E-4000-BBBD-D17D4962E249@tislabs.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 , sidr chairs , Sandra Murphy Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 20:12:54 -0000 matthias, > one more: Can you please replace "Invalid" by "Not Valid", because > this is the notation defined in draft-ietf-sidr-bgpsec-protocol-17. done. randy From nobody Thu Jun 23 13:32:06 2016 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 75C2C12D639; Thu, 23 Jun 2016 13:32:05 -0700 (PDT) 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.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160623203205.12531.49594.idtracker@ietfa.amsl.com> Date: Thu, 23 Jun 2016 13:32:05 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-10.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 20:32:05 -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 of the IETF. Title : BGPsec Operational Considerations Author : Randy Bush Filename : draft-ietf-sidr-bgpsec-ops-10.txt Pages : 8 Date : 2016-06-23 Abstract: Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present the most critical and universal. It is expected to evolve as BGPsec is formalized and initially deployed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-ops-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 Fri Jun 24 00:34:54 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FE512D9B8; Fri, 24 Jun 2016 00:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R588ntL3ZpyL; Fri, 24 Jun 2016 00:34:52 -0700 (PDT) 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 4836912D9B7; Fri, 24 Jun 2016 00:34:51 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bGLdX-0005Lk-S6; Fri, 24 Jun 2016 07:34:48 +0000 Date: Fri, 24 Jun 2016 09:34:47 +0200 Message-ID: From: Randy Bush To: Matthias Waehlisch In-Reply-To: References: <61339176-792E-4000-BBBD-D17D4962E249@tislabs.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 , sidr chairs , Sandra Murphy Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 07:34:53 -0000 > I read v09. No objections only minor comments: i hacked in many of these changes, though i think most did not really change anything other than an alternate way of saying the same thing. but i just do not want to see this go on an on interminably. and at least you reviewed it. thanks! randy > > line 102: BGPsec need*s* *to* be spoken only > > line 104: s/by small edge routers/by resource constrained edge routers/ > > line 119: *see* [RFC4271] > > line 159: s/..../etc./ > > lines 200-206 seem redudant to lines 208-213 > > line 202 s/smallish/resource constrained/ > > line 215: I don't know where the 84% comes from, I suppose it's just a > more or less arbitrary illustration of "vast majority". I would remove > the number. > > line 234: I would be more explicit: "How this is used in routing is up > to the operator's local policy, similar to origin validation [RFC6811]." > > lines 243-250: This paragraph confused me. What about: > > Operators should be aware that controlling Invalid announcements by > local preference might be delusive. Local preference affects only routes > to the same set of destinations. Consider having a Valid announcement > from neighbor V for prefix 10.0.0.0/16 and an Invalid announcement for > 10.0.66.0/24 from neighbor I. If the local policy on a router is > configured to accept Invalid announcements, then both routes will be > installed, no matter of the value of local preference. > > (Btw, I suppose that routes to .666 will be discarded anyway ;) > > line 252: It sounds that only edge routers are allowed to speak BGPsec. > I would weaken and say "Validation of signed paths is usually deployed > at the eBGP edge." > > line 292: s/BGPSEC_Path/BGPsec_Path/ > > lines 288-295: The paragraph seems to mix transparent operation and the > question of validation. What about: > > A route server is usually 'transparent'. To operate transparently in an > environment in which the route server connects BGPsec-enabled peers, the > route server needs to run BGPsec as well. This implies that the route > server creates signatures per client including its own AS in the > BGPsec_Path and the target ASes. However, increasing the AS hop count > reduces the likelihood of best path selection. See 2.2.2 of > [I-D.ietf-idr-ix-bgp-route-server]. To overcome this problem, the route > server uses pCount of zero to not increase the effective AS hop count. > > Furthermore, a BGPsec-aware route server needs to validate the incoming > BGPsec_Path but should not drop invalids. In case the client speaks > BGPsec the route server should just forward updates to clients which > then validate . In case the client does not speak BGPsec, the route > server reconstructs the AS_PATH and may signal the validation outcome > using communities. > > line 300: s/Routers should default to this knob disallowing pCount 0./Routers should disallow pCount 0 by default./ > > line 346: I would rephrase: "Operators should deploy servers that > provide time service, such as [RFC5905], to client routers." From nobody Fri Jun 24 00:57:13 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58F812D9D3; Fri, 24 Jun 2016 00:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XT11CKqJV_Rr; Fri, 24 Jun 2016 00:57:09 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2CAC12D9D2; Fri, 24 Jun 2016 00:57:08 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bGLz6-0001TD-RW>; Fri, 24 Jun 2016 09:57:04 +0200 Received: from x55b23dce.dyn.telefonica.de ([85.178.61.206] helo=mw-PC.fritz.box) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1:AES256-SHA:256) (envelope-from ) id <1bGLz6-003aRj-DJ>; Fri, 24 Jun 2016 09:57:04 +0200 Date: Fri, 24 Jun 2016 09:55:38 +0200 From: Matthias Waehlisch To: Randy Bush In-Reply-To: Message-ID: References: <61339176-792E-4000-BBBD-D17D4962E249@tislabs.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) X-X-Sender: waehl@mail.zedat.fu-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Originating-IP: 85.178.61.206 Archived-At: Cc: sidr , sidr chairs , Sandra Murphy Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 07:57:11 -0000 Thanks! No further comments from my side. Looing forward to publication. Cheers matthias On Fri, 24 Jun 2016, Randy Bush wrote: > > I read v09. No objections only minor comments: > > i hacked in many of these changes, though i think most did not really > change anything other than an alternate way of saying the same thing. > but i just do not want to see this go on an on interminably. and at > least you reviewed it. thanks! > > randy > > > > > line 102: BGPsec need*s* *to* be spoken only > > > > line 104: s/by small edge routers/by resource constrained edge routers/ > > > > line 119: *see* [RFC4271] > > > > line 159: s/..../etc./ > > > > lines 200-206 seem redudant to lines 208-213 > > > > line 202 s/smallish/resource constrained/ > > > > line 215: I don't know where the 84% comes from, I suppose it's just a > > more or less arbitrary illustration of "vast majority". I would remove > > the number. > > > > line 234: I would be more explicit: "How this is used in routing is up > > to the operator's local policy, similar to origin validation [RFC6811]." > > > > lines 243-250: This paragraph confused me. What about: > > > > Operators should be aware that controlling Invalid announcements by > > local preference might be delusive. Local preference affects only routes > > to the same set of destinations. Consider having a Valid announcement > > from neighbor V for prefix 10.0.0.0/16 and an Invalid announcement for > > 10.0.66.0/24 from neighbor I. If the local policy on a router is > > configured to accept Invalid announcements, then both routes will be > > installed, no matter of the value of local preference. > > > > (Btw, I suppose that routes to .666 will be discarded anyway ;) > > > > line 252: It sounds that only edge routers are allowed to speak BGPsec. > > I would weaken and say "Validation of signed paths is usually deployed > > at the eBGP edge." > > > > line 292: s/BGPSEC_Path/BGPsec_Path/ > > > > lines 288-295: The paragraph seems to mix transparent operation and the > > question of validation. What about: > > > > A route server is usually 'transparent'. To operate transparently in an > > environment in which the route server connects BGPsec-enabled peers, the > > route server needs to run BGPsec as well. This implies that the route > > server creates signatures per client including its own AS in the > > BGPsec_Path and the target ASes. However, increasing the AS hop count > > reduces the likelihood of best path selection. See 2.2.2 of > > [I-D.ietf-idr-ix-bgp-route-server]. To overcome this problem, the route > > server uses pCount of zero to not increase the effective AS hop count. > > > > Furthermore, a BGPsec-aware route server needs to validate the incoming > > BGPsec_Path but should not drop invalids. In case the client speaks > > BGPsec the route server should just forward updates to clients which > > then validate . In case the client does not speak BGPsec, the route > > server reconstructs the AS_PATH and may signal the validation outcome > > using communities. > > > > line 300: s/Routers should default to this knob disallowing pCount 0./Routers should disallow pCount 0 by default./ > > > > line 346: I would rephrase: "Operators should deploy servers that > > provide time service, such as [RFC5905], to client routers." > From nobody Fri Jun 24 06:56:09 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E507112DAB8; Fri, 24 Jun 2016 06:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGXNw15BUu0H; Fri, 24 Jun 2016 06:56:05 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 C8A1712DAD6; Fri, 24 Jun 2016 06:55:57 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id b72so100443712ywa.3; Fri, 24 Jun 2016 06:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=03AmpI8WRV5XOkXee41YUzvweD2S9Azer2kvLL4i2G0=; b=gAvJ6wimRKIz5vSbi8roCCdOyla89kaA/C3kbNWCT9TyoNWocT+2zJEF18cXI7nJTj LImoL4gRkLeE48tXM9QxJeyfkKknE0TaUOx+cB4AuADdw3ubW61BazKbAiDiJpJ3EvSj YqOhLFkSX+gw5AXoAePScW8S3gq2eQbH04jxfgE19z0lHH1b+GAVfx5r2jTKcKXrj+49 mViFe6JU6HoiQXavtrWu9VmjQuRjR2XXOF3n2+cSB8wiGSRts9XRColQVbFW+3CEZ00o OmQaU6T3NghWRdclPVAtViYRw+0Bzd2vsvh522Q+ltwj05xKheBGeVPLu4aiRIFf/Dj9 fxWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=03AmpI8WRV5XOkXee41YUzvweD2S9Azer2kvLL4i2G0=; b=gzHcB3/mbLFqh8lULpqpjyf7OTggxdG53z6OqALKTiXqgXJR/JXQT7bRhlpWCNdhCi n6P9Tq0JEY5Q0k3O83a20EWZGm/dDJXcNya1nCi+FsWtF23bvs2P3UEdAAQgFRkzOG/i 5R/k3Ial7UYWIH1iCIFylZicss41/pm8RYLF9X8YZQ03H30aOjho4j6oQbl0BaYdrauU RsmMgjp3n5LqX1hn8ufYt1e/+gYOWjLu4WJ/68nGb6VbLthF1Eq1bH+AxtHR58tUVjEI k5Dz4bS5i2WViCcK33DOKJz4kT6b8A4ztUNaY/P5CSG6JdVIbV9Ksi3Gbnsss8jt7WCy /VuA== X-Gm-Message-State: ALyK8tJjsgQT85703BfdrpPVVnRbPT0oSPxL6HtDlfwOIDfQKtrYoGGmlZXJnb0MQ5wiMy8mdiNNJ6Zg0YfQFQ== X-Received: by 10.13.207.129 with SMTP id r123mr3119803ywd.274.1466776556963; Fri, 24 Jun 2016 06:55:56 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.129.4.22 with HTTP; Fri, 24 Jun 2016 06:55:56 -0700 (PDT) In-Reply-To: References: From: Christopher Morrow Date: Fri, 24 Jun 2016 09:55:56 -0400 X-Google-Sender-Auth: lGMvDY8zIGs8lhX7e5eGIob2vw8 Message-ID: To: Chris Morrow Content-Type: multipart/alternative; boundary=001a114e6886a48c1d05360687c2 Archived-At: Cc: sidr-ads@ietf.org, "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 13:56:08 -0000 --001a114e6886a48c1d05360687c2 Content-Type: text/plain; charset=UTF-8 Howdy folks, since we got some review and action and re-action... and this all seems quite positive, let's send this along for publication now. (today). thanks! -chris On Wed, Jun 1, 2016 at 2:52 PM, Chris Morrow wrote: > > Howdy WG folks, > Please take this note as the start of the 2wk WGLC period for: > > > Abstract: > "Deployment of the BGPsec architecture and protocols has many > operational considerations. This document attempts to collect and > present the most critical and universal. It is expected to evolve as > BGPsec is formalized and initially deployed." > > This is a relatively short document, 8 pages, full of wonder and > excitement! I hope that the wg members have read it (it's been through > 8+ revisions) and that they will re-read it quickly, provide comments > as appropriate and ideas on preparedness for publication or not. > > > Thanks for you time and attention to this matter, > > -Chris > co-chair-persona > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --001a114e6886a48c1d05360687c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How= dy folks, since we got some review and action and re-action... and this all= seems quite positive, let's send this along for publication now. (toda= y).

<= div class=3D"gmail_default" style=3D"font-size:small">thanks!
-chris

On Wed, Jun 1, 2016 at 2:52= PM, Chris Morrow <morrowc@ops-netman.net> wrote:

Howdy WG folks,
Please take this note as the start of the 2wk WGLC period for:
=C2=A0 <https://tools.ietf.org/html/draf= t-ietf-sidr-bgpsec-ops-07>

Abstract:
=C2=A0 "Deployment of the BGPsec architecture and protocols has many =C2=A0 =C2=A0operational considerations.=C2=A0 This document attempts to co= llect and
=C2=A0 =C2=A0present the most critical and universal.=C2=A0 It is expected = to evolve as
=C2=A0 =C2=A0BGPsec is formalized and initially deployed."

This is a relatively short document, 8 pages, full of wonder and
excitement! I hope that the wg members have read it (it's been through<= br> 8+ revisions) and that they will re-read it quickly, provide comments
as appropriate and ideas on preparedness for publication or not.


Thanks for you time and attention to this matter,

-Chris
co-chair-persona

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

--001a114e6886a48c1d05360687c2-- From nobody Fri Jun 24 09:04:08 2016 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 2445612DC76; Fri, 24 Jun 2016 09:00:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160045.10933.75970.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:45 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] sidr - Requested session has been scheduled for IETF 96 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:00:48 -0000 Dear Sandra Murphy, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. sidr Session 1 (2:30:00) Thursday, Morning Session I 1000-1230 Room Name: Bellevue size: 200 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Secure Inter-Domain Routing Area Name: Routing Area Session Requester: Sandra Murphy Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 90 Conflicts to Avoid: First Priority: opsec idr grow saag rtgwg rtgarea Second Priority: dane i2rs isis spring trill Special Requests: --------------------------------------------------------- From nobody Fri Jun 24 12:05:06 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F6012D539 for ; Fri, 24 Jun 2016 12:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.626 X-Spam-Level: X-Spam-Status: No, score=-4.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-t1xY-TKtWo for ; Fri, 24 Jun 2016 12:05:02 -0700 (PDT) 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 28F0E12B008 for ; Fri, 24 Jun 2016 12:05:02 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:48273 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bGWPV-000ATm-1u for sidr@ietf.org; Fri, 24 Jun 2016 15:05:01 -0400 From: Stephen Kent To: sidr Message-ID: Date: Fri, 24 Jun 2016 15:04:59 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------465133AF4A73FD631517E29E" Archived-At: Subject: [sidr] revising Section 7.2 of RFC 6487 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 19:05:05 -0000 This is a multi-part message in MIME format. --------------465133AF4A73FD631517E29E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I've been discussing details of text in the "validation revisited" I-D with Tim, now that he has become the primary editor. I believe a description of a new validation algorithm will be cleaner and easier to understand if we replace all of section 7.2 in 6487, rather than trying to change just step 6. Most of the text will remain the same, but I've tried to simplify the language where appropriate, to correct a technical error (in describing validity checking), and add text needed to describe the revised alg. I think it makes sense to fix the section while we're updating 6487. Here is my proposed re-write for this section. I've marked the changed text as *bold*, and included *red* comments to explain the rationale for the suggested changes. Steve ------ 7.2 Resource Certification Path Validation *The following algorithm is employed to validate CA and EE resources certificates. It is modeled on the path validation algorithm from [RFC5280], but modified to make use of the IP Address Delegation and AS **Identifier Delegation Extensions from [RFC3779]. (this is a shorter, simpler intro for the section)* *There are two inputs to the validation algorithm:* ** *1.**a trust anchor * ** *2.****a certificate to be validated* *(a description of inputs was present in 5280, in 6.1.1, but omitted in 6487)* *The algorithm is initialized with two new variables for use in the RPKI: Validated Resource Set-IP (VRS-IP) and Validated Resource Set-AS (VRS-AS). These sets are used to track the set of resources (IP address space and AS Numbers) that are considered valid for each CA certificate. The VRS-IP and VRS-AS sets are initially set to the IP Address Delegation and **AS Identifier Delegation values, respectively, from the trust anchor used to perform validation.* *(this new text describes the sets needed to track what resources are present in all certs along a path. I suggest we use two sets, not one, because when we deal with ROAs and router certs they each have only only one of these 3779 extensions present.)* This path validation algorithm verifies, among other things, that aprospective certification path (a sequence of n certificates) satisfies the following conditions: A.for all 'x' in {1, ..., n-1}, the subject of certificate 'x' is the issuer of certificate ('x' + 1); B.certificate '1' is issued by a trust anchor; C.certificate 'n' is the certificate to be validated; and D.for all 'x' in {1, ..., n}, certificate 'x' is valid. *(I changed the enumeration for the bullets above to letters from numbers, because we use numbers to enumerate the steps below. 5280 also used letters vs. numbers when enumerating different aspects of path validation, in some parts of section 6, on which this is based.)* Certificate validation requires verifying that all of the following conditions hold, in addition to the certification path validation criteria specified in Section 6 of [RFC5280]. 1.***The signature of certificate x (x>1) is verified using the * ** *public key of the issuer’s certificate (x-1), using the * ** *signature algorithm specified for that public key (in * ** ***certificate x-1). **(this is a more precise specification of what * * it means to verify the sig of cert x in the path)* 2.*The current time lies within the interval defined by the * ** *NotBefore and NotAfter values in the Validity field of * ** *certificate x. **(this wording matches the names of the fields in a cert, whereas the 6487 text uses terms that do not match cert field names.)* 3.*The Version, Issuer, and Subject fields of certificate x * ** *satisfy the constraints established in Section 4.1-4.7 * ** *of this specification. ***(this text precisely defines constraints that apply to cert fields, vs. extensions. the 6487 text referred to fields in step 3, which does not encompass extensions!)** 4.*Certificate x contains all the extensions that MUST be * ** *present, as defined in Section 4.8 of this specification. * ** *The value(s) for each of these extensions MUST be satisfy* ** *the constraints established for each extension in the* ** *respective sections.**Any extension not identified in Section 4.8 MUST NOT****appear in certificate x. ***(this text describes the constraints imposed on extensions, vs. fields, paralleling #3 above) ** ****** 5.***Certificate x MUST NOT have been revoked, i.e., it * ** *MUST NOT appear on a CRL issued by the CA represented by certificate x-1 (this is a more concise wording of step 5 in 6487)* 6.*Compute the VRS-IP and VRS-AS set values as indicated below:* ** ** ** *If the IP Address Delegation extension is present * ** *in certificate x, compute the intersection of the resources between this extension and the current value of the VRS-IP. * ** ** ** *If the IP Address Delegation extension is absent in certificate x, set the VRS-IP to NULL. * ** ** ** *If the AS Identifier Delegation extension is present * ** *in certificate x, compute the intersection of the resources between this extension and the current value of the VRS-AS * ** ** ** *If the AS Identifier Delegation extension is absent * ** *in certificate x, set the VRS-AS to NULL.* ** ** ** *If x = n (i.e., this is the certificate being validated),* ** *then:* ** *1.**If IP Address Delegation extension is present, it is replaced with the intersection of the values from that extension and the current value of the VRS-IP. * ** *2.**If an AS Identifier Delegation extension is present, it is replaced with the intersection of the values from that extension and the current value of the VRS-IP. * ** *3.*** ** ** ** *If an RP is caching the results of validation, these values* ** *MAY be stored along with the certificate, to facilitate* ** *Incremental validation based on cached results.* ** ** ** *Otherwise, return to step 1 and continue path validation.* *(this is the description of the new rule for "relaxed" validation relative to 3779 extensions. it is more detailed than what Tim proposed, in part because I elected to treat IP address and ASNs as separate sets, consistent with the use of separate 3779 extensions. Tim has indicated that he would like to consider making this step apply only to CA certs, in hopes of not having to update the ROA RFC and the impending router cert RFC. This step can be modified to do that with a few tweaks.)* *These rules allow a CA certificate to contain resources * ** *that are not present in (all of) the certificates along * ** *the path from the trust anchor to the CA certificate. * ** *If none of the resources in the CA certificate are present * ** *in all certificates along the path, no subordinate * ** *certificates could be valid. However, the certificate is not immediately rejected as this may be a transient condition. * ** *Not immediately rejecting the certificate does not result in a security problem because the associated VRS sets accurately reflect the resources validly associated with the * ** *certificate in question.* ** ** ** *The IP address and/or AS number resources contained in an * ** *EE certificate being validated MUST always be **encompassed by all certificates along the path to the **trust anchor used to verify that certificate. The algorithm described above ensures this. * ** ** *(the last two paragraphs provide an explanation for the revised validation alg, and asserts a critical requirement for EE certs) * --------------465133AF4A73FD631517E29E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I've been discussing details of text in the "validation revisited" I-D with Tim, now that he has become the primary editor.  I believe a description of a new validation  algorithm will be cleaner and easier to understand if we replace all of section 7.2 in 6487, rather than trying to change just step 6. Most of the text will remain the same, but I've tried to simplify the language where appropriate, to correct a technical error (in describing validity checking), and add text needed to describe the revised alg. I think it makes sense to fix the section while we're updating 6487.  Here is my proposed re-write for this section. I've marked the changed text as bold, and included red comments to explain the rationale for the suggested changes.

Steve

------

7.2 Resource Certification Path Validation

The following algorithm is employed to validate CA and EE resources certificates. It is modeled on the path validation algorithm from [RFC5280], but modified to make use of the IP Address Delegation and AS Identifier Delegation Extensions from [RFC3779]. (this is a shorter, simpler intro for the section)

 

There are two inputs to the validation algorithm:

1.  a trust anchor

2.  a certificate to be validated

(a description of inputs was present in 5280, in 6.1.1, but omitted in 6487)



The algorithm is initialized with two new variables for use in the RPKI: Validated Resource Set-IP (VRS-IP) and Validated Resource Set-AS (VRS-AS). These sets are used to track the set of resources (IP address space and AS Numbers) that are considered valid for each CA certificate. The VRS-IP and VRS-AS sets are initially set to the IP Address Delegation and AS Identifier Delegation values, respectively, from the trust anchor used to perform validation.

(this new text describes the sets needed to track what resources are present in all certs along a path. I suggest we use two sets, not one, because when we deal with ROAs and router certs they each have only only one of these 3779 extensions present.)


This path validation algorithm verifies, among other things, that a prospective certification path (a sequence of n certificates)

satisfies the following conditions:

 

      A.  for all 'x' in {1, ..., n-1}, the subject of certificate 'x'

          is the issuer of certificate ('x' + 1);

 

      B.  certificate '1' is issued by a trust anchor;

 

      C.  certificate 'n' is the certificate to be validated; and

 

      D.  for all 'x' in {1, ..., n}, certificate 'x' is valid.


(I changed the enumeration for the bullets above to letters from numbers, because we use numbers to enumerate the steps below. 5280 also used letters vs. numbers when enumerating different aspects of path validation, in some parts of section 6, on which this is based.)

 

   Certificate validation requires verifying that all of the following

   conditions hold, in addition to the certification path validation

   criteria specified in Section 6 of [RFC5280].

 

 

1.   The signature of certificate x (x>1) is verified using the

    public key of the issuer’s certificate (x-1), using the

    signature algorithm specified for that public key (in

    certificate x-1). (this is a more precise specification of what

    it means to verify the sig of cert x in the path)

 

2.   The current time lies within the interval defined by the

NotBefore and NotAfter values in the Validity field of

certificate x. (this wording matches the names of the fields in a cert, whereas the 6487 text uses terms that do not match cert field names.)

 

3.   The Version, Issuer, and Subject fields of certificate x

satisfy the constraints established in Section 4.1-4.7

of this specification. (this text precisely defines constraints that apply to cert fields, vs. extensions. the 6487 text referred  to fields in step 3, which does not encompass extensions!)

 

4.   Certificate x contains all the extensions that MUST be

present, as defined in Section 4.8 of this specification.

The value(s) for each of these extensions MUST be satisfy

the constraints established for each extension in the

respective sections. Any extension not identified in Section 4.8 MUST NOT appear in certificate x. (this text describes the constraints imposed on extensions, vs. fields, paralleling #3 above)


 

5.   Certificate x MUST NOT have been revoked, i.e., it

MUST NOT appear on a CRL issued by the CA represented by certificate x-1 (this is a more concise wording of step 5 in 6487)

 

6.   Compute the VRS-IP and VRS-AS set values as indicated below:

 

If the IP Address Delegation extension is present

in certificate x, compute the intersection of the resources between this extension and the current value of the VRS-IP.

 

If the IP Address Delegation extension is absent in certificate x, set the VRS-IP to NULL.

 

If the AS Identifier Delegation extension is present

in certificate x, compute the intersection of the resources between this extension and the current value of the VRS-AS

 

If the AS Identifier Delegation extension is absent

in certificate x, set the VRS-AS to NULL.

 

If x = n (i.e., this is the certificate being validated),

then:

1.  If  IP Address Delegation extension is present, it is replaced with the intersection of the values from that extension and the current value of the VRS-IP.

2.  If an AS Identifier Delegation extension is present, it is replaced with the intersection of the values from that extension and the current value of the VRS-IP.

3.   

 

If an RP is caching the results of validation, these values

MAY be stored along with the certificate, to facilitate

Incremental validation based on cached results.

 

Otherwise, return to step 1 and continue path validation.

(this is the description of the new rule for "relaxed" validation relative to 3779 extensions. it is more detailed than what Tim proposed, in part because I elected to treat IP address and ASNs as separate sets, consistent with the use of separate 3779 extensions. Tim has indicated that he would like to consider making this step apply only to CA certs, in hopes of not having to update the ROA RFC and the impending router cert RFC. This step can be modified to do that with a few tweaks.)

 

 

These rules allow a CA certificate to contain resources

that are not present in (all of) the certificates along

the path from the trust anchor to the CA certificate.

If none of the resources in the CA certificate are present

in all certificates along the path, no subordinate

certificates could be valid. However, the certificate is not immediately rejected as this may be a transient condition.

Not immediately rejecting the certificate does not result in a security problem because the associated VRS sets accurately reflect the resources validly associated with the

certificate in question.

 

The IP address  and/or AS number resources contained in an

EE certificate being validated MUST always be encompassed by all certificates along the path to the trust anchor used to verify that certificate. The algorithm described above ensures this.


(the last two paragraphs provide an explanation for the revised validation alg, and asserts a critical requirement for EE certs)

--------------465133AF4A73FD631517E29E-- From nobody Fri Jun 24 15:42:01 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5827012D5DB for ; Fri, 24 Jun 2016 15:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POnDnHvQ6_7J for ; Fri, 24 Jun 2016 15:41:57 -0700 (PDT) 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 8CF1612D7D0 for ; Fri, 24 Jun 2016 15:41:54 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id E972A28B0046 for ; Fri, 24 Jun 2016 18:41:53 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id B98961F8055; Fri, 24 Jun 2016 18:41:53 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_794EBD94-FE3A-43C4-A66E-EEC353D1FE70"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Sandra Murphy In-Reply-To: <6B1254FF-8A81-4923-BBE6-12536C6001C9@tislabs.com> Date: Fri, 24 Jun 2016 18:39:31 -0400 Message-Id: <64FD7445-B2DD-4780-AD85-401104D12A82@tislabs.com> References: <1CD27ACC-F5D2-4F11-8DD5-2B1F42544406@ripe.net> <6B1254FF-8A81-4923-BBE6-12536C6001C9@tislabs.com> To: Sandra Murphy X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: sidr Subject: Re: [sidr] come on people Re: The question about https certificates and frequency of mft/crl re-issuance X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 22:41:59 -0000 --Apple-Mail=_794EBD94-FE3A-43C4-A66E-EEC353D1FE70 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Look, if no one can summon the energy to respond, Tim has no way to = decide on a change. So the current direction will not change. If you are one of those who were speaking at the mike, please consider = typing at a keyboard. =97Sandy, speaking as one of the wg co-chairs and nag On Jun 8, 2016, at 10:36 PM, Sandra Murphy wrote: > Tim=92s been waiting very patiently for any response to this. >=20 > The discussion was energetic and lots of people commented during the = meeting and Tim promised to bring it to the list. >=20 > Where it looks like it is dying. Those people who were speaking at = this mike so energetically should be responding. >=20 > =97Sandy, speaking as one of the wg co-chairs and nagger >=20 >=20 > On Apr 4, 2016, at 6:51 PM, Tim Bruijnzeels wrote: >=20 >> Hi all, >>=20 >> I promised to take this to list. >>=20 >> So, as presented today, the volume of updates of MFTs and CRLs in the = RIPE NCC repository vs updates of ROAs is about 1000:1. This is a bad = signal -to-noise ratio that causes waste of cycles and bandwidth. >>=20 >> =3D Why this noisy? MITM.. >> We get this, because we use a 'next update time' of 24 hours, but we = actually republish every 8 hours to make sure that we can fix issues = before things go stale. In my understanding we need this because of = man-in-the-middle attacks involving replay or withhold. And rsync is = vulnerable to this (clear text, and no authentication of server). If an = RP is being fed old data, they would notice that something is wrong = within 24 hours. A longer period seems scary.. If this understanding is = wrong I would love to be educated. >>=20 >> =3D Solved by https? >> But assuming this does make sense, I wondered whether RRDP with httpS = offers a way out of this. With RRDP a CA signs a certificate with an = https URL like: https//my.repository.example.org/notification.xml. We = can trust this because it's on a signed certificate. Now, if we can also = exclude mitm, because we can trust the httpS certificate, this would = allow for a much longer period 'next update time'. And in the meantime = the RP would still learn about updates before this, because the = notification.xml is checked regularly and would include any changes = ahead of this. >>=20 >> =3D If so, how to handle https TAs? >> This is a question for RPs. But trusting all https certificates or = all default TAs configured on a system is potentially problematic if the = CA assumes that RPs check against mitm. Some of the many TAs = preconfigured in browsers have been shown to have issues here. >>=20 >> Then again, RP software could be pre-configured with a smaller set of = TAs or even server certificates for know repositories and offer an = interface to operators to change this set. Or RPs could accept new = certificates for repositories, but require operators to confirm changes. = The number of expected repositories isn't great. But there clearly are = scaling issues here. >>=20 >> As I stated on the mic. I don't claim to have the answer. But I think = it's really worth thinking about ways to reduce the signal-to-noise = ratio mentioned. >>=20 >> Tim >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 --Apple-Mail=_794EBD94-FE3A-43C4-A66E-EEC353D1FE70 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 iQIcBAEBCgAGBQJXbbcwAAoJEHplpQeet0IZ1VgQAMB+QkHspb0Qj9IRm0oTL90o yXhpYZ/QI9E2Gg1INgogwvvbc+gdwmHKzMNXYq3Vw2XZVMImzgxwAzboI24L4beY da+JsMSwYYYmJICkeTxZex8JcCGWIm9EKFuzrSyLusRhm2CNRiaNwexXCBLy4TCq Eh+5djTTDbf8IRqmtv4pSFqrS1GfQiJsl3LW5BIr1fsgN3kQXiKL3+Y/NY3ZmZN2 psNz3S22kbe1xWENXvdhj7I4wrUEshPK4ZeJ/oxUTrD7uYOuiF3nlNKOEaXEnYIV 520xfFichZvbbZP42p3kPfATiJt6hs2ljc4yQXy1deQhcqobg9UCx+Bb20ciEbKs eoHsLeJBCcivkmy+oKAja5uzEkytyGwUFPZL8/RWOhwnVGfGO5jClGWSgU1Te5xy lDaCLFXeUvkoYdxFRiS1aNmtiZ07OFMjczzW7o3T0rCzkko75kWGBHAT8Bre4nYn FgvbF7sSkrwUNUR1TB0eofR3JAojdxx4JfG6C2B0n4vZFOmtr06gRjrK0nMk9qOQ awyr3Tmh7mF+t61YTrJxMBhvEa7zu6az06XDfJldKm8r3RDGiaDrHBZzNWZnDB9y WArPio94LEwYlw5Dct4ZwaJwNi0eHMXFI16s+118Q9UZkhpjRsMTIMdm6uAATIBj bEwQV75Kmf9o5R+KFqT/ =lLdi -----END PGP SIGNATURE----- --Apple-Mail=_794EBD94-FE3A-43C4-A66E-EEC353D1FE70-- From nobody Sat Jun 25 00:33:00 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149B112D85C for ; Sat, 25 Jun 2016 00:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdTwQRV1bIUf for ; Sat, 25 Jun 2016 00:32:57 -0700 (PDT) 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 C446F12D5F6 for ; Sat, 25 Jun 2016 00:32:57 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bGi5H-0001sD-JE; Sat, 25 Jun 2016 07:32:55 +0000 Date: Sat, 25 Jun 2016 09:32:56 +0200 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: <64FD7445-B2DD-4780-AD85-401104D12A82@tislabs.com> References: <1CD27ACC-F5D2-4F11-8DD5-2B1F42544406@ripe.net> <6B1254FF-8A81-4923-BBE6-12536C6001C9@tislabs.com> <64FD7445-B2DD-4780-AD85-401104D12A82@tislabs.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] come on people Re: The question about https certificates and frequency of mft/crl re-issuance X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 07:32:59 -0000 > Look, if no one can summon the energy to respond, Tim has no way to > decide on a change. i believe that rob laid this out clearly many months ago. and no, i will not look it up for folk; the epicycles have become too painful. randy From nobody Sat Jun 25 04:35:19 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF7D12D743 for ; Sat, 25 Jun 2016 04:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUhpu7Yv6CdY for ; Sat, 25 Jun 2016 04:35:15 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FADA12D09B for ; Sat, 25 Jun 2016 04:35:14 -0700 (PDT) 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 1bGlrg-000295-HT; Sat, 25 Jun 2016 13:35:10 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-173.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1bGlrg-0002VB-Be; Sat, 25 Jun 2016 13:35:08 +0200 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: Date: Sat, 25 Jun 2016 13:35:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <55B266B3-4D9D-4675-9952-24614CAD83AF@ripe.net> References: <1CD27ACC-F5D2-4F11-8DD5-2B1F42544406@ripe.net> <6B1254FF-8A81-4923-BBE6-12536C6001C9@tislabs.com> <64FD7445-B2DD-4780-AD85-401104D12A82@tislabs.com> To: Randy Bush X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: -------- X-RIPE-Spam-Report: Spam Total Points: -8.1 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07196446a674f9d76cfbd1993928e978e413 Archived-At: Cc: sidr , Sandra Murphy Subject: Re: [sidr] come on people Re: The question about https certificates and frequency of mft/crl re-issuance X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 11:35:17 -0000 Hi, > On 25 Jun 2016, at 09:32, Randy Bush wrote: >=20 >> Look, if no one can summon the energy to respond, Tim has no way to >> decide on a change. >=20 > i believe that rob laid this out clearly many months ago. and no, i > will not look it up for folk; the epicycles have become too painful. I remember the comments, and I have been in contact with Rob and the = other RRDP authors about this. I think we can move forward. It is useful to separate the issues regarding 1) https certificate = verification, and 2) mft/crl re-issuance. On 1) ..=20 In short, we seem to converge on using HTTPS certificate validation to = alert about possible problems, but since RPKI objects are signed and can = be validated even if the source is untrusted, let's always try to get = the latest regardless. We are still working on the text, but the gist of = what we would like to put in a -05 doc before the cut-off date: 4. HTTPS considerations It is RECOMMENDED that Relying Parties and Publication Servers follow the Best Current Practices outlined in [RFC7525] on the use of HTTP over TLS (https). Note that a Man-in-the-Middle (MITM) cannot produce validly signed RPKI data, but they can perform withhold or replay attacks targeting an RP, and keep the RP from learning about changes in the RPKI. Because of this RPs SHOULD do TLS certificate and host name validation when they fetch from an RRDP Publication Server However, such validation issues are often due to configuration errors, or a lack of a common TLS trust anchor. In these cases it would be better that the RP retrieves the signed RPKI data regardless, and performs validation on it. Therefore RPs SHOULD log any TLS certificate or host name validation issues they find, so that an operator can investigate the cause. But the RP SHOULD continue to retrieve the data. The RP MAY choose to log this issue only when fetching the notification update file, but not when it subsequently fetches snapshot or delta files from the same host. Furthermore the RP MAY provide a way for operators to accept untrusted connections for a given host, after the cause has been identified. On 2) CRL/MFT re-issuance First of all. TL;DR on the below: There are operational considerations = that I am happy to share with the group, but if they need to be = documented it's not in the RRDP document. I brought it up because there is some mention of using nextUpdate in = CRLs and MFTs as a protection against replays, and I believe the above = (under 1) provides a better way to detect this. The 24 hours that is now = frequently used is probably way too long anyway to be useful w.r.t. = MITM. So I don't think that changing it to 7 days, or even 1 month makes = much difference in this regard. The discussion that we may want to have is whether nextUpdate should be = used as an indication of when to fetch data again. This keeps coming up. = Steve Kent also suggested having a long default nextUpdate time, and a = shorter one when we know that there are changes. Problem is that the common case for change is unpredictable: a change in = routing requires ROAs or BGPSec certificates to be re-issued, and there = is a desire that RPs learn about this fast. There was a lot of = discussion a few years ago about how fast.. especially Danny McPherson = was vocal on this. There is no clear indication of what is fast enough = though. My impression is that if changes in RPKI can propagate to RPs = (and connected routers) in 10-30 minutes we are in a good spot. Both rcynic and the RIPE NCC RPKI Validator* will re-fetch at regular = intervals regardless of the nextUpdate time. With RRDP I believe we have = the scaling to support refetching every 5-10 mins by any RP that wants = it. But if we do, we need to lower the churn resulting from MFT/CRL = updates. So, I believe that it's safe to lower the nextUpdate frequency to = something in the order of a week, or even a month. Chris Morrow brought = up a concern about keeping the cogs in the machine well greased. I hear = you, but in our case we have over 3000 hosted CAs, if we re-issue = MFTs/CRLs every month we still smear the cogs with a 100 CAs every day. Finally I also had another thought how we can lower the signal-to-noise = ratio of MFT/CRLs vs ROAs in our operations. Currently we re-issue = CRLs/MFTs for our 3000+ CAs every X hours, or whenever there is a change = in ROAs (no BGPSec yet). We optimised to spread the load on our CPU and = HSM. But if we want to optimise for RPs fetching instead, we can change = our implementation to do the background CRLs/MFTs updates in large = batches (say once per X days), and only do the ROA related updates as = soon as they happen. This would allow RPs to aggressively do a cheap = fetch for our update notification file every X minutes, and they would = only find that they need to do an expensive when there are important = changes - and okay once per X days because of the nextUpdates are = re-newed. Anyway, I believe that all of the above is in the space of local = operational considerations. There may be merit in discussing, and we may = find there is merit in documenting as Informational or BCP, but in my = opinion not in the current RRDP document. Cheers Tim *: off-topic.. yes, we need a cool name, ideas welcome ;) >=20 > randy >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Sat Jun 25 07:56:37 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14EE412D106 for ; Sat, 25 Jun 2016 07:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.327 X-Spam-Level: X-Spam-Status: No, score=-108.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TYotoqMg9FK for ; Sat, 25 Jun 2016 07:56:34 -0700 (PDT) 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 D5B5D12D0F8 for ; Sat, 25 Jun 2016 07:56:33 -0700 (PDT) Received: from NXMDA2.org.apnic.net (unknown [IPv6:2001:dd8:9:2::101:249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS; Sun, 26 Jun 2016 00:56:29 +1000 (AEST) Received: from [10.200.196.164] (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 26 Jun 2016 00:56:25 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Geoff Huston In-Reply-To: Date: Sun, 26 Jun 2016 00:56:25 +1000 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: Stephen Kent X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sidr Subject: Re: [sidr] revising Section 7.2 of RFC 6487 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 14:56:36 -0000 FWIW, I like this formulation Steve. Possibly when you refer to "the current value of the VRS-IP=E2=80=9D you = may want to explicitly refer to the VRS-IP of certificate x-1 rather = than =E2=80=9Ccurrent=E2=80=9D. I also wonder if it is worth noting that the enumerated steps outlined = here are intended to be performed =E2=80=9Ctop down=E2=80=9D - i.e. from = a trust anchor to the certificate to be validated.=20 regards, Geoff > On 25 Jun 2016, at 5:04 AM, Stephen Kent wrote: >=20 > I've been discussing details of text in the "validation revisited" I-D = with Tim, now that he has become the primary editor. I believe a = description of a new validation algorithm will be cleaner and easier to = understand if we replace all of section 7.2 in 6487, rather than trying = to change just step 6. Most of the text will remain the same, but I've = tried to simplify the language where appropriate, to correct a technical = error (in describing validity checking), and add text needed to describe = the revised alg. I think it makes sense to fix the section while we're = updating 6487. Here is my proposed re-write for this section. I've = marked the changed text as bold, and included red comments to explain = the rationale for the suggested changes. >=20 > Steve >=20 From nobody Sat Jun 25 11:47:17 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A661B12B046 for ; Sat, 25 Jun 2016 11:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2JNsUD043HY for ; Sat, 25 Jun 2016 11:47:14 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58A8812B030 for ; Sat, 25 Jun 2016 11:47:14 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by adrilankha.hactrn.net (Postfix) with ESMTPS id DD36A22884 for ; Sat, 25 Jun 2016 18:47:13 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 0FECA4067D4E for ; Sat, 25 Jun 2016 14:47:20 -0400 (EDT) Date: Sat, 25 Jun 2016 14:47:20 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <55B266B3-4D9D-4675-9952-24614CAD83AF@ripe.net> References: <1CD27ACC-F5D2-4F11-8DD5-2B1F42544406@ripe.net> <6B1254FF-8A81-4923-BBE6-12536C6001C9@tislabs.com> <64FD7445-B2DD-4780-AD85-401104D12A82@tislabs.com> <55B266B3-4D9D-4675-9952-24614CAD83AF@ripe.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20160625184720.0FECA4067D4E@minas-ithil.hactrn.net> Archived-At: Subject: Re: [sidr] come on people Re: The question about https certificates and frequency of mft/crl re-issuance X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 18:47:16 -0000 I agree with Tim that: a) We appear to be approaching closure on text to nail down the TLS certificate validation behavior of RRDP; and b) That the MFT/CRL re-issuance implications of TLS certificate validation in RRDP (if any) are a separate topic to be discussed (if at all) in a different I-D. I would add that we may not know enough to write the second I-D yet, so I'm not in any particular hurry to start on it. From nobody Mon Jun 27 15:23:04 2016 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 825EF12DA04; Mon, 27 Jun 2016 15:23:02 -0700 (PDT) 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.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160627222302.5289.95721.idtracker@ietfa.amsl.com> Date: Mon, 27 Jun 2016 15:23:02 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-origin-validation-signaling-09.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 22:23: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 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-09.txt Pages : 5 Date : 2016-06-27 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-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-origin-validation-signaling-09 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 Jun 28 10:39:37 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFBD212B012 for ; Tue, 28 Jun 2016 10:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.627 X-Spam-Level: X-Spam-Status: No, score=-4.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2U3i-3dmhXuY for ; Tue, 28 Jun 2016 10:39:33 -0700 (PDT) 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 636C812D10D for ; Tue, 28 Jun 2016 10:39:33 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:42722 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bHwym-000AcH-CK; Tue, 28 Jun 2016 13:39:20 -0400 From: Stephen Kent To: Geoff Huston References: Message-ID: Date: Tue, 28 Jun 2016 13:39:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: sidr Subject: Re: [sidr] revising Section 7.2 of RFC 6487 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 17:39:37 -0000 Geoff, Thanks for reviewing the text. I modified the text to change "current VRS-IP" to be "... the value of the VRS-IP computed for certificate x-1" as per your suggestion. I also made this change for the corresponding VRS-AS text. I don't think we need to add a note about validation being performed "top down" since bullet B already says: "certificate '1' is a trust anchor" Steve > FWIW, I like this formulation Steve. > > Possibly when you refer to "the current value of the VRS-IP” you may want to explicitly refer to the VRS-IP of certificate x-1 rather than “current”. > > I also wonder if it is worth noting that the enumerated steps outlined here are intended to be performed “top down” - i.e. from a trust anchor to the certificate to be validated. > > regards, > > Geoff > From nobody Tue Jun 28 11:19:46 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC8C12D0E4 for ; Tue, 28 Jun 2016 11:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.627 X-Spam-Level: X-Spam-Status: No, score=-4.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id El1fodNhXqMU for ; Tue, 28 Jun 2016 11:19:44 -0700 (PDT) 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 DC95812D0CF for ; Tue, 28 Jun 2016 11:19:43 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:43138 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bHxbq-000Bmr-UC for sidr@ietf.org; Tue, 28 Jun 2016 14:19:43 -0400 To: sidr From: Stephen Kent Message-ID: <0891ea5b-6a68-581d-7f5c-0e6f71fe76d2@bbn.com> Date: Tue, 28 Jun 2016 14:19:41 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sidr] rpki-tree-validation vs. madi-sidr-rp X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 18:19:45 -0000 Although I was not present at the BA SIDR meeting, I did participate remotely for one of the sessions. I recall the discussion of the I-D that tries to collect all of the RP requirements in one place, with cites to the sources of these requirements. It part, I recall folks at the mic arguing that this I-D was redundant relative to the existing WG document on tree validation. I don't think this is an accurate comparison of the two docs, although I agree that there is overlap between them. RPKI tree validation describes how the RIPE RP software works. It includes references to 6 SIDR RFCs to explain why the software performs certain checks. The RP requirements doc cites 11 SIDR RFCs, plus the BGPsec (router cert) profile. Thus it appears that the requirements doc tries to address a wider set of RFCs relevant to RP requirements. More importantly, the requirements doc is generic, while the tree validation doc is expressly a description of one RP implementation. Thus it is an example of how that implementation tries to meet the RP requirements, not a general characterization of RP requirements. Thus I think it appropriate to proceed with both docs. Steve From nobody Tue Jun 28 19:07:57 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA0312D511 for ; Tue, 28 Jun 2016 19:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.327 X-Spam-Level: X-Spam-Status: No, score=-108.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jmq7xIE4WtX for ; Tue, 28 Jun 2016 19:07:53 -0700 (PDT) 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 05ADF12D0D1 for ; Tue, 28 Jun 2016 19:07:52 -0700 (PDT) Received: from NXMDA2.org.apnic.net (unknown [IPv6:2001:dd8:9:2::101:249]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS; Wed, 29 Jun 2016 12:07:52 +1000 (AEST) Received: from [10.0.190.31] (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 29 Jun 2016 12:07:43 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Geoff Huston In-Reply-To: Date: Wed, 29 Jun 2016 12:07:41 +1000 Content-Transfer-Encoding: quoted-printable Message-ID: <4C5B2CAA-58AC-4A12-8C30-03FA4CB42BB2@apnic.net> References: To: Stephen Kent X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sidr Subject: Re: [sidr] revising Section 7.2 of RFC 6487 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 02:07:55 -0000 Thanks! I am now very comfortable with your text on this. Geoff > On 29 Jun 2016, at 3:39 AM, Stephen Kent wrote: >=20 > Geoff, >=20 > Thanks for reviewing the text. >=20 > I modified the text to change "current VRS-IP" to be "... the value of = the VRS-IP computed for certificate x-1" as per your suggestion. I also = made this change for the corresponding VRS-AS text. >=20 > I don't think we need to add a note about validation being performed = "top down" since bullet B already says: "certificate '1' is a trust = anchor" >=20 > Steve >> FWIW, I like this formulation Steve. >>=20 >> Possibly when you refer to "the current value of the VRS-IP=E2=80=9D = you may want to explicitly refer to the VRS-IP of certificate x-1 rather = than =E2=80=9Ccurrent=E2=80=9D. >>=20 >> I also wonder if it is worth noting that the enumerated steps = outlined here are intended to be performed =E2=80=9Ctop down=E2=80=9D - = i.e. from a trust anchor to the certificate to be validated. >>=20 >> regards, >>=20 >> Geoff >>=20 From nobody Wed Jun 29 10:42:20 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C3E12B048 for ; Wed, 29 Jun 2016 10:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuseuIWdHBMp for ; Wed, 29 Jun 2016 10:42:16 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665A612D134 for ; Wed, 29 Jun 2016 10:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1096; q=dns/txt; s=iport; t=1467222136; x=1468431736; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=mfU8HzSOE/0373mwR+qJIiTEd6lmt4Q3v60pCiyfOVY=; b=bBH+eYqR3oZD8jiYYfHR5UHNFPirL3zJFyVErfRrBwVxoaFWOX4frH8L 5JWNvb4O+maFOrsLoj8xMq5PFuiXl93i2JazGMIHXlnjBuquBIgh2GRvg QcOnpjKSFjhCvK8mnuxgYQfZHNjcpvMpiG7ZZXQRFt4TtNu3r/3oLxj3m 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAgDEB3RX/49dJa1agz6BUwa5Q4F7h?= =?us-ascii?q?hgCgTI4FAEBAQEBAQFlJ4RNAQEEOk8CAQg2EDIlAgQBEogwxBcBAQEBAQEBAQI?= =?us-ascii?q?BAQEBAQEBAR+GKIRNihsBBIgYiziFNQGOPY8lkAIBHjaDcG6IP38BAQE?= X-IronPort-AV: E=Sophos;i="5.26,547,1459814400"; d="scan'208";a="118260693" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2016 17:42:15 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u5THgFSd014924 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Jun 2016 17:42:15 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Jun 2016 12:42:15 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Wed, 29 Jun 2016 12:42:15 -0500 From: "Alvaro Retana (aretana)" To: Stephen Kent , "sidr@ietf.org" Thread-Topic: [sidr] AD Review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-07 Thread-Index: AQHRnPRan3y40yRdEkS30+qNsvqUUp/L3N6AgDVVFoA= Date: Wed, 29 Jun 2016 17:42:14 +0000 Message-ID: References: <20160427015828.9591B3EEED13@minas-ithil.hactrn.net> <57471323.6050704@bbn.com> In-Reply-To: <57471323.6050704@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <09B544570B086A41BFF38C98CB29F633@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-07 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 17:42:18 -0000 On 5/26/16, 11:15 AM, "sidr on behalf of Stephen Kent" wrote: [Sorry for the delay...] > >> ... >>> It means that most of the code one needs to deal with version one is >>> the same as the code one needs to deal with version zero. Feel free >>> to suggest better text. >> When I think about protocol compatibility I think about on-the-wire >> behavior and packets, not about the implementation internals. > >I'm not sure what the phrase "on-the-wire behavior" means. Certainly >it is not enough to agree on data formats, i.e., the format of data on >the wire. >There also must be consistent behavior by each end of a >connection/session/ ... >(in terms of externally-visible processing) of the agreed upon data >format. >Otherwise, the behavior of "compatible" implementations may vary >significantly, >and users will not see the versions as "compatible." > >I think your latter comments match my sense of "compatibility", >but I just wanted to make sure we are on the same page. Yes, I think we are. Alvaro. From nobody Wed Jun 29 10:46:02 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECF812D599; Wed, 29 Jun 2016 10:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OeZYrZHlSZ5; Wed, 29 Jun 2016 10:45:50 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 754A212D5A1; Wed, 29 Jun 2016 10:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10814; q=dns/txt; s=iport; t=1467222347; x=1468431947; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xAnFqUFVWqgTq2eCtMCjKDTx3KZ13qJgYHzrqIjBnzs=; b=hv8zrn9r82B/uSx2LQ8RpyCkhTugD6kAsIZaida4lLajBL8avY7niR5B we8L8EHL7femNASVtr9+M0GA1VLb/oi2kNGtho13BMyU6f6q3uSX9kgvQ 8pyif7T04MJ+QRE6N/TU7lSBal9JF3YvubHa8WnWXV4ulALP2grrTNQ/2 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAgAACHRX/4wNJK1agz6BUwa5Q4F7h?= =?us-ascii?q?hgCgTI4FAEBAQEBAQFlJ4RNAQEEOjINEAIBCA4KHhAyJQIEDgUZAogVxBQBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBHoQKgh6ETYobAQSIGIs4hTUBjj2BaY08hlSJLgEeN?= =?us-ascii?q?oIIHIFMbog/fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,547,1459814400"; d="scan'208";a="290920067" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Jun 2016 17:45:46 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u5THjkcb006452 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Jun 2016 17:45:46 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Jun 2016 12:45:45 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Wed, 29 Jun 2016 12:45:45 -0500 From: "Alvaro Retana (aretana)" To: Rob Austein Thread-Topic: AD Review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-07 Thread-Index: AQHRnPRan3y40yRdEkS30+qNsvqUUqABMvIA Date: Wed, 29 Jun 2016 17:45:45 +0000 Message-ID: References: <20160427015828.9591B3EEED13@minas-ithil.hactrn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <6D5510C51FC97F4ABA0EFCE3BFE3198D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sidr-chairs@ietf.org" , "draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-07 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 17:46:01 -0000 Rob: Hi! Did you have comments on this? I'm assuming that we're expecting an updated document at some point, but if we need to discuss more... Thanks! Alvaro. On 5/25/16, 12:09 AM, "Alvaro Retana (aretana)" wrote: >On 4/26/16, 6:58 PM, "Rob Austein" wrote: > >Rob: > >Hi! > >>At Sat, 23 Apr 2016 00:09:07 +0000, Alvaro Retana (aretana) wrote: >>> >>> * Section 1.2. (Changes from RFC 6810): "The protocol >>> described in this document is largely compatible with >>> [RFC6810]." What does "largely compatible" mean? It >>> either is compatible or it isn't. >> >>It means that most of the code one needs to deal with version one is >>the same as the code one needs to deal with version zero. Feel free >>to suggest better text. > >When I think about protocol compatibility I think about on-the-wire >behavior and packets, not about the implementation internals. > >NEW> > The protocol described in this document should allow > an implementation to largely reuse the code developed > for version zero. > >However, I would prefer if the sentence was taken out completely. > > >... >> >>> * This document is marked as obsoleting rfc6810, but it >>> mandates its use in section 7 ("...the cache MUST downgrade >>> to protocol version 0 [RFC6810]..."). There are a couple >>> of paths forward: >>> >>> * It seems to me that this document should simply be >>> called "RPKI to Router Protocol version 1" and not >>> change the status of rfc6810 - we can always declare >>> version 0 historic later. >>> >>> * If you really want to obsolete version 0, then an >>> alternative is to eliminate the normative language when >>> it refers to it... For example, >>> >>> * OLD> "If a cache which supports version 1 receives a >>> query from a router which specifies version 0, the >>> cache MUST downgrade to protocol version 0 [RFC6810] >>> or send a version 1 Error Report PDU with Error Code >>> 4 ("Unsupported Protocol Version") and terminate the >>> connection." >>> >>> * NEW> "If a cache which supports version 1 receives a >>> query from a router which specifies version 0, the >>> cache SHOULD send a version 1 Error Report PDU with >>> Error Code 4 ("Unsupported Protocol Version") and >>> terminate the connection." >> >>The intent is to deprecate version zero, because it lacks features we >>think are important. But version zero is already in the field and we >>have no control over how long it will take to upgrade all existing >>copies. So we have to specify how versions zero and one are intended >>to interoperate. I don't know how to specify that without normative >>references to the older version. > >If you want to deprecate version zero, then Obsoleting rfc6810 is ok. >What is not ok is mandating its use at the same time. > >I'm thinking that we could get away with removing Section 7 completely, >and leaving the downgrade behavior as a "local implementation detail" -- >see below: I'm including comments on Section 7, and an optional new >subsection. > > >Notes_On_7 (my comments with [A]> >7. Protocol Version Negotiation > > A router MUST start each transport connection by issuing either a > Reset Query or a Serial Query. This query will tell the cache which > version of this protocol the router implements. > >[A] This text (above) is in conflict with Section 8.1. (Start or Restart) >which reads: "When a transport connection is first established, the router >MAY send a Reset Query...Alternatively...it MAY start with a Serial >Query..." To match the behavior in Section 7, here's a suggestion for >alternate text (for 8.1). > >OLD> > When a transport connection is first established, the router MAY send > a Reset Query and the cache responds with a data sequence of all data > it contains. > > Alternatively, if the router has significant unexpired data from a > broken session with the same cache, it MAY start with a Serial Query > containing the Session ID from the previous session to ensure the > Serial Numbers are commensurate. > >NEW> > When a transport connection is first established, the router MUST send > a Reset Query and the cache responds with a data sequence of all data > it contains, or a Serial Query. The Serial Query can be used if the > router has significant unexpired data from a broken session with the > same cache; in this case the Serial Query containing the Session ID > from the previous session to ensure the Serial Numbers are >commensurate. > > >[A] BTW, a couple of paragraphs later the text goes back to saying that >"The router MUST send either a Reset Query or a Serial Query..." I think >this text would now be redundant and can be deleted. > > > > > If a cache which supports version 1 receives a query from a router > which specifies version 0, the cache MUST downgrade to protocol > version 0 [RFC6810] or send a version 1 Error Report PDU with Error > Code 4 ("Unsupported Protocol Version") and terminate the connection. > >[A] The behavior of sending the Error PDU is expected if the cache doesn't >support anything else. In the case of the cache supporting both, it can >just directly downgrade (as a local decision) -- see some suggested text >below. > > > If a router which supports version 1 sends a query to a cache which > only supports version 0, one of two things will happen. > > 1. The cache may terminate the connection, perhaps with a version 0 > Error Report PDU. In this case the router MAY retry the > connection using protocol version 0. > > 2. The cache may reply with a version 0 response. In this case the > router MUST either downgrade to version 0 or terminate the > connection. > >[A] In this case again, the behavior of the router can be a local >decision: if a version 0 response (including an Error PDU) is received, >then downgrade -- again, see suggested text below. > > > In any of the downgraded combinations above, the new features of > version 1 will not be available. > > If either party receives a PDU containing an unrecognized Protocol > Version (neither 0 nor 1) during this negotiation, it MUST either > downgrade to a known version or terminate the connection, with an > Error Report PDU unless the received PDU is itself an Error Report > PDU. > >[A] Both versions react the same way to an unrecognized version...so no >need to repeat. > > > The router MUST ignore any Serial Notify PDUs it might receive from > the cache during this initial start-up period, regardless of the > Protocol Version field in the Serial Notify PDU. Since Session ID > and Serial Number values are specific to a particular protocol > version, the values in the notification are not useful to the router. > Even if these values were meaningful, the only effect that processing > the notification would have would be to trigger exactly the same > Reset Query or Serial Query that the router has already sent as part > of the not-yet-complete version negotiation process, so there is > nothing to be gained by processing notifications until version > negotiation completes. > >[A] This text (above) is in conflict with Section 5.2. (Serial Notify), >which reads: "If the router receives a Serial Notify PDU during the >initial start-up period...the router SHOULD simply ignore the Serial >Notify PDU..." Solution: update 5.2 with a "MUST" -- according to the >explanation above, there's no real value in listening (which would not >make it a "SHOULD"). > >[A] Section 5.2 also says: "See Section 7 for details." Instead of that >reference, you can include the additional text above (after the first >sentence). > > > Caches SHOULD NOT send Serial Notify PDUs before version negotiation > completes. Note, however, that routers MUST handle such > notifications (by ignoring them) for backwards compatibility with > caches serving protocol version 0. > >[A] The text above is the corollary of the "MUST ignore" text before it >(you can include it in 5.2)...and the second sentence is really redundant. > > > Once the cache and router have agreed upon a Protocol Version via the > negotiation process above, that version is stable for the life of the > session. See Section 5.1 for a discussion of the interaction between > Protocol Version and Session ID. > > If either party receives a PDU for a different Protocol Version once > the above negotiation completes, that party MUST drop the session; > unless the PDU containing the unexpected Protocol Version was itself > an Error Report PDU, the party dropping the session SHOULD send an > Error Report with an error code of 8 ("Unexpected Protocol Version"). > > >[A] Add the exception (receiving an Error PDU) to the definition of error >code 8 in Section 12. > > > > >Given that it is in fact possible to find older versions in the field, you >might want to include a Section calling that out. My suggestion is to >create a new Section called "Deployment Considerations", include in it the >current Section 11. (Deployment Scenarios) as a sub-section, and add a new >sub-section called "Transition Considerations". > >Suggestion> >11.2 Transition Considerations > > This document Obsoletes version zero of this protocol [RFC6810]. > The intent is to deprecate its use. However, version zero is already > in the field and it is possible that deployments will encounter mixed > scenarios, where a router or cache may only support version zero. It > is also expected that during the transition period a cache or router > that supports version one will also support version zero. The >determination=20 > that a peer (cache or router) only supports version zero is straight > forward: a version zero PDU is received from them. In these cases, it > is up to the local implementation, and policy, whether it might prefer > to use version zero to establish the session, with the understanding > that the new features of version one will not be available. > > > > >One new comment: > >Section 12. (Error Codes) says that "Errors which are considered fatal >SHOULD cause the session to be dropped." When is it ok not to drop the >session? IOW, why not use a "MUST"? > > >Thanks! > >Alvaro. > From nobody Wed Jun 29 22:13:38 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9756112D9CF for ; Wed, 29 Jun 2016 22:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KT7AAaM1sCyT for ; Wed, 29 Jun 2016 22:13:34 -0700 (PDT) Received: from gw1.turbomail.org (gw1.turbomail.org [159.8.83.126]) (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 1755F12D9C6 for ; Wed, 29 Jun 2016 22:13:33 -0700 (PDT) X-TM-DID: e05ed950eee8fc20771b4dbf4ae8d59d Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Declan Ma In-Reply-To: <0891ea5b-6a68-581d-7f5c-0e6f71fe76d2@bbn.com> Date: Thu, 30 Jun 2016 13:09:02 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0891ea5b-6a68-581d-7f5c-0e6f71fe76d2@bbn.com> To: sidr X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [sidr] rpki-tree-validation vs. madi-sidr-rp X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 05:13:37 -0000 Hi, all, Speaking as the co-author of =A1=AERequirements for Resource Public Key = Infrastructure (RPKI) Relying Parties=A1=AF, In addition to the clarification made by Steve, I would like to deliver = a clear message here that this draft is intended to make the RP = requirements well framed, which are segmented with orthogonal = functionalities in different sections. As such, those =A1=AEfunctional components=A1=AF could be crafted and = distributed across the operational timeline of an RP software .=20 We would appreciate your comments on this document. Di ZDNS > =D4=DA 2016=C4=EA6=D4=C229=C8=D5=A3=AC02:19=A3=ACStephen Kent = =D0=B4=B5=C0=A3=BA >=20 > Although I was not present at the BA SIDR meeting, I did participate = remotely for one of the sessions. I recall the discussion of the I-D = that tries to collect all of the RP requirements in one place, with = cites to the sources of these requirements. It part, I recall folks at = the mic arguing that this I-D was redundant relative to the existing WG = document on tree validation. I don't think this is an accurate = comparison of the two docs, although I agree that there is overlap = between them. >=20 > RPKI tree validation describes how the RIPE RP software works. It = includes references to 6 SIDR RFCs to explain why the software performs = certain checks. The RP requirements doc cites 11 SIDR RFCs, plus the = BGPsec (router cert) profile. Thus it appears that the requirements doc = tries to address a wider set of RFCs relevant to RP requirements. More = importantly, the requirements doc is generic, while the tree validation = doc is expressly a description of one RP implementation. Thus it is an = example of how that implementation tries to meet the RP requirements, = not a general characterization of RP requirements. >=20 >=20 > Thus I think it appropriate to proceed with both docs. >=20 > Steve >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Jun 30 07:47:09 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBE412D7CC for ; Thu, 30 Jun 2016 07:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iOhbW1O7Psr for ; Thu, 30 Jun 2016 07:47:02 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67C9312D767 for ; Thu, 30 Jun 2016 07:47:02 -0700 (PDT) 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 1bIdF3-000CIF-HJ; Thu, 30 Jun 2016 16:46:59 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-133.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1bIdF3-0007DR-Cm; Thu, 30 Jun 2016 16:46:57 +0200 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Tim Bruijnzeels In-Reply-To: Date: Thu, 30 Jun 2016 16:46:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0891ea5b-6a68-581d-7f5c-0e6f71fe76d2@bbn.com> To: Declan Ma X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ---------- X-RIPE-Spam-Report: Spam Total Points: -10.7 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.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: 784d7acfe6559f2a0b602ec6519a07190fdaf1fdb4b748bd66432221e8e0986a Archived-At: Cc: sidr Subject: Re: [sidr] rpki-tree-validation vs. madi-sidr-rp X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 14:47:07 -0000 Hi, The point that I was trying to make, but maybe not clearly, is that = rpki-tree-validation is indeed intended as an Informational document = specifically detailing our implementation only, but that the RP = implementers discussed earlier during WG sessions that we might want to = create a generalised RP requirement, or even BCP validation document at = a later stage. So I was just somewhat surprised to see this come up. That being said, we are all busy, so I have no problem with you taking = the lead in the effort to document the generalised RP requirements = instead. Especially as an Informational document referencing the = authoritative docs - as it seems to do. Tim > On 30 Jun 2016, at 07:09, Declan Ma wrote: >=20 > Hi, all, >=20 > Speaking as the co-author of =E2=80=98Requirements for Resource Public = Key Infrastructure (RPKI) Relying Parties=E2=80=99, >=20 > In addition to the clarification made by Steve, I would like to = deliver a clear message here that this draft is intended to make the RP = requirements well framed, which are segmented with orthogonal = functionalities in different sections. >=20 > As such, those =E2=80=98functional components=E2=80=99 could be = crafted and distributed across the operational timeline of an RP = software .=20 >=20 > We would appreciate your comments on this document. >=20 > Di > ZDNS >=20 >=20 >> =E5=9C=A8 2016=E5=B9=B46=E6=9C=8829=E6=97=A5=EF=BC=8C02:19=EF=BC=8CStep= hen Kent =E5=86=99=E9=81=93=EF=BC=9A >>=20 >> Although I was not present at the BA SIDR meeting, I did participate = remotely for one of the sessions. I recall the discussion of the I-D = that tries to collect all of the RP requirements in one place, with = cites to the sources of these requirements. It part, I recall folks at = the mic arguing that this I-D was redundant relative to the existing WG = document on tree validation. I don't think this is an accurate = comparison of the two docs, although I agree that there is overlap = between them. >>=20 >> RPKI tree validation describes how the RIPE RP software works. It = includes references to 6 SIDR RFCs to explain why the software performs = certain checks. The RP requirements doc cites 11 SIDR RFCs, plus the = BGPsec (router cert) profile. Thus it appears that the requirements doc = tries to address a wider set of RFCs relevant to RP requirements. More = importantly, the requirements doc is generic, while the tree validation = doc is expressly a description of one RP implementation. Thus it is an = example of how that implementation tries to meet the RP requirements, = not a general characterization of RP requirements. >>=20 >>=20 >> Thus I think it appropriate to proceed with both docs. >>=20 >> Steve >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Jun 30 14:06:03 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3554312D1A4 for ; Thu, 30 Jun 2016 14:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56LYa8_gToP0 for ; Thu, 30 Jun 2016 14:05:59 -0700 (PDT) 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 B1A4912D182 for ; Thu, 30 Jun 2016 14:05:59 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 10B6F28B0042 for ; Thu, 30 Jun 2016 17:05:59 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id E3CD31F8055; Thu, 30 Jun 2016 17:05:58 -0400 (EDT) From: Sandra Murphy X-Pgp-Agent: GPGMail 2.5.2 Content-Type: multipart/signed; boundary="Apple-Mail=_55959AE3-38CB-4173-9250-BF52978F2530"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 30 Jun 2016 17:05:58 -0400 Message-Id: <88ABAC3C-886C-4402-9A73-09E1D748DE7F@tislabs.com> To: sidr 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] agenda requests for the Berlin IETF 96 meeting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 21:06:01 -0000 --Apple-Mail=_55959AE3-38CB-4173-9250-BF52978F2530 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Anyone who wishes to discuss a topic at the IETF meeting, please send a = message to the list and chairs. =97Sandy, speaking as one of the wg co-chairs --Apple-Mail=_55959AE3-38CB-4173-9250-BF52978F2530 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 iQIcBAEBCgAGBQJXdYm2AAoJEHplpQeet0IZ0MMP/jx9JRKR2h1YcImw4TbNWKee guzufCENYdQGOWcMAfVghDnkX46aPGY6r3YrwINwRwG9nBIxvmG7lkBEgtuJJ9Uj fasDFHTI+oDqbiUsLZVz5KgBer88CnojxV2FxYZEXao/zseCPOPLmQB5LPwMrDVM 8SdJZtXZIPaO+GsUKnp79Ds6vDaoMAfZIFC8yp0zFeNRSElPypkZj/p4mo6Xyl4L L6S6VzmV366RVReAjQ8M2QzqRXGuzNcsTFeIan0JnjAdREZvG3Uq3W5sbjjQD9cG hm4BpiWYpU4pURb3ISTkG/dX14v3VeThsjClcyK/bKXEZnaUKXgJM+teTlpA4DlG fZ03GaWZzMSUWTQIIKmePcSywus16a4x6CLbvFzuUmnUMr4kr1Wz1kE+NeiSRpjI 6Uy3GKlCi0pJQHeyd0Dql6YqW44I/2j8/A3GJWelujKudXXguH38V+9VXw3Jvaua P39FOroJI7IMy9l/KQ3hm0//d6j2KWC9qO1GJlihZc1UpKrWyd7GQ31EnwXcLdC7 7xWfGQINxCl2JYk7UgGa2CuYC2mLeu35dpKPVciVXC37sPpO1GT+0qtwvvogu0Cv hs+UBqhy3018lvPmL1Gvj1xYKqoFIYnUCqhAETFIUx9GuVdVWHpF9yNt8Fz95mFz scy2CFG0/qAtqmi9rp0U =QEW9 -----END PGP SIGNATURE----- --Apple-Mail=_55959AE3-38CB-4173-9250-BF52978F2530-- From nobody Thu Jun 30 14:11:56 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4AC12B064 for ; Thu, 30 Jun 2016 14:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mi26MppmI-wn for ; Thu, 30 Jun 2016 14:11:53 -0700 (PDT) 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 BF2D712B038 for ; Thu, 30 Jun 2016 14:11:53 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 26E3028B0042 for ; Thu, 30 Jun 2016 17:11:53 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 13AA61F8055; Thu, 30 Jun 2016 17:11:53 -0400 (EDT) From: Sandra Murphy X-Pgp-Agent: GPGMail 2.5.2 Content-Type: multipart/signed; boundary="Apple-Mail=_53865940-1985-4E7A-B0B9-C3B0703FC43D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 30 Jun 2016 17:11:52 -0400 Message-Id: <8E32FD39-FD20-455C-8BEC-5752DE9C8531@tislabs.com> To: sidr 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] wglc for draft-ietf-sidr-adverse-actions-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 21:11:55 -0000 --Apple-Mail=_53865940-1985-4E7A-B0B9-C3B0703FC43D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The authors of draft-ietf-sidr-adverse-actions-00, "Adverse Actions by a = Certification Authority (CA) or Repository Manager in the Resource = Public Key Infrastructure (RPKI)=94, believe that the document is ready = for a working group last call. This starts a two week wglc which will end on 14 July 2016. Please review the draft and send comments and your opinion of whether it = is worthy of publication to the list. Remember that support for = publication is needed, and comments can improve quality, so lack of = comments is not sufficient. You can reach the document at = https://tools.ietf.org/html/draft-ietf-sidr-adverse-actions-00 and = https://datatracker.ietf.org/doc/draft-ietf-sidr-adverse-actions. =97Sandy, speaking as one of the wg co-chairs. --Apple-Mail=_53865940-1985-4E7A-B0B9-C3B0703FC43D 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 iQIcBAEBCgAGBQJXdYsYAAoJEHplpQeet0IZVwMP/0kTAUihmty7Ou2qOQWvb7kA H7drheddNvGoYpdB09NwYO9oWefnEzzY3Mq1cSZjs0UZaeOvA9S5K+/6XBUUCvEC nepjV4m3YDEtEkzcdcDpqqyf+eMKcqE3TamkvsW0GGOGTzJJmBLNZNKpS1G6L20+ f/qVnsYlk4KC3pFvpIE0TmnQiIHnrlVEJroftVFWMER5Zyyyje3SU9DTf6hkP7cq xJqwbFQ8REq5pmUb3LqMQ0uh/VPtDxw0XMIHdeRXiCr5iqVGxXQ7/7PUKnb8evmc nnKmGvdLoBL+9BcIxJTRxSdIMG4VP2iE/UykjBoGdXOKHQaCBDs8MJh/eE9vHiMi p/1tGCpyIXvlaazmXr2gJ+syzPzQM8+gWtgSRIfOZBdBHD/1B0KgZeOHzq18Nn4T HMc8N0D5v6Flfn/3wwYTxFPxSMfJE2YXRandH8voFBnGTO5okP7i9JCfXdFoo716 CEX+i092h6V3pvo6sCrFJ0mtKk7l3VmSBOn286SCzGRF/dUvo/9cQfmk8f8qXZxi C8sBAc5RH3/H0Hjw8/3dbqh+C9FKhKOOduRhxbhHRNt6Uuvb//r/+vY11UITXdlT zP7Xd48669KR0mA40oV9tNqI6CZIWeIWfvvk//0Z5+av5MWSfdvvKx4wxBOFCB2X HWh2Rh/Novh9rsoJdP4W =/D0S -----END PGP SIGNATURE----- --Apple-Mail=_53865940-1985-4E7A-B0B9-C3B0703FC43D-- From nobody Thu Jun 30 15:49:04 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E854412B019; Thu, 30 Jun 2016 15:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.328 X-Spam-Level: X-Spam-Status: No, score=-108.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00KakgXSSab6; Thu, 30 Jun 2016 15:49:00 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B46D212B004; Thu, 30 Jun 2016 15:49:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id AA3D1B80C12; Thu, 30 Jun 2016 15:49:00 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160630224900.AA3D1B80C12@rfc-editor.org> Date: Thu, 30 Jun 2016 15:49:00 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, sidr@ietf.org, rfc-editor@rfc-editor.org Subject: [sidr] RFC 7909 on Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 22:49:03 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7909 Title: Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures Author: R. Kisteleki, B. Haberman Status: Standards Track Stream: IETF Date: June 2016 Mailbox: robert@ripe.net, brian@innovationslab.net Pages: 14 Characters: 30493 Updates: RFC 2622, RFC 4012 I-D Tag: draft-ietf-sidr-rpsl-sig-12.txt URL: https://www.rfc-editor.org/info/rfc7909 DOI: http://dx.doi.org/10.17487/RFC7909 This document describes a method that allows parties to electronically sign Routing Policy Specification Language objects and validate such electronic signatures. This allows relying parties to detect accidental or malicious modifications of such objects. It also allows parties who run Internet Routing Registries or similar databases, but do not yet have authentication (based on Routing Policy System Security) of the maintainers of certain objects, to verify that the additions or modifications of such database objects are done by the legitimate holder(s) of the Internet resources mentioned in those objects. This document updates RFCs 2622 and 4012 to add the signature attribute to supported RPSL objects. This document is a product of the Secure Inter-Domain Routing Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Jun 30 16:04:11 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3EB612B019 for ; Thu, 30 Jun 2016 16:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQtzusTjOKBW for ; Thu, 30 Jun 2016 16:04:08 -0700 (PDT) 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 86871127058 for ; Thu, 30 Jun 2016 16:04:08 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bIl07-0006lz-Nk; Thu, 30 Jun 2016 23:04:04 +0000 Date: Fri, 01 Jul 2016 08:04:02 +0900 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: <8E32FD39-FD20-455C-8BEC-5752DE9C8531@tislabs.com> References: <8E32FD39-FD20-455C-8BEC-5752DE9C8531@tislabs.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] wglc for draft-ietf-sidr-adverse-actions-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 23:04:09 -0000 the introduction starts by labeling the basic make before break of a provider switch, a perfectly normal operation, as an adverse action. randy