From nobody Thu Mar 2 00:36:35 2017 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 B485B1299F5; Thu, 2 Mar 2017 00:36:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Shucheng LIU To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148844379373.7077.11693707774114284535.idtracker@ietfa.amsl.com> Date: Thu, 02 Mar 2017 00:36:33 -0800 Archived-At: Cc: draft-ietf-sidr-bgpsec-pki-profiles.all@ietf.org, ietf@ietf.org, sidr@ietf.org Subject: [sidr] Review of draft-ietf-sidr-bgpsec-pki-profiles-21 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, 02 Mar 2017 08:36:34 -0000 Reviewer: Shucheng LIU Review result: Ready Hi all, Sorry that it seems I missed this review request. I guess it's the first one assigned to me via the new review system. I have reviewed draft-ietf-sidr-bgpsec-pki-profiles-21 as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. “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).” My overall view of the document is 'Ready' for publication. ** Technical ** No. ** Editorial ** *Section 4 >BGPsec Router Certificates always include the BGPsec Rouer EKU > value; therefore, request without the value result in certificates > with the value; and, s/Rouer/Router From nobody Thu Mar 2 03:04:31 2017 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 9313C126D74; Thu, 2 Mar 2017 03:04:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148845266459.19507.8615948310870059270.idtracker@ietfa.amsl.com> Date: Thu, 02 Mar 2017 03:04:24 -0800 Archived-At: Cc: draft-ietf-sidr-delta-protocol@ietf.org, sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org Subject: [sidr] Alexey Melnikov's Discuss on draft-ietf-sidr-delta-protocol-07: (with DISCUSS and 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: Thu, 02 Mar 2017 11:04:24 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-sidr-delta-protocol-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I would be happy to ballot Yes on this document, as it is well written and is a useful piece of work. However I have one issue (and a few minor comments) that I would like to DISCUSS before doing so: In Section 5.3 the document says: 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) [RFC2818]. RFC 7525 is referencing RFC 6125 for server hostname validation. Unfortunately this is not detailed enough to perform hostname validation, because reference to RFC 6125 requires specifying answers to every question in section 3 of RFC 6125. (And there is no generic RFC that specifies how this is done for protocols using HTTP.) One example of how this might look like is in Section 9.2 of . For your convenience the relevant text is pasted below: Routers MUST also verify the cache's TLS server certificate, using subjectAltName dNSName identities as described in [RFC6125], to avoid man-in-the-middle attacks. The rules and guidelines defined in [RFC6125] apply here, with the following considerations: Support for DNS-ID identifier type (that is, the dNSName identity in the subjectAltName extension) is REQUIRED in rpki-rtr server and client implementations which use TLS. Certification authorities which issue rpki-rtr server certificates MUST support the DNS-ID identifier type, and the DNS-ID identifier type MUST be present in rpki-rtr server certificates. DNS names in rpki-rtr server certificates SHOULD NOT contain the wildcard character "*". rpki-rtr implementations which use TLS MUST NOT use CN-ID identifiers; a CN field may be present in the server certificate's subject name, but MUST NOT be used for authentication within the rules described in [RFC6125]. The only thing missing from the above is explicit mentioning that SRV-ID and URI-ID are not used. (I think the same should apply to your document.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In 3.2: HTTPS reference is out-of-date. SHA-256 needs a reference. The shepherding write up says that the schema was not validated. Why not? From nobody Thu Mar 2 05:42:18 2017 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 1E3A012944C; Thu, 2 Mar 2017 05:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAX0MKKJ_YhI; Thu, 2 Mar 2017 05:42:14 -0800 (PST) Received: from khatovar.hactrn.net (khatovar.hactrn.net [IPv6:2001:418:8006::30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15A94129548; Thu, 2 Mar 2017 05:42:14 -0800 (PST) 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 khatovar.hactrn.net (Postfix) with ESMTPS id 8A47913992; Thu, 2 Mar 2017 13:42:12 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id CD9354BA238; Thu, 2 Mar 2017 08:42:12 -0500 (EST) Date: Thu, 02 Mar 2017 08:42:12 -0500 From: Rob Austein To: Alexey Melnikov In-Reply-To: <148845266459.19507.8615948310870059270.idtracker@ietfa.amsl.com> References: <148845266459.19507.8615948310870059270.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170302134212.CD9354BA238@minas-ithil.hactrn.net> Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, draft-ietf-sidr-delta-protocol@ietf.org Subject: Re: [sidr] Alexey Melnikov's Discuss on draft-ietf-sidr-delta-protocol-07: (with DISCUSS and COMMENT) 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 Mar 2017 13:42:15 -0000 At Thu, 02 Mar 2017 03:04:24 -0800, Alexey Melnikov wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The shepherding write up says that the schema was not validated. Why not? Er, the write-up is incorrect on this point. The schema passes validation with trang and xmllint. I'm not the lead author on this I-D, so this isn't one of my automated-schema-validation-before-running-xml2rfc hacks, but I just extracted the current schema from the -07 text and ran it through trang and xmllint by hand, no problems reported. From nobody Thu Mar 2 05:47:40 2017 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 0224712997D; Thu, 2 Mar 2017 05:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=HgGA0RHZ; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=GdxIO+4U Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPsLbrcDbB4w; Thu, 2 Mar 2017 05:47:38 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E4B31298D2; Thu, 2 Mar 2017 05:47:38 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 7AF6E205A7; Thu, 2 Mar 2017 08:47:37 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Thu, 02 Mar 2017 08:47:37 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=N4/VHHDE2d67j+b bNjz0l5SSTbA=; b=HgGA0RHZc/obsqzNO4ZNHSh8zUPHGcJFQ2DTbOtnYQz7kFS MXlCeDEaVM1IS5n4zK77GJaY6Ca7SgWH4KQqb5gWh8Zb0wLY3Xi2ibOJGdMs9zgA RHma88uszN+VKyjmxk+thOujdkeXpSQnQXg7ioqPlXUvo+EzR8ZW4Poe3Fms= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=N4/VHHDE2d67j+bbNjz0l5SSTbA=; b=GdxIO+4Ub/3Yh2iQhvjM iO66eCTFVDmWIO7YlZePT2Add3+jX481RVp0nohpHH7CDUxLCtEaW5fcV6S2p593 x7kpYAkAxLh9UGZPRTXK3p5OsqckdcJpmMuSLBWYVUj9yxW7hvl69GZhOtQo8Wk7 Wh1x4lis/A5ZN1OXpYhNO+w= X-ME-Sender: X-Sasl-enc: o9SS4ldxB+jIe2H2YYSmlNoSco7QE5iuWQc5/TBGB+80 1488462457 Received: from [172.20.1.74] (unknown [62.232.206.186]) by mail.messagingengine.com (Postfix) with ESMTPA id 35B697E1FF; Thu, 2 Mar 2017 08:47:37 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPad Mail (14A456) In-Reply-To: <20170302134212.CD9354BA238@minas-ithil.hactrn.net> Date: Thu, 2 Mar 2017 14:06:53 +0000 Content-Transfer-Encoding: 7bit Message-Id: <6D0E68CD-C5E9-429E-A06D-F652BC05E9A4@fastmail.fm> References: <148845266459.19507.8615948310870059270.idtracker@ietfa.amsl.com> <20170302134212.CD9354BA238@minas-ithil.hactrn.net> To: Rob Austein Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, draft-ietf-sidr-delta-protocol@ietf.org Subject: Re: [sidr] Alexey Melnikov's Discuss on draft-ietf-sidr-delta-protocol-07: (with DISCUSS and COMMENT) 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 Mar 2017 13:47:39 -0000 Hi Rob, > On 2 Mar 2017, at 13:42, Rob Austein wrote: > > At Thu, 02 Mar 2017 03:04:24 -0800, Alexey Melnikov wrote: >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> The shepherding write up says that the schema was not validated. Why not? > > Er, the write-up is incorrect on this point. The schema passes > validation with trang and xmllint. > > I'm not the lead author on this I-D, so this isn't one of my > automated-schema-validation-before-running-xml2rfc hacks, but I just > extracted the current schema from the -07 text and ran it through > trang and xmllint by hand, no problems reported. Good to know! The write-up should be corrected on this point. Thank you, Alexey From nobody Thu Mar 2 06:24:18 2017 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 E0EC51295F2; Thu, 2 Mar 2017 06:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBSG3eZx9XiL; Thu, 2 Mar 2017 06:24:11 -0800 (PST) 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 8E3451295E6; Thu, 2 Mar 2017 06:24:11 -0800 (PST) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id 14E403FD51; Thu, 2 Mar 2017 14:24:10 +0000 (UTC) Received: from donkey.her.corp.google.com.ops-netman.net (unknown [104.132.12.94]) (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 BD404463D359; Thu, 2 Mar 2017 14:24:09 +0000 (UTC) Date: Thu, 02 Mar 2017 09:24:08 -0500 Message-ID: From: Chris Morrow To: Alexey Melnikov In-Reply-To: <6D0E68CD-C5E9-429E-A06D-F652BC05E9A4@fastmail.fm> References: <148845266459.19507.8615948310870059270.idtracker@ietfa.amsl.com> <20170302134212.CD9354BA238@minas-ithil.hactrn.net> <6D0E68CD-C5E9-429E-A06D-F652BC05E9A4@fastmail.fm> 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: Cc: Rob Austein , Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, draft-ietf-sidr-delta-protocol@ietf.org Subject: Re: [sidr] Alexey Melnikov's Discuss on draft-ietf-sidr-delta-protocol-07: (with DISCUSS and COMMENT) 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 Mar 2017 14:24:13 -0000 At Thu, 2 Mar 2017 14:06:53 +0000, Alexey Melnikov wrote: > > Hi Rob, > > > On 2 Mar 2017, at 13:42, Rob Austein wrote: > > > > At Thu, 02 Mar 2017 03:04:24 -0800, Alexey Melnikov wrote: > >> > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> The shepherding write up says that the schema was not validated. Why not? > > > > Er, the write-up is incorrect on this point. The schema passes > > validation with trang and xmllint. > > > > I'm not the lead author on this I-D, so this isn't one of my > > automated-schema-validation-before-running-xml2rfc hacks, but I just > > extracted the current schema from the -07 text and ran it through > > trang and xmllint by hand, no problems reported. > > Good to know! The write-up should be corrected on this point. sorry, fixed. From nobody Thu Mar 2 16:33:01 2017 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 484B4129667; Thu, 2 Mar 2017 16:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2kUoKTiDx09; Thu, 2 Mar 2017 16:32:59 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70E34129607; Thu, 2 Mar 2017 16:32:56 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cjb9S-0001ca-13; Fri, 03 Mar 2017 00:32:54 +0000 Date: Fri, 03 Mar 2017 09:32:51 +0900 Message-ID: From: Randy Bush To: "Jakob Heitz (jheitz)" In-Reply-To: <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com> References: <148414831932.11019.14685466226406323027.idtracker@ietfa.amsl.com> <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: "draft-ietf-sidr-origin-validation-signaling@ietf.org" , "sandy@tislabs.com" , "sidr-chairs@ietf.org" , The IESG , The IESG , "sidr@ietf.org" , IETF-Announce , "rfc-editor@rfc-editor.org" Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-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: Fri, 03 Mar 2017 00:33:00 -0000 > What happens if a BGP speaker validates a route in its own RPKI > database and finds it to be either Valid or Invalid (not NotFound) and > also receives the extended community that specifies a different > validation state? > > I don't see that condition covered in the draft. > I would say to ignore the extended community. agree From nobody Fri Mar 3 11:35:53 2017 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 E52471295B8; Fri, 3 Mar 2017 11:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlyaHajH8YVR; Fri, 3 Mar 2017 11:35:49 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0118.outbound.protection.outlook.com [23.103.200.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F6C112949B; Fri, 3 Mar 2017 11:35:49 -0800 (PST) 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=xf7eYPkN1H3aCDLVa+YPBh3xOmFR0Bb1BfqFrN45ib0=; b=wrsZsfhgGZSu2E2NK4X6yWGS7iiXsLMcOb+bxZsjJr8ELTTzsTUY5z7TaHDE5kgHvzz//JiDDI4kmhnROd9i2Ust0zzp5ScAmqCXftXLQ3416daXVLyrziltENaps4DpITmRLivwMGLUrS419x2gUJSUvo4tJtXiS6QgeJvWxnw= Received: from BN6PR09MB1426.namprd09.prod.outlook.com (10.173.202.14) by BN6PR09MB1428.namprd09.prod.outlook.com (10.173.202.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Fri, 3 Mar 2017 19:35:48 +0000 Received: from BN6PR09MB1426.namprd09.prod.outlook.com ([10.173.202.14]) by BN6PR09MB1426.namprd09.prod.outlook.com ([10.173.202.14]) with mapi id 15.01.0919.022; Fri, 3 Mar 2017 19:35:47 +0000 From: "Montgomery, Douglas (Fed)" To: "Alvaro Retana (aretana)" , "Jakob Heitz (jheitz)" , "draft-ietf-sidr-origin-validation-signaling@ietf.org" Thread-Topic: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt) Thread-Index: AQHSbB8Sc+1j7EQgyk+BThT9XkihhaF3XtSAgAAICQCADBe3AA== Importance: low X-Priority: 5 Date: Fri, 3 Mar 2017 19:35:47 +0000 Message-ID: References: <148414831932.11019.14685466226406323027.idtracker@ietfa.amsl.com> <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.230.247] x-microsoft-exchange-diagnostics: 1; BN6PR09MB1428; 7:T6Cx9gq0f0s93mkzScvNkR4CE8mPV8h5SMYR4iENjgF4PCInVNItlZfI7RlVMNbdqvM+fLua4v5gm+a1cMH2Zk29rtVO63bHFWs3GrHMFQeEV3wYRd3tx3UpiTuXVC6DkAYWTCLVCuZ+/vioOrTgp3GT5/YKVoNp5h/jJNomBFMa31ZRnbLFpcK4B+9QYe1OqUPm6jrHEAPM0jJQ9GH8gWQ5IpyRwiJ3oqtAzjBwhcXS/UI+sNd76QXHIlB64S2zIMdHayIA2NHcnEkQo++fW2id0I0rrzeoKmSymOoIiH0lFcmNZ06diCrnndmJ71TAlr2OHh8ABRNTJ+TSBdHDTw== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39850400002)(39450400003)(39840400002)(24454002)(377454003)(13464003)(3280700002)(3660700001)(122556002)(4001350100001)(230783001)(66066001)(50986999)(76176999)(86362001)(54356999)(81686999)(229853002)(25786008)(99286003)(2900100001)(77096006)(2906002)(92566002)(2950100002)(54906002)(6486002)(106116001)(6506006)(6436002)(6306002)(6246003)(38730400002)(53546006)(6512007)(36756003)(53936002)(305945005)(7736002)(83506001)(81166006)(189998001)(8936002)(8676002)(6116002)(4326008)(2501003)(5660300001)(102836003)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR09MB1428; H:BN6PR09MB1426.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 1eda0092-a501-4c72-a68a-08d4626c7e01 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR09MB1428; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(95692535739014)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123558025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:BN6PR09MB1428; BCL:0; PCL:0; RULEID:; SRVR:BN6PR09MB1428; x-forefront-prvs: 0235CBE7D0 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <9E70112F1729514793E4D4281C5BA60F@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2017 19:35:47.3757 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR09MB1428 Archived-At: Cc: "sidr@ietf.org" , "sidr-chairs@ietf.org" , "sandy@tislabs.com" Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-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: Fri, 03 Mar 2017 19:35:52 -0000 SSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgdGhlIG9yaWdpbmFsIHF1ZXN0aW9uL3BvaW50IGFu ZC9vciBBbHZhcm8ncw0KcmVzcG9uc2UuDQoNClRoZSBzcGVjIGluIHNlY3Rpb24gMiBzYXlzOg0K DQrigJwuLi5TaW1pbGFybHkgb24gdGhlIHJlY2VpdmluZyBJQkdQIHNwZWFrZXJzLCB0aGUgdmFs aWRhdGlvbiBzdGF0ZSBvZiBhbg0KSUJHUCByb3V0ZSBTSE9VTEQgYmUgZGVyaXZlZCBkaXJlY3Rs eSBmcm9tIHRoZSBsYXN0IG9jdGV0IG9mIHRoZSBleHRlbmRlZA0KY29tbXVuaXR5LCBpZiBwcmVz ZW50LuKAnQ0KDQoNClRoYXQgc2VlbXMgbGlrZSBhIHN1Z2dlc3RlZCByZWNlaXZlIGxvZ2ljIOKA piBhbHRob3VnaCBpdCBpcyBhIFNIT1VMRC4gIE9mDQpjb3Vyc2UgaXQgaXMgc3RpbGwgdXAgdG8g bG9jYWwgcG9saWN5IGhvdyB0aGlzIHZhbGlkYXRpb24gc3RhdGUgZWZmZWN0cw0KdGhlIGRlY2lz aW9uIHByb2Nlc3MuDQoNCkkgdGhpbmsgaXQgd291bGQgYmUgYSBtaXN0YWtlIHRvIG1ha2Ugc29t ZSBjaGFuZ2UgdGhhdCBzdWdnZXN0ZWQgdGhhdCB0aGUNCnJlY2VpdmVkIHZhbGlkYXRpb24gc3Rh dGUgb24gYSBpQkdQIHVwZGF0ZSBzaG91bGQgc29tZWhvdyBpbmZsdWVuY2UgdGhlDQpjb21wdXRl ZCBvcmlnaW4gdmFsaWRhdGlvbiBzdGF0ZSBvZiBvdGhlciByZWNlaXZlZCB1cGRhdGVzLiAgSW4g cGFydGljdWxhcg0KaW5mbHVlbmNpbmcgdGhlIHZhbGlkYXRpb24gc3RhdGUgb2YgYW55IGxvY2Fs bHkgdmFsaWRhdGVkIHVwZGF0ZXMuICBUaGUNCm9yaWdpbmFsIHF1ZXN0aW9uIHNlZW1zIHRvIHN1 Z2dlc3QgdGhhdCBhIHJlY2VpdmVkIElOVkFMSUQgb3IgVkFMSUQgbWlnaHQNCnN1cGVyc2VkZSBh IOKAnE5PVF9GT1VOROKAnS4gKHdhcyB0aGF0IHRoZSBzdWdnZXN0aW9uPykgIFN1Y2ggYSBzaXR1 YXRpb24NCnJlcHJlc2VudHMgYW4gUlBLSSBzdGF0ZSBza2V3IGJldHdlZW4gdGhlIHR3byByb3V0 ZXJzIChtaWdodCBqdXN0IGJlDQp0cmFuc2l0b3J5KSBidXQgaXQgaXMgaW1wb3NzaWJsZSB0byB0 ZWxsIGlmIHRoZSBJL1Ygb3IgdGhlIE5GIHJlcHJlc2VudHMNCnRoZSBtb3JlIOKAnHVwIHRvIGRh dGXigJ0gcmVzdWx0LiAgQWxzbyBoYXZpbmcgdGhlIG9yaWdpbiB2YWxpZGF0aW9uIHJlc3VsdHMN Cm9mIGEgcm91dGVyIHRoYXQgaXMgZG9pbmcgT1Ygb3ZlcndyaXR0ZW4gYnkgc29tZSBvdGhlciBy b3V0ZXIgKHBvc3NpYmx5DQpzeW5jZWQgdG8gYSBkaWZmZXJlbnQgdmFsaWRhdGluZyBjYWNoZSkg d2lsbCBtYWtlIGRlYnVnZ2luZyBPViByZXN1bHRzDQp2ZXJ5IGRpZmZpY3VsdC4NCg0KSW4gc2hv cnQsIGZvciBub3csIEkgd291bGQgbm90IGNoYW5nZSB0aGUgc3BlYy4gIFdpdGggc29tZSBvcGVy YXRpb25hbA0KZXhwZXJpZW5jZSB3ZSBtaWdodCBmaW5kIHNvbWUgdXNlIGZvciBzaW1pbGFyIGZ1 bmN0aW9uYWxpdHkgKEkgd29uZGVyIGlmDQpieSBOT1RfRk9VTkQgeW91IG1lYW50IG5vdCB2YWxp ZGF0ZWQpIGJ1dCBmb3Igbm93LCBJIHdvdWxkIG5vdCBjaGFuZ2UgaXQuDQoNCmRvdWdtDQrigJQg DQpEb3VnIE1vbnRnb21lcnksIE1nciBJbnRlcm5ldCAmIFNjYWxhYmxlIFN5c3RlbXMgUmVzZWFy Y2ggYXQgIE5JU1QvSVRML0FOVEQNCg0KDQoNCg0KDQpPbiAyLzIzLzE3LCA0OjU1IFBNLCAic2lk ciBvbiBiZWhhbGYgb2YgQWx2YXJvIFJldGFuYSAoYXJldGFuYSkiDQo8c2lkci1ib3VuY2VzQGll dGYub3JnIG9uIGJlaGFsZiBvZiBhcmV0YW5hQGNpc2NvLmNvbT4gd3JvdGU6DQoNCj5bVG9vayB0 aGUgSUVTRywgaWV0Zi1hbm5vdW5jZSBhbmQgcmZjLWVkaXRvciBsaXN0cyBvZmYuXQ0KPg0KPkph a29iOg0KPg0KPkhpIQ0KPg0KPlRoaXMgZG9jdW1lbnQgaXMgYWxyZWFkeSBpbiBBVVRINDguICBJ IGRvbuKAmXQgdGhpbmsgd2UgbmVlZCB0byBtYWtlIGFueQ0KPmNoYW5nZXMgdG8gdGhlIGRvY3Vt ZW50LCBidXQgaWYgd2UgZG8sIHdlIG5lZWQgdG8gZGVjaWRlIHZlcnkgc29vbi4NCj4NCj5UaGUg ZG9jdW1lbnQgZG9lc27igJl0IHNheSBhbnl0aGluZyBhYm91dCB3aGF0IHNob3VsZCBiZSBkb25l IHdpdGggdGhpcw0KPmV4dGVuZGVkIGNvbW11bml0eSwgZXhjZXB0IHRvIHNheSB0aGF0IOKAnHNw ZWFrZXJzIHRoYXQgcmVjZWl2ZSB0aGlzDQo+dmFsaWRhdGlvbiBzdGF0ZSBjYW4gY29uZmlndXJl IGxvY2FsIHBvbGljaWVzIGFsbG93aW5nIGl0IHRvIGluZmx1ZW5jZQ0KPnRoZWlyIGRlY2lzaW9u IHByb2Nlc3Mu4oCdICBJT1csIHRoZXJlIGlzIG5vIGV4cGVjdGVkIGRlZmF1bHQgcHJvY2Vzc2lu ZyBvZg0KPnRoZSB2YWxpZGF0aW9uIHN0YXRlLg0KPg0KPklmIHRoZSBjb21tdW5pdHkgaXMgcmVj ZWl2ZWQgYW5kIHRoZSByb3V0ZXIgYWxzbyBoYXMgdmFsaWRhdGlvbg0KPmluZm9ybWF0aW9uLCB0 aGVuIEkgYWdyZWUgdGhhdCB0aGUgZXh0ZW5kZWQgY29tbXVuaXR5IGlzIG5vdCBuZWVkZWTigKZi dXQgSQ0KPnRoaW5rIHRoYXQgYWN0aW9uIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9j dW1lbnQuDQo+DQo+VGhhbmtzIQ0KPg0KPkFsdmFyby4NCj4NCj4NCj4NCj4NCj5PbiAyLzIzLzE3 LCA0OjI2IFBNLCAiaWVzZyBvbiBiZWhhbGYgb2YgSmFrb2IgSGVpdHogKGpoZWl0eikiDQo+PGll c2ctYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgamhlaXR6QGNpc2NvLmNvbT4gd3JvdGU6 DQo+DQo+ICAgIFdoYXQgaGFwcGVucyBpZiBhIEJHUCBzcGVha2VyIHZhbGlkYXRlcyBhIHJvdXRl IGluIGl0cyBvd24gUlBLSQ0KPmRhdGFiYXNlDQo+ICAgIGFuZCBmaW5kcyBpdCB0byBiZSBlaXRo ZXIgVmFsaWQgb3IgSW52YWxpZCAobm90IE5vdEZvdW5kKSBhbmQgYWxzbw0KPnJlY2VpdmVzDQo+ ICAgIHRoZSBleHRlbmRlZCBjb21tdW5pdHkgdGhhdCBzcGVjaWZpZXMgYSBkaWZmZXJlbnQgdmFs aWRhdGlvbiBzdGF0ZT8NCj4gICAgDQo+ICAgIEkgZG9uJ3Qgc2VlIHRoYXQgY29uZGl0aW9uIGNv dmVyZWQgaW4gdGhlIGRyYWZ0Lg0KPiAgICBJIHdvdWxkIHNheSB0byBpZ25vcmUgdGhlIGV4dGVu ZGVkIGNvbW11bml0eS4NCj4gICAgDQo+ICAgIFRoYW5rcywNCj4gICAgSmFrb2IuDQo+ICAgIA0K PiAgICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ICAgID4gRnJvbTogc2lkciBbbWFp bHRvOnNpZHItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRoZSBJRVNHDQo+ICAgID4g U2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDExLCAyMDE3IDc6MjUgQU0NCj4gICAgPiBUbzogSUVU Ri1Bbm5vdW5jZSA8aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZz4NCj4gICAgPiBDYzogZHJhZnQtaWV0 Zi1zaWRyLW9yaWdpbi12YWxpZGF0aW9uLXNpZ25hbGluZ0BpZXRmLm9yZzsNCj5zaWRyQGlldGYu b3JnOyBzaWRyLWNoYWlyc0BpZXRmLm9yZzsgVGhlIElFU0cNCj4gICAgPiA8aWVzZ0BpZXRmLm9y Zz47IHNhbmR5QHRpc2xhYnMuY29tOyByZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnDQo+ICAgID4g U3ViamVjdDogW3NpZHJdIFByb3RvY29sIEFjdGlvbjogJ0JHUCBQcmVmaXggT3JpZ2luIFZhbGlk YXRpb24NCj5TdGF0ZSBFeHRlbmRlZCBDb21tdW5pdHknIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+ ICAgID4gKGRyYWZ0LWlldGYtc2lkci1vcmlnaW4tdmFsaWRhdGlvbi1zaWduYWxpbmctMTEudHh0 KQ0KPiAgICA+IA0KPiAgICA+IFRoZSBJRVNHIGhhcyBhcHByb3ZlZCB0aGUgZm9sbG93aW5nIGRv Y3VtZW50Og0KPiAgICA+IC0gJ0JHUCBQcmVmaXggT3JpZ2luIFZhbGlkYXRpb24gU3RhdGUgRXh0 ZW5kZWQgQ29tbXVuaXR5Jw0KPiAgICA+ICAgKGRyYWZ0LWlldGYtc2lkci1vcmlnaW4tdmFsaWRh dGlvbi1zaWduYWxpbmctMTEudHh0KSBhcyBQcm9wb3NlZA0KPiAgICA+IFN0YW5kYXJkDQo+ICAg ID4gDQo+ICAgID4gVGhpcyBkb2N1bWVudCBpcyB0aGUgcHJvZHVjdCBvZiB0aGUgU2VjdXJlIElu dGVyLURvbWFpbiBSb3V0aW5nDQo+V29ya2luZw0KPiAgICA+IEdyb3VwLg0KPiAgICA+IA0KPiAg ICA+IFRoZSBJRVNHIGNvbnRhY3QgcGVyc29ucyBhcmUgQWx2YXJvIFJldGFuYSwgQWxpYSBBdGxh cyBhbmQgRGVib3JhaA0KPiAgICA+IEJydW5nYXJkLg0KPiAgICA+IA0KPiAgICA+IEEgVVJMIG9m IHRoaXMgSW50ZXJuZXQgRHJhZnQgaXM6DQo+ICAgID4gDQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zaWRyLW9yaWdpbi12YWxpZGF0aW9uLXNpZ25hbGkNCj5u Zy8NCj4gICAgPiANCj4gICAgPiANCj4gICAgPiANCj4gICAgPiANCj4gICAgPiANCj4gICAgPiBU ZWNobmljYWwgU3VtbWFyeQ0KPiAgICA+IA0KPiAgICA+ICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5l cyBhIG5ldyBCR1Agb3BhcXVlIGV4dGVuZGVkIGNvbW11bml0eSB0bw0KPmNhcnJ5DQo+ICAgID4g ICAgdGhlIG9yaWdpbmF0aW9uIEFTIHZhbGlkYXRpb24gc3RhdGUgaW5zaWRlIGFuIGF1dG9ub21v dXMgc3lzdGVtLg0KPiAgICA+ICAgIElCR1Agc3BlYWtlcnMgdGhhdCByZWNlaXZlIHRoaXMgdmFs aWRhdGlvbiBzdGF0ZSBjYW4gY29uZmlndXJlDQo+bG9jYWwNCj4gICAgPiAgICBwb2xpY2llcyBh bGxvd2luZyBpdCB0byBpbmZsdWVuY2UgdGhlaXIgZGVjaXNpb24gcHJvY2Vzcy4NCj4gICAgPiAN Cj4gICAgPiBXb3JraW5nIEdyb3VwIFN1bW1hcnkNCj4gICAgPiANCj4gICAgPiAgIFRoaXMgZG9j dW1lbnQgaGFzIGhhZCBjb25zaXN0ZW50IGludGVyZXN0IGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAu DQo+ICAgID4gICBCZWNhdXNlIGl0IGRlZmluZXMgYSBuZXcgQkdQIGNvbW11bml0eSwgaXQgd2Fz IHJldmlld2VkIGJ5IHRoZSBpZHINCj4gICAgPiAgIHdvcmtpbmcgZ3JvdXAgYXMgd2VsbC4NCj4g ICAgPiANCj4gICAgPiBEb2N1bWVudCBRdWFsaXR5DQo+ICAgID4gDQo+ICAgID4gICBUaGUgZG9j dW1lbnQgaGFzIGJlZW4gaW1wbGVtZW50ZWQgYnkgbWFqb3Igcm91dGVyIHZlbmRvcnMuDQo+ICAg ID4gICBJdCBpcyBrbm93biB0byBiZSBpbiB1c2UgaW4gdHdvIGxhcmdlIElYUHMsIEFNUy1JWCBh bmQgREUtQ0lYLg0KPiAgICA+IA0KPiAgICA+IFBlcnNvbm5lbA0KPiAgICA+IA0KPiAgICA+ICAg RG9jdW1lbnQgU2hlcGhlcmQ6IFNhbmRyYSBNdXJwaHkNCj4gICAgPiAgIFJlc3BvbnNpYmxlIEFy ZWEgRGlyZWN0b3I6IEFsdmFybyBSZXRhbmENCj4gICAgPiANCj4gICAgPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICA+IHNpZHIgbWFpbGluZyBs aXN0DQo+ICAgID4gc2lkckBpZXRmLm9yZw0KPiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2lkcg0KPiAgICANCj4gICAgDQo+DQo+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zaWRyIG1haWxpbmcgbGlzdA0KPnNpZHJA aWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpZHINCg0K From nobody Fri Mar 3 12:24:49 2017 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 3E404129489; Fri, 3 Mar 2017 12:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_24yVx1PYeQ; Fri, 3 Mar 2017 12:24:46 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19AA2129444; Fri, 3 Mar 2017 12:24:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9558; q=dns/txt; s=iport; t=1488572686; x=1489782286; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/M7pykiPqFBKl4UkosT8RbPOWLFrpwu05lBAa5oveBo=; b=Vm9dXGADP3kYE/7ZMkaRdHaCmwVpSpdNWNhoYf9dNc0Aw4JtZmoMRtnQ 7/iOyMYmDH4ow62KWC3+uXYfYLd/m3bQ3gHr/5r30EiFQm0jt+FqTiBP2 QFnvByko/PZeONOHUwdcd1bJZsow5mBXFGiC6TGO3a1K8qBSEiqWDL2Mj Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKAQDIz7lY/5ldJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQoHg1eKCpFHlTeCDR8NhXYCGoJMPxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?wAQEBBAEBIRE6CwwEAgEIEQQBAQECAh8EAwICAiULFAEICAIEAQ0FCAyJZw6zN?= =?us-ascii?q?oImiwQBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELhUOEb4Rrgm+CXwWcLAGGdYs?= =?us-ascii?q?0ggSPJIhDincBHzhYK1YVP4UKgUp2h1MrgQOBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,238,1484006400"; d="scan'208";a="213938150" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Mar 2017 20:24:44 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v23KOikA018461 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 Mar 2017 20:24:44 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 3 Mar 2017 14:24:44 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Fri, 3 Mar 2017 14:24:44 -0600 From: "Jakob Heitz (jheitz)" To: "Montgomery, Douglas (Fed)" , "Alvaro Retana (aretana)" , "draft-ietf-sidr-origin-validation-signaling@ietf.org" Thread-Topic: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt) Thread-Index: AQHSbB8KL4goLDO+zUCyR+oqQEK9nqF2Wu8wgAEcsQCADL9tgP//pOHg Date: Fri, 3 Mar 2017 20:24:44 +0000 Message-ID: References: <148414831932.11019.14685466226406323027.idtracker@ietfa.amsl.com> <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.90.253] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sidr@ietf.org" , "sidr-chairs@ietf.org" , "sandy@tislabs.com" Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-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: Fri, 03 Mar 2017 20:24:48 -0000 VGhlIGNhc2UgaXMgdW5saWtlbHksIGJ1dCBzb21ldGhpbmcgd2UgbmVlZCB0byB3cml0ZSBjb2Rl IGZvci4NCldpdGhvdXQgYW4gYW5zd2VyLCB0aGVuIHRoZSB2YWxpZGl0eSB3aWxsIGp1c3QgYmUg c2V0IGJ5IHdoaWNoZXZlcg0Kd2FzIHNldCBsYXN0LiBUaGF0IHdvdWxkIG1ha2UgaXQgaW5kZXRl cm1pbmF0ZS4NCg0KVGhlIGNhc2UgaXMgZm9yIGEgc2luZ2xlIHJvdXRlLiBUaGVyZSBpcyBubyBz dWdnZXN0aW9uIG9mIHRoZSB2YWxpZGl0eQ0Kb2Ygb25lIHJvdXRlIGJlaW5nIHVzZWQgdG8gc2V0 IHZhbGlkaXR5IG9mIGFub3RoZXIuDQoNCkEgcm91dGVyIG1heSBiZSBkb2luZyBsb2NhbCB2YWxp ZGF0aW9uLCB1c2luZyBycGtpLXJ0ciBwcm90b2NvbC4NCkluIGFkZGl0aWlvbiwgaXQgbWF5IHJl Y2VpdmUgYSByb3V0ZSB3aXRoIGEgdmFsaWRhdGlvbiBzdGF0ZSBpbg0KYW4gZXh0ZW5kZWQtY29t bXVuaXR5Lg0KDQpUaGUgcXVlc3Rpb24gaXMgd2hhdCB0byBkbyBpZiBvbmUgdmFsaWRhdGlvbiBt ZXRob2Qgc2FzeXMgImludmFsaWQiDQphbmQgdGhlIG90aGVyIHNheXMgInZhbGlkIi4NCg0KVGhl IHNpdHVhdGlvbiBtYXkgYXJpc2UgaWYgdGhlIHJvdXRlciBzZW5kaW5nIHRoZSBleHRlbmRlZC1j b21tdW5pdHkNCmlzIHVzaW5nIGEgZGlmZmVyZW50IHZhbGlkYXRpb24gbWV0aG9kLCBub3QgUlBL SS4NCg0KVGhhbmtzLA0KSmFrb2IuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogTW9udGdvbWVyeSwgRG91Z2xhcyAoRmVkKSBbbWFpbHRvOmRvdWdtQG5pc3QuZ292XQ0K PiBTZW50OiBGcmlkYXksIE1hcmNoIDAzLCAyMDE3IDExOjM2IEFNDQo+IFRvOiBBbHZhcm8gUmV0 YW5hIChhcmV0YW5hKSA8YXJldGFuYUBjaXNjby5jb20+OyBKYWtvYiBIZWl0eiAoamhlaXR6KSA8 amhlaXR6QGNpc2NvLmNvbT47IGRyYWZ0LWlldGYtc2lkci1vcmlnaW4tDQo+IHZhbGlkYXRpb24t c2lnbmFsaW5nQGlldGYub3JnDQo+IENjOiBzYW5keUB0aXNsYWJzLmNvbTsgc2lkci1jaGFpcnNA aWV0Zi5vcmc7IHNpZHJAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzaWRyXSBQcm90b2NvbCBB Y3Rpb246ICdCR1AgUHJlZml4IE9yaWdpbiBWYWxpZGF0aW9uIFN0YXRlIEV4dGVuZGVkIENvbW11 bml0eScgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gKGRyYWZ0LWlldGYtc2lkci1vcmlnaW4tdmFs aWRhdGlvbi1zaWduYWxpbmctMTEudHh0KQ0KPiBJbXBvcnRhbmNlOiBMb3cNCj4gDQo+IEkgYW0g bm90IHN1cmUgSSB1bmRlcnN0YW5kIHRoZSBvcmlnaW5hbCBxdWVzdGlvbi9wb2ludCBhbmQvb3Ig QWx2YXJvJ3MNCj4gcmVzcG9uc2UuDQo+IA0KPiBUaGUgc3BlYyBpbiBzZWN0aW9uIDIgc2F5czoN Cj4gDQo+IOKAnC4uLlNpbWlsYXJseSBvbiB0aGUgcmVjZWl2aW5nIElCR1Agc3BlYWtlcnMsIHRo ZSB2YWxpZGF0aW9uIHN0YXRlIG9mIGFuDQo+IElCR1Agcm91dGUgU0hPVUxEIGJlIGRlcml2ZWQg ZGlyZWN0bHkgZnJvbSB0aGUgbGFzdCBvY3RldCBvZiB0aGUgZXh0ZW5kZWQNCj4gY29tbXVuaXR5 LCBpZiBwcmVzZW50LuKAnQ0KPiANCj4gDQo+IFRoYXQgc2VlbXMgbGlrZSBhIHN1Z2dlc3RlZCBy ZWNlaXZlIGxvZ2ljIOKApiBhbHRob3VnaCBpdCBpcyBhIFNIT1VMRC4gIE9mDQo+IGNvdXJzZSBp dCBpcyBzdGlsbCB1cCB0byBsb2NhbCBwb2xpY3kgaG93IHRoaXMgdmFsaWRhdGlvbiBzdGF0ZSBl ZmZlY3RzDQo+IHRoZSBkZWNpc2lvbiBwcm9jZXNzLg0KPiANCj4gSSB0aGluayBpdCB3b3VsZCBi ZSBhIG1pc3Rha2UgdG8gbWFrZSBzb21lIGNoYW5nZSB0aGF0IHN1Z2dlc3RlZCB0aGF0IHRoZQ0K PiByZWNlaXZlZCB2YWxpZGF0aW9uIHN0YXRlIG9uIGEgaUJHUCB1cGRhdGUgc2hvdWxkIHNvbWVo b3cgaW5mbHVlbmNlIHRoZQ0KPiBjb21wdXRlZCBvcmlnaW4gdmFsaWRhdGlvbiBzdGF0ZSBvZiBv dGhlciByZWNlaXZlZCB1cGRhdGVzLiAgSW4gcGFydGljdWxhcg0KPiBpbmZsdWVuY2luZyB0aGUg dmFsaWRhdGlvbiBzdGF0ZSBvZiBhbnkgbG9jYWxseSB2YWxpZGF0ZWQgdXBkYXRlcy4gIFRoZQ0K PiBvcmlnaW5hbCBxdWVzdGlvbiBzZWVtcyB0byBzdWdnZXN0IHRoYXQgYSByZWNlaXZlZCBJTlZB TElEIG9yIFZBTElEIG1pZ2h0DQo+IHN1cGVyc2VkZSBhIOKAnE5PVF9GT1VOROKAnS4gKHdhcyB0 aGF0IHRoZSBzdWdnZXN0aW9uPykgIFN1Y2ggYSBzaXR1YXRpb24NCj4gcmVwcmVzZW50cyBhbiBS UEtJIHN0YXRlIHNrZXcgYmV0d2VlbiB0aGUgdHdvIHJvdXRlcnMgKG1pZ2h0IGp1c3QgYmUNCj4g dHJhbnNpdG9yeSkgYnV0IGl0IGlzIGltcG9zc2libGUgdG8gdGVsbCBpZiB0aGUgSS9WIG9yIHRo ZSBORiByZXByZXNlbnRzDQo+IHRoZSBtb3JlIOKAnHVwIHRvIGRhdGXigJ0gcmVzdWx0LiAgQWxz byBoYXZpbmcgdGhlIG9yaWdpbiB2YWxpZGF0aW9uIHJlc3VsdHMNCj4gb2YgYSByb3V0ZXIgdGhh dCBpcyBkb2luZyBPViBvdmVyd3JpdHRlbiBieSBzb21lIG90aGVyIHJvdXRlciAocG9zc2libHkN Cj4gc3luY2VkIHRvIGEgZGlmZmVyZW50IHZhbGlkYXRpbmcgY2FjaGUpIHdpbGwgbWFrZSBkZWJ1 Z2dpbmcgT1YgcmVzdWx0cw0KPiB2ZXJ5IGRpZmZpY3VsdC4NCj4gDQo+IEluIHNob3J0LCBmb3Ig bm93LCBJIHdvdWxkIG5vdCBjaGFuZ2UgdGhlIHNwZWMuICBXaXRoIHNvbWUgb3BlcmF0aW9uYWwN Cj4gZXhwZXJpZW5jZSB3ZSBtaWdodCBmaW5kIHNvbWUgdXNlIGZvciBzaW1pbGFyIGZ1bmN0aW9u YWxpdHkgKEkgd29uZGVyIGlmDQo+IGJ5IE5PVF9GT1VORCB5b3UgbWVhbnQgbm90IHZhbGlkYXRl ZCkgYnV0IGZvciBub3csIEkgd291bGQgbm90IGNoYW5nZSBpdC4NCj4gDQo+IGRvdWdtDQo+IOKA lA0KPiBEb3VnIE1vbnRnb21lcnksIE1nciBJbnRlcm5ldCAmIFNjYWxhYmxlIFN5c3RlbXMgUmVz ZWFyY2ggYXQgIE5JU1QvSVRML0FOVEQNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBPbiAyLzIzLzE3 LCA0OjU1IFBNLCAic2lkciBvbiBiZWhhbGYgb2YgQWx2YXJvIFJldGFuYSAoYXJldGFuYSkiDQo+ IDxzaWRyLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGFyZXRhbmFAY2lzY28uY29tPiB3 cm90ZToNCj4gDQo+ID5bVG9vayB0aGUgSUVTRywgaWV0Zi1hbm5vdW5jZSBhbmQgcmZjLWVkaXRv ciBsaXN0cyBvZmYuXQ0KPiA+DQo+ID5KYWtvYjoNCj4gPg0KPiA+SGkhDQo+ID4NCj4gPlRoaXMg ZG9jdW1lbnQgaXMgYWxyZWFkeSBpbiBBVVRINDguICBJIGRvbuKAmXQgdGhpbmsgd2UgbmVlZCB0 byBtYWtlIGFueQ0KPiA+Y2hhbmdlcyB0byB0aGUgZG9jdW1lbnQsIGJ1dCBpZiB3ZSBkbywgd2Ug bmVlZCB0byBkZWNpZGUgdmVyeSBzb29uLg0KPiA+DQo+ID5UaGUgZG9jdW1lbnQgZG9lc27igJl0 IHNheSBhbnl0aGluZyBhYm91dCB3aGF0IHNob3VsZCBiZSBkb25lIHdpdGggdGhpcw0KPiA+ZXh0 ZW5kZWQgY29tbXVuaXR5LCBleGNlcHQgdG8gc2F5IHRoYXQg4oCcc3BlYWtlcnMgdGhhdCByZWNl aXZlIHRoaXMNCj4gPnZhbGlkYXRpb24gc3RhdGUgY2FuIGNvbmZpZ3VyZSBsb2NhbCBwb2xpY2ll cyBhbGxvd2luZyBpdCB0byBpbmZsdWVuY2UNCj4gPnRoZWlyIGRlY2lzaW9uIHByb2Nlc3Mu4oCd ICBJT1csIHRoZXJlIGlzIG5vIGV4cGVjdGVkIGRlZmF1bHQgcHJvY2Vzc2luZyBvZg0KPiA+dGhl IHZhbGlkYXRpb24gc3RhdGUuDQo+ID4NCj4gPklmIHRoZSBjb21tdW5pdHkgaXMgcmVjZWl2ZWQg YW5kIHRoZSByb3V0ZXIgYWxzbyBoYXMgdmFsaWRhdGlvbg0KPiA+aW5mb3JtYXRpb24sIHRoZW4g SSBhZ3JlZSB0aGF0IHRoZSBleHRlbmRlZCBjb21tdW5pdHkgaXMgbm90IG5lZWRlZOKApmJ1dCBJ DQo+ID50aGluayB0aGF0IGFjdGlvbiBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3Vt ZW50Lg0KPiA+DQo+ID5UaGFua3MhDQo+ID4NCj4gPkFsdmFyby4NCj4gPg0KPiA+DQo+ID4NCj4g Pg0KPiA+T24gMi8yMy8xNywgNDoyNiBQTSwgImllc2cgb24gYmVoYWxmIG9mIEpha29iIEhlaXR6 IChqaGVpdHopIg0KPiA+PGllc2ctYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgamhlaXR6 QGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiAgICBXaGF0IGhhcHBlbnMgaWYgYSBCR1Agc3Bl YWtlciB2YWxpZGF0ZXMgYSByb3V0ZSBpbiBpdHMgb3duIFJQS0kNCj4gPmRhdGFiYXNlDQo+ID4g ICAgYW5kIGZpbmRzIGl0IHRvIGJlIGVpdGhlciBWYWxpZCBvciBJbnZhbGlkIChub3QgTm90Rm91 bmQpIGFuZCBhbHNvDQo+ID5yZWNlaXZlcw0KPiA+ICAgIHRoZSBleHRlbmRlZCBjb21tdW5pdHkg dGhhdCBzcGVjaWZpZXMgYSBkaWZmZXJlbnQgdmFsaWRhdGlvbiBzdGF0ZT8NCj4gPg0KPiA+ICAg IEkgZG9uJ3Qgc2VlIHRoYXQgY29uZGl0aW9uIGNvdmVyZWQgaW4gdGhlIGRyYWZ0Lg0KPiA+ICAg IEkgd291bGQgc2F5IHRvIGlnbm9yZSB0aGUgZXh0ZW5kZWQgY29tbXVuaXR5Lg0KPiA+DQo+ID4g ICAgVGhhbmtzLA0KPiA+ICAgIEpha29iLg0KPiA+DQo+ID4gICAgPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiA+ICAgID4gRnJvbTogc2lkciBbbWFpbHRvOnNpZHItYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIFRoZSBJRVNHDQo+ID4gICAgPiBTZW50OiBXZWRuZXNkYXksIEph bnVhcnkgMTEsIDIwMTcgNzoyNSBBTQ0KPiA+ICAgID4gVG86IElFVEYtQW5ub3VuY2UgPGlldGYt YW5ub3VuY2VAaWV0Zi5vcmc+DQo+ID4gICAgPiBDYzogZHJhZnQtaWV0Zi1zaWRyLW9yaWdpbi12 YWxpZGF0aW9uLXNpZ25hbGluZ0BpZXRmLm9yZzsNCj4gPnNpZHJAaWV0Zi5vcmc7IHNpZHItY2hh aXJzQGlldGYub3JnOyBUaGUgSUVTRw0KPiA+ICAgID4gPGllc2dAaWV0Zi5vcmc+OyBzYW5keUB0 aXNsYWJzLmNvbTsgcmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZw0KPiA+ICAgID4gU3ViamVjdDog W3NpZHJdIFByb3RvY29sIEFjdGlvbjogJ0JHUCBQcmVmaXggT3JpZ2luIFZhbGlkYXRpb24NCj4g PlN0YXRlIEV4dGVuZGVkIENvbW11bml0eScgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPiAgICA+ IChkcmFmdC1pZXRmLXNpZHItb3JpZ2luLXZhbGlkYXRpb24tc2lnbmFsaW5nLTExLnR4dCkNCj4g PiAgICA+DQo+ID4gICAgPiBUaGUgSUVTRyBoYXMgYXBwcm92ZWQgdGhlIGZvbGxvd2luZyBkb2N1 bWVudDoNCj4gPiAgICA+IC0gJ0JHUCBQcmVmaXggT3JpZ2luIFZhbGlkYXRpb24gU3RhdGUgRXh0 ZW5kZWQgQ29tbXVuaXR5Jw0KPiA+ICAgID4gICAoZHJhZnQtaWV0Zi1zaWRyLW9yaWdpbi12YWxp ZGF0aW9uLXNpZ25hbGluZy0xMS50eHQpIGFzIFByb3Bvc2VkDQo+ID4gICAgPiBTdGFuZGFyZA0K PiA+ICAgID4NCj4gPiAgICA+IFRoaXMgZG9jdW1lbnQgaXMgdGhlIHByb2R1Y3Qgb2YgdGhlIFNl Y3VyZSBJbnRlci1Eb21haW4gUm91dGluZw0KPiA+V29ya2luZw0KPiA+ICAgID4gR3JvdXAuDQo+ ID4gICAgPg0KPiA+ICAgID4gVGhlIElFU0cgY29udGFjdCBwZXJzb25zIGFyZSBBbHZhcm8gUmV0 YW5hLCBBbGlhIEF0bGFzIGFuZCBEZWJvcmFoDQo+ID4gICAgPiBCcnVuZ2FyZC4NCj4gPiAgICA+ DQo+ID4gICAgPiBBIFVSTCBvZiB0aGlzIEludGVybmV0IERyYWZ0IGlzOg0KPiA+ICAgID4NCj4g Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2lkci1vcmlnaW4t dmFsaWRhdGlvbi1zaWduYWxpDQo+ID5uZy8NCj4gPiAgICA+DQo+ID4gICAgPg0KPiA+ICAgID4N Cj4gPiAgICA+DQo+ID4gICAgPg0KPiA+ICAgID4gVGVjaG5pY2FsIFN1bW1hcnkNCj4gPiAgICA+ DQo+ID4gICAgPiAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgQkdQIG9wYXF1ZSBleHRl bmRlZCBjb21tdW5pdHkgdG8NCj4gPmNhcnJ5DQo+ID4gICAgPiAgICB0aGUgb3JpZ2luYXRpb24g QVMgdmFsaWRhdGlvbiBzdGF0ZSBpbnNpZGUgYW4gYXV0b25vbW91cyBzeXN0ZW0uDQo+ID4gICAg PiAgICBJQkdQIHNwZWFrZXJzIHRoYXQgcmVjZWl2ZSB0aGlzIHZhbGlkYXRpb24gc3RhdGUgY2Fu IGNvbmZpZ3VyZQ0KPiA+bG9jYWwNCj4gPiAgICA+ICAgIHBvbGljaWVzIGFsbG93aW5nIGl0IHRv IGluZmx1ZW5jZSB0aGVpciBkZWNpc2lvbiBwcm9jZXNzLg0KPiA+ICAgID4NCj4gPiAgICA+IFdv cmtpbmcgR3JvdXAgU3VtbWFyeQ0KPiA+ICAgID4NCj4gPiAgICA+ICAgVGhpcyBkb2N1bWVudCBo YXMgaGFkIGNvbnNpc3RlbnQgaW50ZXJlc3QgZnJvbSB0aGUgd29ya2luZyBncm91cC4NCj4gPiAg ICA+ICAgQmVjYXVzZSBpdCBkZWZpbmVzIGEgbmV3IEJHUCBjb21tdW5pdHksIGl0IHdhcyByZXZp ZXdlZCBieSB0aGUgaWRyDQo+ID4gICAgPiAgIHdvcmtpbmcgZ3JvdXAgYXMgd2VsbC4NCj4gPiAg ICA+DQo+ID4gICAgPiBEb2N1bWVudCBRdWFsaXR5DQo+ID4gICAgPg0KPiA+ICAgID4gICBUaGUg ZG9jdW1lbnQgaGFzIGJlZW4gaW1wbGVtZW50ZWQgYnkgbWFqb3Igcm91dGVyIHZlbmRvcnMuDQo+ ID4gICAgPiAgIEl0IGlzIGtub3duIHRvIGJlIGluIHVzZSBpbiB0d28gbGFyZ2UgSVhQcywgQU1T LUlYIGFuZCBERS1DSVguDQo+ID4gICAgPg0KPiA+ICAgID4gUGVyc29ubmVsDQo+ID4gICAgPg0K PiA+ICAgID4gICBEb2N1bWVudCBTaGVwaGVyZDogU2FuZHJhIE11cnBoeQ0KPiA+ICAgID4gICBS ZXNwb25zaWJsZSBBcmVhIERpcmVjdG9yOiBBbHZhcm8gUmV0YW5hDQo+ID4gICAgPg0KPiA+ICAg ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiAg ICA+IHNpZHIgbWFpbGluZyBsaXN0DQo+ID4gICAgPiBzaWRyQGlldGYub3JnDQo+ID4gICAgPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpZHINCj4gPg0KPiA+DQo+ID4N Cj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID5z aWRyIG1haWxpbmcgbGlzdA0KPiA+c2lkckBpZXRmLm9yZw0KPiA+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zaWRyDQoNCg== From nobody Fri Mar 3 12:43:46 2017 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 B9EBA129602; Fri, 3 Mar 2017 12:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.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 yzSxX93o88if; Fri, 3 Mar 2017 12:43:32 -0800 (PST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) (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 F3314129528; Fri, 3 Mar 2017 12:43:31 -0800 (PST) Received: from pure.maildistiller.com (unknown [10.110.50.29]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id 75AF860064; Fri, 3 Mar 2017 20:43:31 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx9-us1.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 3A9A960049; Fri, 3 Mar 2017 20:43:31 +0000 (UTC) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0116.outbound.protection.outlook.com [207.46.163.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx9-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 93F9818007F; Fri, 3 Mar 2017 20:43:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=S3lUjlMBe93ZrvYOYrL/PGGdqHvUi8yz7llfSyHWkQ4=; b=mKvlb9aVJo4l6hBKydQZO/fSEOiDggdX+QC8REWyGnghRWMyMYWQjSDjldpn7W2YvTU0NWjNkZi9Vqy26hY45ihQwO079XJJ/IoAk2EWwuQlqrvQ9CpTz7urPN66ydrO45Gs2AgvSGbyf/3tFBA/aS1sqTREPeXE212FrsNv3KM= Received: from BY2PR18MB0262.namprd18.prod.outlook.com (10.163.72.152) by BY2PR18MB0262.namprd18.prod.outlook.com (10.163.72.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Fri, 3 Mar 2017 20:43:18 +0000 Received: from BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) by BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) with mapi id 15.01.0933.020; Fri, 3 Mar 2017 20:43:18 +0000 From: Keyur Patel To: "Jakob Heitz (jheitz)" , The IESG , IETF-Announce Thread-Topic: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt) Thread-Index: AQHSbB7tzlS1UVmWk0KSI6cn7Yzvt6F3XtWAgAwAYgA= Date: Fri, 3 Mar 2017 20:43:18 +0000 Message-ID: References: <148414831932.11019.14685466226406323027.idtracker@ietfa.amsl.com> <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com> In-Reply-To: <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=arrcus.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [96.68.143.133] x-ms-office365-filtering-correlation-id: 17115c7b-4396-4ddd-2af2-08d46275ecab x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BY2PR18MB0262; x-microsoft-exchange-diagnostics: 1; BY2PR18MB0262; 7:CSa0GQIWN17ICyq085FGTL3ScmowRwnjr5feplOWa8JAjXFtCPfyXxHI4Ync6df5dNTOGhjXUKC+L9SRisRDctF5BCwFZFPpDR/9fQEpDBnqCrAPpHG3oe2qwgJvlU2qidxl6/swF+I3BnZ3kkxOaIcsEbarKBjXRlvjy/HNYWbpm4WpxtY46eKAVpTbBg3rXf5z/5KoEJ14mrSjRBYeRp4sm47u7X3fhOFgOHx3oyLooPoqQyeMD7XEYbjGCiVp/7l0xeT+P+O83EBaJGQLLV0GZEQ2elwocGFoGxDrd9GYZU6cm9T88pz85sU0RLsZ9YA/iCAGPWvzOCqZjEKhZQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(95692535739014)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(20161123558025)(2016111802025)(6072148)(6043046); SRVR:BY2PR18MB0262; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0262; x-forefront-prvs: 0235CBE7D0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(39410400002)(39830400002)(24454002)(377454003)(13464003)(305945005)(8676002)(33656002)(7736002)(81166006)(53546006)(83716003)(8936002)(5660300001)(122556002)(2950100002)(4326008)(230783001)(6116002)(102836003)(106116001)(3846002)(6436002)(82746002)(6486002)(77096006)(36756003)(66066001)(3660700001)(229853002)(53936002)(2900100001)(54356999)(76176999)(6246003)(6512007)(86362001)(3280700002)(99286003)(54906002)(6306002)(2906002)(189998001)(38730400002)(6506006)(25786008)(92566002)(50986999)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0262; H:BY2PR18MB0262.namprd18.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <37DF7766BFF34C4A9BFD617AF7C430AD@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2017 20:43:18.5387 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0262 X-MDID: 1488573811-Qp54ImIgU9Ed Archived-At: Cc: "draft-ietf-sidr-origin-validation-signaling@ietf.org" , "sidr@ietf.org" , "sidr-chairs@ietf.org" , The IESG , "sandy@tislabs.com" , "rfc-editor@rfc-editor.org" Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-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: Fri, 03 Mar 2017 20:43:41 -0000 SmFjb2IsDQoNCkFwb2xvZ2llcyBmb3IgdGhlIGRlbGF5ZWQgcmVzcG9uc2UuIENvbW1lbnRzICNL ZXl1cg0KDQpPbiAyLzIzLzE3LCAxOjI2IFBNLCAiSmFrb2IgSGVpdHogKGpoZWl0eikiIDxqaGVp dHpAY2lzY28uY29tPiB3cm90ZToNCg0KICAgIFdoYXQgaGFwcGVucyBpZiBhIEJHUCBzcGVha2Vy IHZhbGlkYXRlcyBhIHJvdXRlIGluIGl0cyBvd24gUlBLSSBkYXRhYmFzZQ0KICAgIGFuZCBmaW5k cyBpdCB0byBiZSBlaXRoZXIgVmFsaWQgb3IgSW52YWxpZCAobm90IE5vdEZvdW5kKSBhbmQgYWxz byByZWNlaXZlcw0KICAgIHRoZSBleHRlbmRlZCBjb21tdW5pdHkgdGhhdCBzcGVjaWZpZXMgYSBk aWZmZXJlbnQgdmFsaWRhdGlvbiBzdGF0ZT8NCiAgICANCiNLZXl1cjogVGhhdCBwcmV0dHkgbXVj aCBtZWFucyB0aGF0IGliZ3Agc3BlYWtlcnMgaGFzIG91dCBvZiBzeW5jIHJwa2kgZGF0YS4gVGhp cyBjb3VsZCB2ZXJ5IHdlbGwgaGFwcGVuIGlmIHRoZSBpYmdwIHNwZWFrZXJzIGhhdmUgZGlmZmVy ZW50IHJlZnJlc2ggaW50ZXJ2YWxzIGZvciBwb2xsaW5nIHRoZSBycGtpIGRhdGEgKG9yIHNvbWUg ZXJyb3IgaGFzIG9jY3VycmVkIHRoYXQgaGFzIHJlc3VsdGVkIGludG8gYSBzdGFsZSBzdGF0ZSku DQoNCiAgICBJIGRvbid0IHNlZSB0aGF0IGNvbmRpdGlvbiBjb3ZlcmVkIGluIHRoZSBkcmFmdC4N CiAgICBJIHdvdWxkIHNheSB0byBpZ25vcmUgdGhlIGV4dGVuZGVkIGNvbW11bml0eS4NCiAgICAN CiNLZXl1cjogSSBhbSBub3Qgc3VyZSBpZiB3ZSBuZWVkIHRvIGFkZCBhbnkgdGV4dD8gRXh0ZW5k ZWQgY29tbXVuaXR5IG1hcHMgdG8gYSBwb2xpY3kgb24gYSBuIGluYm91bmQgc2lkZS4gUG9saWN5 IHdvdWxkIGRpY3RhdGUgaG93IHlvdSB3b3VsZCB3YW50IHRvIHVzZSB0aGUgY29tbXVuaXR5LiBJ bXBsZW1lbnRhdGlvbnMgY291bGQgYWx3YXlzIGxvZyBhbnkgY29uZmxpY3RpbmcgcnBraSBzdGF0 ZSB0aGV5IGVuY291bnRlcj8NCg0KUmVnYXJkcywNCktleXVyDQoNCiAgICBUaGFua3MsDQogICAg SmFrb2IuDQogICAgDQogICAgPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgID4gRnJv bTogc2lkciBbbWFpbHRvOnNpZHItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRoZSBJ RVNHDQogICAgPiBTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMTEsIDIwMTcgNzoyNSBBTQ0KICAg ID4gVG86IElFVEYtQW5ub3VuY2UgPGlldGYtYW5ub3VuY2VAaWV0Zi5vcmc+DQogICAgPiBDYzog ZHJhZnQtaWV0Zi1zaWRyLW9yaWdpbi12YWxpZGF0aW9uLXNpZ25hbGluZ0BpZXRmLm9yZzsgc2lk ckBpZXRmLm9yZzsgc2lkci1jaGFpcnNAaWV0Zi5vcmc7IFRoZSBJRVNHDQogICAgPiA8aWVzZ0Bp ZXRmLm9yZz47IHNhbmR5QHRpc2xhYnMuY29tOyByZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnDQog ICAgPiBTdWJqZWN0OiBbc2lkcl0gUHJvdG9jb2wgQWN0aW9uOiAnQkdQIFByZWZpeCBPcmlnaW4g VmFsaWRhdGlvbiBTdGF0ZSBFeHRlbmRlZCBDb21tdW5pdHknIHRvIFByb3Bvc2VkIFN0YW5kYXJk DQogICAgPiAoZHJhZnQtaWV0Zi1zaWRyLW9yaWdpbi12YWxpZGF0aW9uLXNpZ25hbGluZy0xMS50 eHQpDQogICAgPiANCiAgICA+IFRoZSBJRVNHIGhhcyBhcHByb3ZlZCB0aGUgZm9sbG93aW5nIGRv Y3VtZW50Og0KICAgID4gLSAnQkdQIFByZWZpeCBPcmlnaW4gVmFsaWRhdGlvbiBTdGF0ZSBFeHRl bmRlZCBDb21tdW5pdHknDQogICAgPiAgIChkcmFmdC1pZXRmLXNpZHItb3JpZ2luLXZhbGlkYXRp b24tc2lnbmFsaW5nLTExLnR4dCkgYXMgUHJvcG9zZWQNCiAgICA+IFN0YW5kYXJkDQogICAgPiAN CiAgICA+IFRoaXMgZG9jdW1lbnQgaXMgdGhlIHByb2R1Y3Qgb2YgdGhlIFNlY3VyZSBJbnRlci1E b21haW4gUm91dGluZyBXb3JraW5nDQogICAgPiBHcm91cC4NCiAgICA+IA0KICAgID4gVGhlIElF U0cgY29udGFjdCBwZXJzb25zIGFyZSBBbHZhcm8gUmV0YW5hLCBBbGlhIEF0bGFzIGFuZCBEZWJv cmFoDQogICAgPiBCcnVuZ2FyZC4NCiAgICA+IA0KICAgID4gQSBVUkwgb2YgdGhpcyBJbnRlcm5l dCBEcmFmdCBpczoNCiAgICA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtc2lkci1vcmlnaW4tdmFsaWRhdGlvbi1zaWduYWxpbmcvDQogICAgPiANCiAgICA+IA0K ICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gVGVjaG5pY2FsIFN1bW1hcnkNCiAgICA+IA0K ICAgID4gICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IEJHUCBvcGFxdWUgZXh0ZW5kZWQg Y29tbXVuaXR5IHRvIGNhcnJ5DQogICAgPiAgICB0aGUgb3JpZ2luYXRpb24gQVMgdmFsaWRhdGlv biBzdGF0ZSBpbnNpZGUgYW4gYXV0b25vbW91cyBzeXN0ZW0uDQogICAgPiAgICBJQkdQIHNwZWFr ZXJzIHRoYXQgcmVjZWl2ZSB0aGlzIHZhbGlkYXRpb24gc3RhdGUgY2FuIGNvbmZpZ3VyZSBsb2Nh bA0KICAgID4gICAgcG9saWNpZXMgYWxsb3dpbmcgaXQgdG8gaW5mbHVlbmNlIHRoZWlyIGRlY2lz aW9uIHByb2Nlc3MuDQogICAgPiANCiAgICA+IFdvcmtpbmcgR3JvdXAgU3VtbWFyeQ0KICAgID4g DQogICAgPiAgIFRoaXMgZG9jdW1lbnQgaGFzIGhhZCBjb25zaXN0ZW50IGludGVyZXN0IGZyb20g dGhlIHdvcmtpbmcgZ3JvdXAuDQogICAgPiAgIEJlY2F1c2UgaXQgZGVmaW5lcyBhIG5ldyBCR1Ag Y29tbXVuaXR5LCBpdCB3YXMgcmV2aWV3ZWQgYnkgdGhlIGlkcg0KICAgID4gICB3b3JraW5nIGdy b3VwIGFzIHdlbGwuDQogICAgPiANCiAgICA+IERvY3VtZW50IFF1YWxpdHkNCiAgICA+IA0KICAg ID4gICBUaGUgZG9jdW1lbnQgaGFzIGJlZW4gaW1wbGVtZW50ZWQgYnkgbWFqb3Igcm91dGVyIHZl bmRvcnMuDQogICAgPiAgIEl0IGlzIGtub3duIHRvIGJlIGluIHVzZSBpbiB0d28gbGFyZ2UgSVhQ cywgQU1TLUlYIGFuZCBERS1DSVguDQogICAgPiANCiAgICA+IFBlcnNvbm5lbA0KICAgID4gDQog ICAgPiAgIERvY3VtZW50IFNoZXBoZXJkOiBTYW5kcmEgTXVycGh5DQogICAgPiAgIFJlc3BvbnNp YmxlIEFyZWEgRGlyZWN0b3I6IEFsdmFybyBSZXRhbmENCiAgICA+IA0KICAgID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IHNpZHIgbWFpbGlu ZyBsaXN0DQogICAgPiBzaWRyQGlldGYub3JnDQogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NpZHINCiAgICANCg0K From nobody Fri Mar 3 13:15:12 2017 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 4F80A1294AE; Fri, 3 Mar 2017 13:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ah6Tui_zFs08; Fri, 3 Mar 2017 13:15:09 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2382812896F; Fri, 3 Mar 2017 13:15:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5498; q=dns/txt; s=iport; t=1488575709; x=1489785309; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JMR7PWssz4i5X7wWM0un5E0dK+drFhdhlJbpVS4Tvpc=; b=UUgS+WLW/bRzhrwFRs5SJDRvY7BCXBurJ2jNqve9LdT82KOZvITB5uSj ddIPN7AJe//i0FpxE+0Q7IX/5+xKs9g0vql6+JrlieXrK29Egg+1dxkDU qIKYtfOb6YS/niXZTijkhTgMQ/klUHhAh1p1tgqos9cV15aCacrAcyADk E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKAQD/27lY/5tdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQoHg1eKCpFHlTeCDR8NhXYCGoJMPxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?wAQEBBAEBIRE6CwwEAgEIEQQBAQECAh8EAwICAiULFAEICAIEAQ0FCAyJZw6zR?= =?us-ascii?q?YImiwIBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELhUOEb4Rrgm+CXwWcLAGGdYs?= =?us-ascii?q?0kSiTOgEfOFgrVhU/hQqBSnaHUyuBA4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.35,238,1484006400"; d="scan'208";a="393179031" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Mar 2017 21:15:08 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v23LF8nl028692 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 Mar 2017 21:15:08 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 3 Mar 2017 15:15:07 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Fri, 3 Mar 2017 15:15:07 -0600 From: "Jakob Heitz (jheitz)" To: Keyur Patel , The IESG , IETF-Announce Thread-Topic: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt) Thread-Index: AQHSbB8KL4goLDO+zUCyR+oqQEK9nqF2Wu8wgA3u+wD//6L1QA== Date: Fri, 3 Mar 2017 21:15:07 +0000 Message-ID: <4ae6d6be76c547f4a6a131cc0f3431be@XCH-ALN-014.cisco.com> References: <148414831932.11019.14685466226406323027.idtracker@ietfa.amsl.com> <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.90.253] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sidr-origin-validation-signaling@ietf.org" , "sidr@ietf.org" , "sidr-chairs@ietf.org" , The IESG , "sandy@tislabs.com" , "rfc-editor@rfc-editor.org" Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-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: Fri, 03 Mar 2017 21:15:11 -0000 SSBhc3N1bWUgdGhhdCB0aGUgZXh0LWNvbW0gcGFzc2VzIHBvbGljeS4NCg0KVGhhbmtzLA0KSmFr b2IuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogS2V5dXIgUGF0ZWwg W21haWx0bzprZXl1ckBhcnJjdXMuY29tXQ0KPiBTZW50OiBGcmlkYXksIE1hcmNoIDAzLCAyMDE3 IDEyOjQzIFBNDQo+IFRvOiBKYWtvYiBIZWl0eiAoamhlaXR6KSA8amhlaXR6QGNpc2NvLmNvbT47 IFRoZSBJRVNHIDxpZXNnLXNlY3JldGFyeUBpZXRmLm9yZz47IElFVEYtQW5ub3VuY2UgPGlldGYt DQo+IGFubm91bmNlQGlldGYub3JnPg0KPiBDYzogZHJhZnQtaWV0Zi1zaWRyLW9yaWdpbi12YWxp ZGF0aW9uLXNpZ25hbGluZ0BpZXRmLm9yZzsgc2lkckBpZXRmLm9yZzsgc2lkci1jaGFpcnNAaWV0 Zi5vcmc7IFRoZSBJRVNHDQo+IDxpZXNnQGlldGYub3JnPjsgc2FuZHlAdGlzbGFicy5jb207IHJm Yy1lZGl0b3JAcmZjLWVkaXRvci5vcmcNCj4gU3ViamVjdDogUmU6IFtzaWRyXSBQcm90b2NvbCBB Y3Rpb246ICdCR1AgUHJlZml4IE9yaWdpbiBWYWxpZGF0aW9uIFN0YXRlIEV4dGVuZGVkIENvbW11 bml0eScgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gKGRyYWZ0LWlldGYtc2lkci1vcmlnaW4tdmFs aWRhdGlvbi1zaWduYWxpbmctMTEudHh0KQ0KPiANCj4gSmFjb2IsDQo+IA0KPiBBcG9sb2dpZXMg Zm9yIHRoZSBkZWxheWVkIHJlc3BvbnNlLiBDb21tZW50cyAjS2V5dXINCj4gDQo+IE9uIDIvMjMv MTcsIDE6MjYgUE0sICJKYWtvYiBIZWl0eiAoamhlaXR6KSIgPGpoZWl0ekBjaXNjby5jb20+IHdy b3RlOg0KPiANCj4gICAgIFdoYXQgaGFwcGVucyBpZiBhIEJHUCBzcGVha2VyIHZhbGlkYXRlcyBh IHJvdXRlIGluIGl0cyBvd24gUlBLSSBkYXRhYmFzZQ0KPiAgICAgYW5kIGZpbmRzIGl0IHRvIGJl IGVpdGhlciBWYWxpZCBvciBJbnZhbGlkIChub3QgTm90Rm91bmQpIGFuZCBhbHNvIHJlY2VpdmVz DQo+ICAgICB0aGUgZXh0ZW5kZWQgY29tbXVuaXR5IHRoYXQgc3BlY2lmaWVzIGEgZGlmZmVyZW50 IHZhbGlkYXRpb24gc3RhdGU/DQo+IA0KPiAjS2V5dXI6IFRoYXQgcHJldHR5IG11Y2ggbWVhbnMg dGhhdCBpYmdwIHNwZWFrZXJzIGhhcyBvdXQgb2Ygc3luYyBycGtpIGRhdGEuIFRoaXMgY291bGQg dmVyeSB3ZWxsIGhhcHBlbiBpZiB0aGUgaWJncA0KPiBzcGVha2VycyBoYXZlIGRpZmZlcmVudCBy ZWZyZXNoIGludGVydmFscyBmb3IgcG9sbGluZyB0aGUgcnBraSBkYXRhIChvciBzb21lIGVycm9y IGhhcyBvY2N1cnJlZCB0aGF0IGhhcyByZXN1bHRlZA0KPiBpbnRvIGEgc3RhbGUgc3RhdGUpLg0K PiANCj4gICAgIEkgZG9uJ3Qgc2VlIHRoYXQgY29uZGl0aW9uIGNvdmVyZWQgaW4gdGhlIGRyYWZ0 Lg0KPiAgICAgSSB3b3VsZCBzYXkgdG8gaWdub3JlIHRoZSBleHRlbmRlZCBjb21tdW5pdHkuDQo+ IA0KPiAjS2V5dXI6IEkgYW0gbm90IHN1cmUgaWYgd2UgbmVlZCB0byBhZGQgYW55IHRleHQ/IEV4 dGVuZGVkIGNvbW11bml0eSBtYXBzIHRvIGEgcG9saWN5IG9uIGEgbiBpbmJvdW5kIHNpZGUuIFBv bGljeQ0KPiB3b3VsZCBkaWN0YXRlIGhvdyB5b3Ugd291bGQgd2FudCB0byB1c2UgdGhlIGNvbW11 bml0eS4gSW1wbGVtZW50YXRpb25zIGNvdWxkIGFsd2F5cyBsb2cgYW55IGNvbmZsaWN0aW5nIHJw a2kgc3RhdGUNCj4gdGhleSBlbmNvdW50ZXI/DQo+IA0KPiBSZWdhcmRzLA0KPiBLZXl1cg0KPiAN Cj4gICAgIFRoYW5rcywNCj4gICAgIEpha29iLg0KPiANCj4gICAgID4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gICAgID4gRnJvbTogc2lkciBbbWFpbHRvOnNpZHItYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIFRoZSBJRVNHDQo+ICAgICA+IFNlbnQ6IFdlZG5lc2RheSwgSmFu dWFyeSAxMSwgMjAxNyA3OjI1IEFNDQo+ICAgICA+IFRvOiBJRVRGLUFubm91bmNlIDxpZXRmLWFu bm91bmNlQGlldGYub3JnPg0KPiAgICAgPiBDYzogZHJhZnQtaWV0Zi1zaWRyLW9yaWdpbi12YWxp ZGF0aW9uLXNpZ25hbGluZ0BpZXRmLm9yZzsgc2lkckBpZXRmLm9yZzsgc2lkci1jaGFpcnNAaWV0 Zi5vcmc7IFRoZSBJRVNHDQo+ICAgICA+IDxpZXNnQGlldGYub3JnPjsgc2FuZHlAdGlzbGFicy5j b207IHJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmcNCj4gICAgID4gU3ViamVjdDogW3NpZHJdIFBy b3RvY29sIEFjdGlvbjogJ0JHUCBQcmVmaXggT3JpZ2luIFZhbGlkYXRpb24gU3RhdGUgRXh0ZW5k ZWQgQ29tbXVuaXR5JyB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiAgICAgPiAoZHJhZnQtaWV0Zi1z aWRyLW9yaWdpbi12YWxpZGF0aW9uLXNpZ25hbGluZy0xMS50eHQpDQo+ICAgICA+DQo+ICAgICA+ IFRoZSBJRVNHIGhhcyBhcHByb3ZlZCB0aGUgZm9sbG93aW5nIGRvY3VtZW50Og0KPiAgICAgPiAt ICdCR1AgUHJlZml4IE9yaWdpbiBWYWxpZGF0aW9uIFN0YXRlIEV4dGVuZGVkIENvbW11bml0eScN Cj4gICAgID4gICAoZHJhZnQtaWV0Zi1zaWRyLW9yaWdpbi12YWxpZGF0aW9uLXNpZ25hbGluZy0x MS50eHQpIGFzIFByb3Bvc2VkDQo+ICAgICA+IFN0YW5kYXJkDQo+ICAgICA+DQo+ICAgICA+IFRo aXMgZG9jdW1lbnQgaXMgdGhlIHByb2R1Y3Qgb2YgdGhlIFNlY3VyZSBJbnRlci1Eb21haW4gUm91 dGluZyBXb3JraW5nDQo+ICAgICA+IEdyb3VwLg0KPiAgICAgPg0KPiAgICAgPiBUaGUgSUVTRyBj b250YWN0IHBlcnNvbnMgYXJlIEFsdmFybyBSZXRhbmEsIEFsaWEgQXRsYXMgYW5kIERlYm9yYWgN Cj4gICAgID4gQnJ1bmdhcmQuDQo+ICAgICA+DQo+ICAgICA+IEEgVVJMIG9mIHRoaXMgSW50ZXJu ZXQgRHJhZnQgaXM6DQo+ICAgICA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtc2lkci1vcmlnaW4tdmFsaWRhdGlvbi1zaWduYWxpbmcvDQo+ICAgICA+DQo+ICAg ICA+DQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+IFRlY2huaWNhbCBTdW1tYXJ5 DQo+ICAgICA+DQo+ICAgICA+ICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBCR1Agb3Bh cXVlIGV4dGVuZGVkIGNvbW11bml0eSB0byBjYXJyeQ0KPiAgICAgPiAgICB0aGUgb3JpZ2luYXRp b24gQVMgdmFsaWRhdGlvbiBzdGF0ZSBpbnNpZGUgYW4gYXV0b25vbW91cyBzeXN0ZW0uDQo+ICAg ICA+ICAgIElCR1Agc3BlYWtlcnMgdGhhdCByZWNlaXZlIHRoaXMgdmFsaWRhdGlvbiBzdGF0ZSBj YW4gY29uZmlndXJlIGxvY2FsDQo+ICAgICA+ICAgIHBvbGljaWVzIGFsbG93aW5nIGl0IHRvIGlu Zmx1ZW5jZSB0aGVpciBkZWNpc2lvbiBwcm9jZXNzLg0KPiAgICAgPg0KPiAgICAgPiBXb3JraW5n IEdyb3VwIFN1bW1hcnkNCj4gICAgID4NCj4gICAgID4gICBUaGlzIGRvY3VtZW50IGhhcyBoYWQg Y29uc2lzdGVudCBpbnRlcmVzdCBmcm9tIHRoZSB3b3JraW5nIGdyb3VwLg0KPiAgICAgPiAgIEJl Y2F1c2UgaXQgZGVmaW5lcyBhIG5ldyBCR1AgY29tbXVuaXR5LCBpdCB3YXMgcmV2aWV3ZWQgYnkg dGhlIGlkcg0KPiAgICAgPiAgIHdvcmtpbmcgZ3JvdXAgYXMgd2VsbC4NCj4gICAgID4NCj4gICAg ID4gRG9jdW1lbnQgUXVhbGl0eQ0KPiAgICAgPg0KPiAgICAgPiAgIFRoZSBkb2N1bWVudCBoYXMg YmVlbiBpbXBsZW1lbnRlZCBieSBtYWpvciByb3V0ZXIgdmVuZG9ycy4NCj4gICAgID4gICBJdCBp cyBrbm93biB0byBiZSBpbiB1c2UgaW4gdHdvIGxhcmdlIElYUHMsIEFNUy1JWCBhbmQgREUtQ0lY Lg0KPiAgICAgPg0KPiAgICAgPiBQZXJzb25uZWwNCj4gICAgID4NCj4gICAgID4gICBEb2N1bWVu dCBTaGVwaGVyZDogU2FuZHJhIE11cnBoeQ0KPiAgICAgPiAgIFJlc3BvbnNpYmxlIEFyZWEgRGly ZWN0b3I6IEFsdmFybyBSZXRhbmENCj4gICAgID4NCj4gICAgID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgID4gc2lkciBtYWlsaW5nIGxpc3QN Cj4gICAgID4gc2lkckBpZXRmLm9yZw0KPiAgICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NpZHINCj4gDQoNCg== From nobody Fri Mar 3 13:56:23 2017 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 26B2712963B; Fri, 3 Mar 2017 13:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lNoIzFmqQya; Fri, 3 Mar 2017 13:56:19 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0108.outbound.protection.outlook.com [23.103.200.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55FBA12963A; Fri, 3 Mar 2017 13:56:19 -0800 (PST) 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=FATYJSMhHw1jExC3PtuP1/qQt5z5fzafBwHXMvBbxNI=; b=MWbrcxms435+YNiKVkYgaXdhUDJAa6UEBkGplU0hnLWc+viXj7n28OdnD0G15mJDDKb+Z2+swqi5HKyzsM0WRlT5j23RJzudzSzrkSMzxzofc7nd026P4o0WVHtt57cXIV4vxyOmbUH3OzYqra7jafqdqDeV18hFM35CjV9Kx7Q= Received: from BN6PR09MB1426.namprd09.prod.outlook.com (10.173.202.14) by BN6PR09MB1427.namprd09.prod.outlook.com (10.173.202.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Fri, 3 Mar 2017 21:56:17 +0000 Received: from BN6PR09MB1426.namprd09.prod.outlook.com ([10.173.202.14]) by BN6PR09MB1426.namprd09.prod.outlook.com ([10.173.202.14]) with mapi id 15.01.0919.022; Fri, 3 Mar 2017 21:56:17 +0000 From: "Montgomery, Douglas (Fed)" To: "Jakob Heitz (jheitz)" , "Alvaro Retana (aretana)" , "draft-ietf-sidr-origin-validation-signaling@ietf.org" Thread-Topic: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt) Thread-Index: AQHSbB8Sc+1j7EQgyk+BThT9XkihhaF3XtSAgAAICQCADBe3AIAAYZEA///FsoA= Importance: low X-Priority: 5 Date: Fri, 3 Mar 2017 21:56:17 +0000 Message-ID: References: <148414831932.11019.14685466226406323027.idtracker@ietfa.amsl.com> <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.140.29] x-microsoft-exchange-diagnostics: 1; BN6PR09MB1427; 7:N2DwXuHlaMBSv2ER05IxRcr9g66HrD3kxtdaq79FiZr+eK0Wd9sOFZ2eD68pRrYnUie6R3d6lsPYH4upsxPsMb5TOn0C7ou99QzaZkV96Q/9ff3Q28PiH4sAnwJX9HDhq5xTIac+XH/pb7ohjJLC9Uah21r6IDpxmMH5liisw92LRNHY+LuakdGWEW9L0Ln25e5jbktYlx/bcOW+hGOHUWKBjSwSv/KZbzfDG43T/RK3nl02jQhXzisAh1OvVdMjTzCMNHrVWzq33U1VrjGOnA2S01XhGHjmVRB22kRymVQdGDO2VEX5x2Qkj5Si4W66lyp+JiiJAER3zCayVTrnsQ== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39450400003)(39410400002)(39850400002)(39860400002)(13464003)(377454003)(24454002)(2900100001)(230783001)(5660300001)(93886004)(83506001)(92566002)(8936002)(3660700001)(2906002)(6116002)(102836003)(66066001)(4326008)(3280700002)(2501003)(54356999)(81686999)(76176999)(50986999)(81166006)(3846002)(8676002)(6306002)(106116001)(6506006)(2950100002)(6246003)(6436002)(36756003)(6512007)(189998001)(6486002)(99286003)(305945005)(77096006)(7736002)(53546006)(122556002)(25786008)(38730400002)(86362001)(54906002)(229853002)(4001350100001)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR09MB1427; H:BN6PR09MB1426.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: cf3c991a-d123-43e1-3305-08d462801ead x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR09MB1427; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(120809045254105)(95692535739014)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:BN6PR09MB1427; BCL:0; PCL:0; RULEID:; SRVR:BN6PR09MB1427; x-forefront-prvs: 0235CBE7D0 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2017 21:56:17.3513 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR09MB1427 Archived-At: Cc: "sidr@ietf.org" , "sidr-chairs@ietf.org" , "sandy@tislabs.com" Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-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: Fri, 03 Mar 2017 21:56:22 -0000 DQpPbiAzLzMvMTcsIDM6MjQgUE0sICJKYWtvYiBIZWl0eiAoamhlaXR6KSIgPGpoZWl0ekBjaXNj by5jb20+IHdyb3RlOg0KDQo+VGhlIGNhc2UgaXMgdW5saWtlbHksIGJ1dCBzb21ldGhpbmcgd2Ug bmVlZCB0byB3cml0ZSBjb2RlIGZvci4NCj5XaXRob3V0IGFuIGFuc3dlciwgdGhlbiB0aGUgdmFs aWRpdHkgd2lsbCBqdXN0IGJlIHNldCBieSB3aGljaGV2ZXINCj53YXMgc2V0IGxhc3QuIFRoYXQg d291bGQgbWFrZSBpdCBpbmRldGVybWluYXRlLg0KPg0KPlRoZSBjYXNlIGlzIGZvciBhIHNpbmds ZSByb3V0ZS4gVGhlcmUgaXMgbm8gc3VnZ2VzdGlvbiBvZiB0aGUgdmFsaWRpdHkNCj5vZiBvbmUg cm91dGUgYmVpbmcgdXNlZCB0byBzZXQgdmFsaWRpdHkgb2YgYW5vdGhlci4NCg0KQnkgc2luZ2xl IHJvdXRlLCBkbyB5b3UgbWVhbiBhbiB1cGRhdGUgZnJvbSBhIHNwZWNpZmljIGlCR1AgcGVlcj8g IE9yIGRvDQp5b3UgbWVhbiB1cGRhdGVzIGZyb20gdHdvIG9yIG1vcmUgaUJHUCBwZWVycz8NCg0K Pg0KPkEgcm91dGVyIG1heSBiZSBkb2luZyBsb2NhbCB2YWxpZGF0aW9uLCB1c2luZyBycGtpLXJ0 ciBwcm90b2NvbC4NCj5JbiBhZGRpdGlpb24sIGl0IG1heSByZWNlaXZlIGEgcm91dGUgd2l0aCBh IHZhbGlkYXRpb24gc3RhdGUgaW4NCj5hbiBleHRlbmRlZC1jb21tdW5pdHkuDQoNCkluIHRoaXMg Y2FzZSBhcmUgeW91IHNheWluZyB0aGUgcm91dGVyIGlzIGRvaW5nIG9yaWdpbiB2YWxpZGF0aW9u IG9uIGlCR1ANCnVwZGF0ZXMsIGV2ZW4gdGhvdWdoIHRoZXkgY29udGFpbiB0aGUgZXh0ZW5kZWQt Y29tbXVuaXR5Pw0KDQpJZiBzbywgSSB3b3VsZCBzdWdnZXN0IG9uZSBrZWVwL3VzZSB0aGUgbG9j YWxseSBjb21wdXRlZCB2YWxpZGF0aW9uIHN0YXRlLA0Kbm90IHRoZSBzaWduYWxlZCBzdGF0ZS4N Cg0KPg0KPlRoZSBxdWVzdGlvbiBpcyB3aGF0IHRvIGRvIGlmIG9uZSB2YWxpZGF0aW9uIG1ldGhv ZCBzYXN5cyAiaW52YWxpZCINCj5hbmQgdGhlIG90aGVyIHNheXMgInZhbGlkIi4NCj4NCj5UaGUg c2l0dWF0aW9uIG1heSBhcmlzZSBpZiB0aGUgcm91dGVyIHNlbmRpbmcgdGhlIGV4dGVuZGVkLWNv bW11bml0eQ0KPmlzIHVzaW5nIGEgZGlmZmVyZW50IHZhbGlkYXRpb24gbWV0aG9kLCBub3QgUlBL SS4NCg0KSXQgY2FuIGFsc28gaGFwcGVuIGlmIGFsbCByb3V0ZXJzIGFyZSBkb2luZyBSUEtJLCBi dXQgdGhlcmUgaXMgdHJhbnNpZW50DQpSUEtJIHN0YXRlIHNrZXcgYmV0d2VlbiBtdWx0aXBsZSB2 YWxpZGF0aW5nIGNhY2hlcywgbG9jYWwgU0xVUk0gcG9saWNpZXMsDQpldGMuDQoNCg0KPg0KPlRo YW5rcywNCj5KYWtvYi4NCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9t OiBNb250Z29tZXJ5LCBEb3VnbGFzIChGZWQpIFttYWlsdG86ZG91Z21AbmlzdC5nb3ZdDQo+PiBT ZW50OiBGcmlkYXksIE1hcmNoIDAzLCAyMDE3IDExOjM2IEFNDQo+PiBUbzogQWx2YXJvIFJldGFu YSAoYXJldGFuYSkgPGFyZXRhbmFAY2lzY28uY29tPjsgSmFrb2IgSGVpdHogKGpoZWl0eikNCj4+ PGpoZWl0ekBjaXNjby5jb20+OyBkcmFmdC1pZXRmLXNpZHItb3JpZ2luLQ0KPj4gdmFsaWRhdGlv bi1zaWduYWxpbmdAaWV0Zi5vcmcNCj4+IENjOiBzYW5keUB0aXNsYWJzLmNvbTsgc2lkci1jaGFp cnNAaWV0Zi5vcmc7IHNpZHJAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbc2lkcl0gUHJvdG9j b2wgQWN0aW9uOiAnQkdQIFByZWZpeCBPcmlnaW4gVmFsaWRhdGlvbg0KPj5TdGF0ZSBFeHRlbmRl ZCBDb21tdW5pdHknIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+PiAoZHJhZnQtaWV0Zi1zaWRyLW9y aWdpbi12YWxpZGF0aW9uLXNpZ25hbGluZy0xMS50eHQpDQo+PiBJbXBvcnRhbmNlOiBMb3cNCj4+ IA0KPj4gSSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgdGhlIG9yaWdpbmFsIHF1ZXN0aW9uL3Bv aW50IGFuZC9vciBBbHZhcm8ncw0KPj4gcmVzcG9uc2UuDQo+PiANCj4+IFRoZSBzcGVjIGluIHNl Y3Rpb24gMiBzYXlzOg0KPj4gDQo+PiDigJwuLi5TaW1pbGFybHkgb24gdGhlIHJlY2VpdmluZyBJ QkdQIHNwZWFrZXJzLCB0aGUgdmFsaWRhdGlvbiBzdGF0ZSBvZiBhbg0KPj4gSUJHUCByb3V0ZSBT SE9VTEQgYmUgZGVyaXZlZCBkaXJlY3RseSBmcm9tIHRoZSBsYXN0IG9jdGV0IG9mIHRoZQ0KPj5l eHRlbmRlZA0KPj4gY29tbXVuaXR5LCBpZiBwcmVzZW50LuKAnQ0KPj4gDQo+PiANCj4+IFRoYXQg c2VlbXMgbGlrZSBhIHN1Z2dlc3RlZCByZWNlaXZlIGxvZ2ljIOKApiBhbHRob3VnaCBpdCBpcyBh IFNIT1VMRC4gIE9mDQo+PiBjb3Vyc2UgaXQgaXMgc3RpbGwgdXAgdG8gbG9jYWwgcG9saWN5IGhv dyB0aGlzIHZhbGlkYXRpb24gc3RhdGUgZWZmZWN0cw0KPj4gdGhlIGRlY2lzaW9uIHByb2Nlc3Mu DQo+PiANCj4+IEkgdGhpbmsgaXQgd291bGQgYmUgYSBtaXN0YWtlIHRvIG1ha2Ugc29tZSBjaGFu Z2UgdGhhdCBzdWdnZXN0ZWQgdGhhdA0KPj50aGUNCj4+IHJlY2VpdmVkIHZhbGlkYXRpb24gc3Rh dGUgb24gYSBpQkdQIHVwZGF0ZSBzaG91bGQgc29tZWhvdyBpbmZsdWVuY2UgdGhlDQo+PiBjb21w dXRlZCBvcmlnaW4gdmFsaWRhdGlvbiBzdGF0ZSBvZiBvdGhlciByZWNlaXZlZCB1cGRhdGVzLiAg SW4NCj4+cGFydGljdWxhcg0KPj4gaW5mbHVlbmNpbmcgdGhlIHZhbGlkYXRpb24gc3RhdGUgb2Yg YW55IGxvY2FsbHkgdmFsaWRhdGVkIHVwZGF0ZXMuICBUaGUNCj4+IG9yaWdpbmFsIHF1ZXN0aW9u IHNlZW1zIHRvIHN1Z2dlc3QgdGhhdCBhIHJlY2VpdmVkIElOVkFMSUQgb3IgVkFMSUQNCj4+bWln aHQNCj4+IHN1cGVyc2VkZSBhIOKAnE5PVF9GT1VOROKAnS4gKHdhcyB0aGF0IHRoZSBzdWdnZXN0 aW9uPykgIFN1Y2ggYSBzaXR1YXRpb24NCj4+IHJlcHJlc2VudHMgYW4gUlBLSSBzdGF0ZSBza2V3 IGJldHdlZW4gdGhlIHR3byByb3V0ZXJzIChtaWdodCBqdXN0IGJlDQo+PiB0cmFuc2l0b3J5KSBi dXQgaXQgaXMgaW1wb3NzaWJsZSB0byB0ZWxsIGlmIHRoZSBJL1Ygb3IgdGhlIE5GIHJlcHJlc2Vu dHMNCj4+IHRoZSBtb3JlIOKAnHVwIHRvIGRhdGXigJ0gcmVzdWx0LiAgQWxzbyBoYXZpbmcgdGhl IG9yaWdpbiB2YWxpZGF0aW9uIHJlc3VsdHMNCj4+IG9mIGEgcm91dGVyIHRoYXQgaXMgZG9pbmcg T1Ygb3ZlcndyaXR0ZW4gYnkgc29tZSBvdGhlciByb3V0ZXIgKHBvc3NpYmx5DQo+PiBzeW5jZWQg dG8gYSBkaWZmZXJlbnQgdmFsaWRhdGluZyBjYWNoZSkgd2lsbCBtYWtlIGRlYnVnZ2luZyBPViBy ZXN1bHRzDQo+PiB2ZXJ5IGRpZmZpY3VsdC4NCj4+IA0KPj4gSW4gc2hvcnQsIGZvciBub3csIEkg d291bGQgbm90IGNoYW5nZSB0aGUgc3BlYy4gIFdpdGggc29tZSBvcGVyYXRpb25hbA0KPj4gZXhw ZXJpZW5jZSB3ZSBtaWdodCBmaW5kIHNvbWUgdXNlIGZvciBzaW1pbGFyIGZ1bmN0aW9uYWxpdHkg KEkgd29uZGVyIGlmDQo+PiBieSBOT1RfRk9VTkQgeW91IG1lYW50IG5vdCB2YWxpZGF0ZWQpIGJ1 dCBmb3Igbm93LCBJIHdvdWxkIG5vdCBjaGFuZ2UNCj4+aXQuDQo+PiANCj4+IGRvdWdtDQo+PiDi gJQNCj4+IERvdWcgTW9udGdvbWVyeSwgTWdyIEludGVybmV0ICYgU2NhbGFibGUgU3lzdGVtcyBS ZXNlYXJjaCBhdA0KPj5OSVNUL0lUTC9BTlREDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4g T24gMi8yMy8xNywgNDo1NSBQTSwgInNpZHIgb24gYmVoYWxmIG9mIEFsdmFybyBSZXRhbmEgKGFy ZXRhbmEpIg0KPj4gPHNpZHItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgYXJldGFuYUBj aXNjby5jb20+IHdyb3RlOg0KPj4gDQo+PiA+W1Rvb2sgdGhlIElFU0csIGlldGYtYW5ub3VuY2Ug YW5kIHJmYy1lZGl0b3IgbGlzdHMgb2ZmLl0NCj4+ID4NCj4+ID5KYWtvYjoNCj4+ID4NCj4+ID5I aSENCj4+ID4NCj4+ID5UaGlzIGRvY3VtZW50IGlzIGFscmVhZHkgaW4gQVVUSDQ4LiAgSSBkb27i gJl0IHRoaW5rIHdlIG5lZWQgdG8gbWFrZSBhbnkNCj4+ID5jaGFuZ2VzIHRvIHRoZSBkb2N1bWVu dCwgYnV0IGlmIHdlIGRvLCB3ZSBuZWVkIHRvIGRlY2lkZSB2ZXJ5IHNvb24uDQo+PiA+DQo+PiA+ VGhlIGRvY3VtZW50IGRvZXNu4oCZdCBzYXkgYW55dGhpbmcgYWJvdXQgd2hhdCBzaG91bGQgYmUg ZG9uZSB3aXRoIHRoaXMNCj4+ID5leHRlbmRlZCBjb21tdW5pdHksIGV4Y2VwdCB0byBzYXkgdGhh dCDigJxzcGVha2VycyB0aGF0IHJlY2VpdmUgdGhpcw0KPj4gPnZhbGlkYXRpb24gc3RhdGUgY2Fu IGNvbmZpZ3VyZSBsb2NhbCBwb2xpY2llcyBhbGxvd2luZyBpdCB0byBpbmZsdWVuY2UNCj4+ID50 aGVpciBkZWNpc2lvbiBwcm9jZXNzLuKAnSAgSU9XLCB0aGVyZSBpcyBubyBleHBlY3RlZCBkZWZh dWx0IHByb2Nlc3NpbmcNCj4+b2YNCj4+ID50aGUgdmFsaWRhdGlvbiBzdGF0ZS4NCj4+ID4NCj4+ ID5JZiB0aGUgY29tbXVuaXR5IGlzIHJlY2VpdmVkIGFuZCB0aGUgcm91dGVyIGFsc28gaGFzIHZh bGlkYXRpb24NCj4+ID5pbmZvcm1hdGlvbiwgdGhlbiBJIGFncmVlIHRoYXQgdGhlIGV4dGVuZGVk IGNvbW11bml0eSBpcyBub3QNCj4+bmVlZGVk4oCmYnV0IEkNCj4+ID50aGluayB0aGF0IGFjdGlv biBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KPj4gPg0KPj4gPlRoYW5r cyENCj4+ID4NCj4+ID5BbHZhcm8uDQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+T24gMi8y My8xNywgNDoyNiBQTSwgImllc2cgb24gYmVoYWxmIG9mIEpha29iIEhlaXR6IChqaGVpdHopIg0K Pj4gPjxpZXNnLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGpoZWl0ekBjaXNjby5jb20+ IHdyb3RlOg0KPj4gPg0KPj4gPiAgICBXaGF0IGhhcHBlbnMgaWYgYSBCR1Agc3BlYWtlciB2YWxp ZGF0ZXMgYSByb3V0ZSBpbiBpdHMgb3duIFJQS0kNCj4+ID5kYXRhYmFzZQ0KPj4gPiAgICBhbmQg ZmluZHMgaXQgdG8gYmUgZWl0aGVyIFZhbGlkIG9yIEludmFsaWQgKG5vdCBOb3RGb3VuZCkgYW5k IGFsc28NCj4+ID5yZWNlaXZlcw0KPj4gPiAgICB0aGUgZXh0ZW5kZWQgY29tbXVuaXR5IHRoYXQg c3BlY2lmaWVzIGEgZGlmZmVyZW50IHZhbGlkYXRpb24gc3RhdGU/DQo+PiA+DQo+PiA+ICAgIEkg ZG9uJ3Qgc2VlIHRoYXQgY29uZGl0aW9uIGNvdmVyZWQgaW4gdGhlIGRyYWZ0Lg0KPj4gPiAgICBJ IHdvdWxkIHNheSB0byBpZ25vcmUgdGhlIGV4dGVuZGVkIGNvbW11bml0eS4NCj4+ID4NCj4+ID4g ICAgVGhhbmtzLA0KPj4gPiAgICBKYWtvYi4NCj4+ID4NCj4+ID4gICAgPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4gPiAgICA+IEZyb206IHNpZHIgW21haWx0bzpzaWRyLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUaGUgSUVTRw0KPj4gPiAgICA+IFNlbnQ6IFdlZG5lc2Rh eSwgSmFudWFyeSAxMSwgMjAxNyA3OjI1IEFNDQo+PiA+ICAgID4gVG86IElFVEYtQW5ub3VuY2Ug PGlldGYtYW5ub3VuY2VAaWV0Zi5vcmc+DQo+PiA+ICAgID4gQ2M6IGRyYWZ0LWlldGYtc2lkci1v cmlnaW4tdmFsaWRhdGlvbi1zaWduYWxpbmdAaWV0Zi5vcmc7DQo+PiA+c2lkckBpZXRmLm9yZzsg c2lkci1jaGFpcnNAaWV0Zi5vcmc7IFRoZSBJRVNHDQo+PiA+ICAgID4gPGllc2dAaWV0Zi5vcmc+ OyBzYW5keUB0aXNsYWJzLmNvbTsgcmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZw0KPj4gPiAgICA+ IFN1YmplY3Q6IFtzaWRyXSBQcm90b2NvbCBBY3Rpb246ICdCR1AgUHJlZml4IE9yaWdpbiBWYWxp ZGF0aW9uDQo+PiA+U3RhdGUgRXh0ZW5kZWQgQ29tbXVuaXR5JyB0byBQcm9wb3NlZCBTdGFuZGFy ZA0KPj4gPiAgICA+IChkcmFmdC1pZXRmLXNpZHItb3JpZ2luLXZhbGlkYXRpb24tc2lnbmFsaW5n LTExLnR4dCkNCj4+ID4gICAgPg0KPj4gPiAgICA+IFRoZSBJRVNHIGhhcyBhcHByb3ZlZCB0aGUg Zm9sbG93aW5nIGRvY3VtZW50Og0KPj4gPiAgICA+IC0gJ0JHUCBQcmVmaXggT3JpZ2luIFZhbGlk YXRpb24gU3RhdGUgRXh0ZW5kZWQgQ29tbXVuaXR5Jw0KPj4gPiAgICA+ICAgKGRyYWZ0LWlldGYt c2lkci1vcmlnaW4tdmFsaWRhdGlvbi1zaWduYWxpbmctMTEudHh0KSBhcw0KPj5Qcm9wb3NlZA0K Pj4gPiAgICA+IFN0YW5kYXJkDQo+PiA+ICAgID4NCj4+ID4gICAgPiBUaGlzIGRvY3VtZW50IGlz IHRoZSBwcm9kdWN0IG9mIHRoZSBTZWN1cmUgSW50ZXItRG9tYWluIFJvdXRpbmcNCj4+ID5Xb3Jr aW5nDQo+PiA+ICAgID4gR3JvdXAuDQo+PiA+ICAgID4NCj4+ID4gICAgPiBUaGUgSUVTRyBjb250 YWN0IHBlcnNvbnMgYXJlIEFsdmFybyBSZXRhbmEsIEFsaWEgQXRsYXMgYW5kDQo+PkRlYm9yYWgN Cj4+ID4gICAgPiBCcnVuZ2FyZC4NCj4+ID4gICAgPg0KPj4gPiAgICA+IEEgVVJMIG9mIHRoaXMg SW50ZXJuZXQgRHJhZnQgaXM6DQo+PiA+ICAgID4NCj4+IA0KPj4+aHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zaWRyLW9yaWdpbi12YWxpZGF0aW9uLXNpZ25hDQo+ Pj5saQ0KPj4gPm5nLw0KPj4gPiAgICA+DQo+PiA+ICAgID4NCj4+ID4gICAgPg0KPj4gPiAgICA+ DQo+PiA+ICAgID4NCj4+ID4gICAgPiBUZWNobmljYWwgU3VtbWFyeQ0KPj4gPiAgICA+DQo+PiA+ ICAgID4gICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IEJHUCBvcGFxdWUgZXh0ZW5kZWQg Y29tbXVuaXR5IHRvDQo+PiA+Y2FycnkNCj4+ID4gICAgPiAgICB0aGUgb3JpZ2luYXRpb24gQVMg dmFsaWRhdGlvbiBzdGF0ZSBpbnNpZGUgYW4gYXV0b25vbW91cw0KPj5zeXN0ZW0uDQo+PiA+ICAg ID4gICAgSUJHUCBzcGVha2VycyB0aGF0IHJlY2VpdmUgdGhpcyB2YWxpZGF0aW9uIHN0YXRlIGNh biBjb25maWd1cmUNCj4+ID5sb2NhbA0KPj4gPiAgICA+ICAgIHBvbGljaWVzIGFsbG93aW5nIGl0 IHRvIGluZmx1ZW5jZSB0aGVpciBkZWNpc2lvbiBwcm9jZXNzLg0KPj4gPiAgICA+DQo+PiA+ICAg ID4gV29ya2luZyBHcm91cCBTdW1tYXJ5DQo+PiA+ICAgID4NCj4+ID4gICAgPiAgIFRoaXMgZG9j dW1lbnQgaGFzIGhhZCBjb25zaXN0ZW50IGludGVyZXN0IGZyb20gdGhlIHdvcmtpbmcNCj4+Z3Jv dXAuDQo+PiA+ICAgID4gICBCZWNhdXNlIGl0IGRlZmluZXMgYSBuZXcgQkdQIGNvbW11bml0eSwg aXQgd2FzIHJldmlld2VkIGJ5IHRoZQ0KPj5pZHINCj4+ID4gICAgPiAgIHdvcmtpbmcgZ3JvdXAg YXMgd2VsbC4NCj4+ID4gICAgPg0KPj4gPiAgICA+IERvY3VtZW50IFF1YWxpdHkNCj4+ID4gICAg Pg0KPj4gPiAgICA+ICAgVGhlIGRvY3VtZW50IGhhcyBiZWVuIGltcGxlbWVudGVkIGJ5IG1ham9y IHJvdXRlciB2ZW5kb3JzLg0KPj4gPiAgICA+ICAgSXQgaXMga25vd24gdG8gYmUgaW4gdXNlIGlu IHR3byBsYXJnZSBJWFBzLCBBTVMtSVggYW5kIERFLUNJWC4NCj4+ID4gICAgPg0KPj4gPiAgICA+ IFBlcnNvbm5lbA0KPj4gPiAgICA+DQo+PiA+ICAgID4gICBEb2N1bWVudCBTaGVwaGVyZDogU2Fu ZHJhIE11cnBoeQ0KPj4gPiAgICA+ICAgUmVzcG9uc2libGUgQXJlYSBEaXJlY3RvcjogQWx2YXJv IFJldGFuYQ0KPj4gPiAgICA+DQo+PiA+ICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+ID4gICAgPiBzaWRyIG1haWxpbmcgbGlzdA0KPj4gPiAg ICA+IHNpZHJAaWV0Zi5vcmcNCj4+ID4gICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NpZHINCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPnNpZHIgbWFpbGluZyBsaXN0DQo+PiA+ c2lkckBpZXRmLm9yZw0KPj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2lkcg0KPg0KDQo= From nobody Fri Mar 3 14:16:20 2017 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 5547D12965A; Fri, 3 Mar 2017 14:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24l3Ed7Yx8ss; Fri, 3 Mar 2017 14:16:17 -0800 (PST) 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 CA4C3129650; Fri, 3 Mar 2017 14:16:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12230; q=dns/txt; s=iport; t=1488579376; x=1489788976; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wIXK0U2rlHdGEouuJvL7BaxwsuYiXjsTrDn7N7EhqdI=; b=iGLpmoW8ay87X3YuebUmyIWzrH0db/vzbB5P+2OS0jQx7A7tQkLClnEd 3FNgs6NZWPELIoscgiAKUl3aB+khLT0phAhA9EBDc8EryWSltkP5BcBjX HA8198C04SKKP9dEiOpQqCXX0ugwCQu8q4xC5WPkTx19NLBXZTmP+drQG c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CVAQDD6rlY/49dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQoHg1eKDJFGlTeCDR8NhXYCGoJMPxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?wAQEBAwEBASEROgsFBwQCAQgRBAEBAQICHwQDAgICJQsUAQgIAgQBDQUIDIlfC?= =?us-ascii?q?A6zOoImiwEBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELhUOEb4Rrgm+CXwWVdYY?= =?us-ascii?q?3AYZ1izSCBI8kiEOKdwEfOFgrVhU/hQqBSnaHUyuBA4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.35,239,1484006400"; d="scan'208";a="213664223" 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; 03 Mar 2017 22:15:54 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v23MFsfG030426 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 Mar 2017 22:15:54 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 3 Mar 2017 16:15:54 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Fri, 3 Mar 2017 16:15:54 -0600 From: "Jakob Heitz (jheitz)" To: "Montgomery, Douglas (Fed)" , "Alvaro Retana (aretana)" , "draft-ietf-sidr-origin-validation-signaling@ietf.org" Thread-Topic: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt) Thread-Index: AQHSbB8KL4goLDO+zUCyR+oqQEK9nqF2Wu8wgAEcsQCADL9tgP//pOHggACCYID//5/aYA== Date: Fri, 3 Mar 2017 22:15:54 +0000 Message-ID: <5a95316b20e840749135658a9c67444c@XCH-ALN-014.cisco.com> References: <148414831932.11019.14685466226406323027.idtracker@ietfa.amsl.com> <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.90.253] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sidr@ietf.org" , "sandy@tislabs.com" Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-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: Fri, 03 Mar 2017 22:16:19 -0000 VGhhbmtzLiBUaGlzIGlzIHRoZSBwYXJ0IEkgd2FzIGxvb2tpbmcgZm9yOg0KDQo+IEkgd291bGQg c3VnZ2VzdCBvbmUga2VlcC91c2UgdGhlIGxvY2FsbHkgY29tcHV0ZWQgdmFsaWRhdGlvbiBzdGF0 ZSwNCj4gbm90IHRoZSBzaWduYWxlZCBzdGF0ZS4NCg0KSmFrb2IuDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTW9udGdvbWVyeSwgRG91Z2xhcyAoRmVkKSBbbWFpbHRv OmRvdWdtQG5pc3QuZ292XQ0KPiBTZW50OiBGcmlkYXksIE1hcmNoIDAzLCAyMDE3IDE6NTYgUE0N Cj4gVG86IEpha29iIEhlaXR6IChqaGVpdHopIDxqaGVpdHpAY2lzY28uY29tPjsgQWx2YXJvIFJl dGFuYSAoYXJldGFuYSkgPGFyZXRhbmFAY2lzY28uY29tPjsgZHJhZnQtaWV0Zi1zaWRyLW9yaWdp bi0NCj4gdmFsaWRhdGlvbi1zaWduYWxpbmdAaWV0Zi5vcmcNCj4gQ2M6IHNhbmR5QHRpc2xhYnMu Y29tOyBzaWRyLWNoYWlyc0BpZXRmLm9yZzsgc2lkckBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog W3NpZHJdIFByb3RvY29sIEFjdGlvbjogJ0JHUCBQcmVmaXggT3JpZ2luIFZhbGlkYXRpb24gU3Rh dGUgRXh0ZW5kZWQgQ29tbXVuaXR5JyB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiAoZHJhZnQtaWV0 Zi1zaWRyLW9yaWdpbi12YWxpZGF0aW9uLXNpZ25hbGluZy0xMS50eHQpDQo+IEltcG9ydGFuY2U6 IExvdw0KPiANCj4gDQo+IE9uIDMvMy8xNywgMzoyNCBQTSwgIkpha29iIEhlaXR6IChqaGVpdHop IiA8amhlaXR6QGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPiA+VGhlIGNhc2UgaXMgdW5saWtlbHks IGJ1dCBzb21ldGhpbmcgd2UgbmVlZCB0byB3cml0ZSBjb2RlIGZvci4NCj4gPldpdGhvdXQgYW4g YW5zd2VyLCB0aGVuIHRoZSB2YWxpZGl0eSB3aWxsIGp1c3QgYmUgc2V0IGJ5IHdoaWNoZXZlcg0K PiA+d2FzIHNldCBsYXN0LiBUaGF0IHdvdWxkIG1ha2UgaXQgaW5kZXRlcm1pbmF0ZS4NCj4gPg0K PiA+VGhlIGNhc2UgaXMgZm9yIGEgc2luZ2xlIHJvdXRlLiBUaGVyZSBpcyBubyBzdWdnZXN0aW9u IG9mIHRoZSB2YWxpZGl0eQ0KPiA+b2Ygb25lIHJvdXRlIGJlaW5nIHVzZWQgdG8gc2V0IHZhbGlk aXR5IG9mIGFub3RoZXIuDQo+IA0KPiBCeSBzaW5nbGUgcm91dGUsIGRvIHlvdSBtZWFuIGFuIHVw ZGF0ZSBmcm9tIGEgc3BlY2lmaWMgaUJHUCBwZWVyPyAgT3IgZG8NCj4geW91IG1lYW4gdXBkYXRl cyBmcm9tIHR3byBvciBtb3JlIGlCR1AgcGVlcnM/DQo+IA0KPiA+DQo+ID5BIHJvdXRlciBtYXkg YmUgZG9pbmcgbG9jYWwgdmFsaWRhdGlvbiwgdXNpbmcgcnBraS1ydHIgcHJvdG9jb2wuDQo+ID5J biBhZGRpdGlpb24sIGl0IG1heSByZWNlaXZlIGEgcm91dGUgd2l0aCBhIHZhbGlkYXRpb24gc3Rh dGUgaW4NCj4gPmFuIGV4dGVuZGVkLWNvbW11bml0eS4NCj4gDQo+IEluIHRoaXMgY2FzZSBhcmUg eW91IHNheWluZyB0aGUgcm91dGVyIGlzIGRvaW5nIG9yaWdpbiB2YWxpZGF0aW9uIG9uIGlCR1AN Cj4gdXBkYXRlcywgZXZlbiB0aG91Z2ggdGhleSBjb250YWluIHRoZSBleHRlbmRlZC1jb21tdW5p dHk/DQo+IA0KPiBJZiBzbywgSSB3b3VsZCBzdWdnZXN0IG9uZSBrZWVwL3VzZSB0aGUgbG9jYWxs eSBjb21wdXRlZCB2YWxpZGF0aW9uIHN0YXRlLA0KPiBub3QgdGhlIHNpZ25hbGVkIHN0YXRlLg0K PiANCj4gPg0KPiA+VGhlIHF1ZXN0aW9uIGlzIHdoYXQgdG8gZG8gaWYgb25lIHZhbGlkYXRpb24g bWV0aG9kIHNhc3lzICJpbnZhbGlkIg0KPiA+YW5kIHRoZSBvdGhlciBzYXlzICJ2YWxpZCIuDQo+ ID4NCj4gPlRoZSBzaXR1YXRpb24gbWF5IGFyaXNlIGlmIHRoZSByb3V0ZXIgc2VuZGluZyB0aGUg ZXh0ZW5kZWQtY29tbXVuaXR5DQo+ID5pcyB1c2luZyBhIGRpZmZlcmVudCB2YWxpZGF0aW9uIG1l dGhvZCwgbm90IFJQS0kuDQo+IA0KPiBJdCBjYW4gYWxzbyBoYXBwZW4gaWYgYWxsIHJvdXRlcnMg YXJlIGRvaW5nIFJQS0ksIGJ1dCB0aGVyZSBpcyB0cmFuc2llbnQNCj4gUlBLSSBzdGF0ZSBza2V3 IGJldHdlZW4gbXVsdGlwbGUgdmFsaWRhdGluZyBjYWNoZXMsIGxvY2FsIFNMVVJNIHBvbGljaWVz LA0KPiBldGMuDQo+IA0KPiANCj4gPg0KPiA+VGhhbmtzLA0KPiA+SmFrb2IuDQo+ID4NCj4gPj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogTW9udGdvbWVyeSwgRG91Z2xh cyAoRmVkKSBbbWFpbHRvOmRvdWdtQG5pc3QuZ292XQ0KPiA+PiBTZW50OiBGcmlkYXksIE1hcmNo IDAzLCAyMDE3IDExOjM2IEFNDQo+ID4+IFRvOiBBbHZhcm8gUmV0YW5hIChhcmV0YW5hKSA8YXJl dGFuYUBjaXNjby5jb20+OyBKYWtvYiBIZWl0eiAoamhlaXR6KQ0KPiA+PjxqaGVpdHpAY2lzY28u Y29tPjsgZHJhZnQtaWV0Zi1zaWRyLW9yaWdpbi0NCj4gPj4gdmFsaWRhdGlvbi1zaWduYWxpbmdA aWV0Zi5vcmcNCj4gPj4gQ2M6IHNhbmR5QHRpc2xhYnMuY29tOyBzaWRyLWNoYWlyc0BpZXRmLm9y Zzsgc2lkckBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW3NpZHJdIFByb3RvY29sIEFjdGlv bjogJ0JHUCBQcmVmaXggT3JpZ2luIFZhbGlkYXRpb24NCj4gPj5TdGF0ZSBFeHRlbmRlZCBDb21t dW5pdHknIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4+IChkcmFmdC1pZXRmLXNpZHItb3JpZ2lu LXZhbGlkYXRpb24tc2lnbmFsaW5nLTExLnR4dCkNCj4gPj4gSW1wb3J0YW5jZTogTG93DQo+ID4+ DQo+ID4+IEkgYW0gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHRoZSBvcmlnaW5hbCBxdWVzdGlvbi9w b2ludCBhbmQvb3IgQWx2YXJvJ3MNCj4gPj4gcmVzcG9uc2UuDQo+ID4+DQo+ID4+IFRoZSBzcGVj IGluIHNlY3Rpb24gMiBzYXlzOg0KPiA+Pg0KPiA+PiDigJwuLi5TaW1pbGFybHkgb24gdGhlIHJl Y2VpdmluZyBJQkdQIHNwZWFrZXJzLCB0aGUgdmFsaWRhdGlvbiBzdGF0ZSBvZiBhbg0KPiA+PiBJ QkdQIHJvdXRlIFNIT1VMRCBiZSBkZXJpdmVkIGRpcmVjdGx5IGZyb20gdGhlIGxhc3Qgb2N0ZXQg b2YgdGhlDQo+ID4+ZXh0ZW5kZWQNCj4gPj4gY29tbXVuaXR5LCBpZiBwcmVzZW50LuKAnQ0KPiA+ Pg0KPiA+Pg0KPiA+PiBUaGF0IHNlZW1zIGxpa2UgYSBzdWdnZXN0ZWQgcmVjZWl2ZSBsb2dpYyDi gKYgYWx0aG91Z2ggaXQgaXMgYSBTSE9VTEQuICBPZg0KPiA+PiBjb3Vyc2UgaXQgaXMgc3RpbGwg dXAgdG8gbG9jYWwgcG9saWN5IGhvdyB0aGlzIHZhbGlkYXRpb24gc3RhdGUgZWZmZWN0cw0KPiA+ PiB0aGUgZGVjaXNpb24gcHJvY2Vzcy4NCj4gPj4NCj4gPj4gSSB0aGluayBpdCB3b3VsZCBiZSBh IG1pc3Rha2UgdG8gbWFrZSBzb21lIGNoYW5nZSB0aGF0IHN1Z2dlc3RlZCB0aGF0DQo+ID4+dGhl DQo+ID4+IHJlY2VpdmVkIHZhbGlkYXRpb24gc3RhdGUgb24gYSBpQkdQIHVwZGF0ZSBzaG91bGQg c29tZWhvdyBpbmZsdWVuY2UgdGhlDQo+ID4+IGNvbXB1dGVkIG9yaWdpbiB2YWxpZGF0aW9uIHN0 YXRlIG9mIG90aGVyIHJlY2VpdmVkIHVwZGF0ZXMuICBJbg0KPiA+PnBhcnRpY3VsYXINCj4gPj4g aW5mbHVlbmNpbmcgdGhlIHZhbGlkYXRpb24gc3RhdGUgb2YgYW55IGxvY2FsbHkgdmFsaWRhdGVk IHVwZGF0ZXMuICBUaGUNCj4gPj4gb3JpZ2luYWwgcXVlc3Rpb24gc2VlbXMgdG8gc3VnZ2VzdCB0 aGF0IGEgcmVjZWl2ZWQgSU5WQUxJRCBvciBWQUxJRA0KPiA+Pm1pZ2h0DQo+ID4+IHN1cGVyc2Vk ZSBhIOKAnE5PVF9GT1VOROKAnS4gKHdhcyB0aGF0IHRoZSBzdWdnZXN0aW9uPykgIFN1Y2ggYSBz aXR1YXRpb24NCj4gPj4gcmVwcmVzZW50cyBhbiBSUEtJIHN0YXRlIHNrZXcgYmV0d2VlbiB0aGUg dHdvIHJvdXRlcnMgKG1pZ2h0IGp1c3QgYmUNCj4gPj4gdHJhbnNpdG9yeSkgYnV0IGl0IGlzIGlt cG9zc2libGUgdG8gdGVsbCBpZiB0aGUgSS9WIG9yIHRoZSBORiByZXByZXNlbnRzDQo+ID4+IHRo ZSBtb3JlIOKAnHVwIHRvIGRhdGXigJ0gcmVzdWx0LiAgQWxzbyBoYXZpbmcgdGhlIG9yaWdpbiB2 YWxpZGF0aW9uIHJlc3VsdHMNCj4gPj4gb2YgYSByb3V0ZXIgdGhhdCBpcyBkb2luZyBPViBvdmVy d3JpdHRlbiBieSBzb21lIG90aGVyIHJvdXRlciAocG9zc2libHkNCj4gPj4gc3luY2VkIHRvIGEg ZGlmZmVyZW50IHZhbGlkYXRpbmcgY2FjaGUpIHdpbGwgbWFrZSBkZWJ1Z2dpbmcgT1YgcmVzdWx0 cw0KPiA+PiB2ZXJ5IGRpZmZpY3VsdC4NCj4gPj4NCj4gPj4gSW4gc2hvcnQsIGZvciBub3csIEkg d291bGQgbm90IGNoYW5nZSB0aGUgc3BlYy4gIFdpdGggc29tZSBvcGVyYXRpb25hbA0KPiA+PiBl eHBlcmllbmNlIHdlIG1pZ2h0IGZpbmQgc29tZSB1c2UgZm9yIHNpbWlsYXIgZnVuY3Rpb25hbGl0 eSAoSSB3b25kZXIgaWYNCj4gPj4gYnkgTk9UX0ZPVU5EIHlvdSBtZWFudCBub3QgdmFsaWRhdGVk KSBidXQgZm9yIG5vdywgSSB3b3VsZCBub3QgY2hhbmdlDQo+ID4+aXQuDQo+ID4+DQo+ID4+IGRv dWdtDQo+ID4+IOKAlA0KPiA+PiBEb3VnIE1vbnRnb21lcnksIE1nciBJbnRlcm5ldCAmIFNjYWxh YmxlIFN5c3RlbXMgUmVzZWFyY2ggYXQNCj4gPj5OSVNUL0lUTC9BTlREDQo+ID4+DQo+ID4+DQo+ ID4+DQo+ID4+DQo+ID4+DQo+ID4+IE9uIDIvMjMvMTcsIDQ6NTUgUE0sICJzaWRyIG9uIGJlaGFs ZiBvZiBBbHZhcm8gUmV0YW5hIChhcmV0YW5hKSINCj4gPj4gPHNpZHItYm91bmNlc0BpZXRmLm9y ZyBvbiBiZWhhbGYgb2YgYXJldGFuYUBjaXNjby5jb20+IHdyb3RlOg0KPiA+Pg0KPiA+PiA+W1Rv b2sgdGhlIElFU0csIGlldGYtYW5ub3VuY2UgYW5kIHJmYy1lZGl0b3IgbGlzdHMgb2ZmLl0NCj4g Pj4gPg0KPiA+PiA+SmFrb2I6DQo+ID4+ID4NCj4gPj4gPkhpIQ0KPiA+PiA+DQo+ID4+ID5UaGlz IGRvY3VtZW50IGlzIGFscmVhZHkgaW4gQVVUSDQ4LiAgSSBkb27igJl0IHRoaW5rIHdlIG5lZWQg dG8gbWFrZSBhbnkNCj4gPj4gPmNoYW5nZXMgdG8gdGhlIGRvY3VtZW50LCBidXQgaWYgd2UgZG8s IHdlIG5lZWQgdG8gZGVjaWRlIHZlcnkgc29vbi4NCj4gPj4gPg0KPiA+PiA+VGhlIGRvY3VtZW50 IGRvZXNu4oCZdCBzYXkgYW55dGhpbmcgYWJvdXQgd2hhdCBzaG91bGQgYmUgZG9uZSB3aXRoIHRo aXMNCj4gPj4gPmV4dGVuZGVkIGNvbW11bml0eSwgZXhjZXB0IHRvIHNheSB0aGF0IOKAnHNwZWFr ZXJzIHRoYXQgcmVjZWl2ZSB0aGlzDQo+ID4+ID52YWxpZGF0aW9uIHN0YXRlIGNhbiBjb25maWd1 cmUgbG9jYWwgcG9saWNpZXMgYWxsb3dpbmcgaXQgdG8gaW5mbHVlbmNlDQo+ID4+ID50aGVpciBk ZWNpc2lvbiBwcm9jZXNzLuKAnSAgSU9XLCB0aGVyZSBpcyBubyBleHBlY3RlZCBkZWZhdWx0IHBy b2Nlc3NpbmcNCj4gPj5vZg0KPiA+PiA+dGhlIHZhbGlkYXRpb24gc3RhdGUuDQo+ID4+ID4NCj4g Pj4gPklmIHRoZSBjb21tdW5pdHkgaXMgcmVjZWl2ZWQgYW5kIHRoZSByb3V0ZXIgYWxzbyBoYXMg dmFsaWRhdGlvbg0KPiA+PiA+aW5mb3JtYXRpb24sIHRoZW4gSSBhZ3JlZSB0aGF0IHRoZSBleHRl bmRlZCBjb21tdW5pdHkgaXMgbm90DQo+ID4+bmVlZGVk4oCmYnV0IEkNCj4gPj4gPnRoaW5rIHRo YXQgYWN0aW9uIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQo+ID4+ID4N Cj4gPj4gPlRoYW5rcyENCj4gPj4gPg0KPiA+PiA+QWx2YXJvLg0KPiA+PiA+DQo+ID4+ID4NCj4g Pj4gPg0KPiA+PiA+DQo+ID4+ID5PbiAyLzIzLzE3LCA0OjI2IFBNLCAiaWVzZyBvbiBiZWhhbGYg b2YgSmFrb2IgSGVpdHogKGpoZWl0eikiDQo+ID4+ID48aWVzZy1ib3VuY2VzQGlldGYub3JnIG9u IGJlaGFsZiBvZiBqaGVpdHpAY2lzY28uY29tPiB3cm90ZToNCj4gPj4gPg0KPiA+PiA+ICAgIFdo YXQgaGFwcGVucyBpZiBhIEJHUCBzcGVha2VyIHZhbGlkYXRlcyBhIHJvdXRlIGluIGl0cyBvd24g UlBLSQ0KPiA+PiA+ZGF0YWJhc2UNCj4gPj4gPiAgICBhbmQgZmluZHMgaXQgdG8gYmUgZWl0aGVy IFZhbGlkIG9yIEludmFsaWQgKG5vdCBOb3RGb3VuZCkgYW5kIGFsc28NCj4gPj4gPnJlY2VpdmVz DQo+ID4+ID4gICAgdGhlIGV4dGVuZGVkIGNvbW11bml0eSB0aGF0IHNwZWNpZmllcyBhIGRpZmZl cmVudCB2YWxpZGF0aW9uIHN0YXRlPw0KPiA+PiA+DQo+ID4+ID4gICAgSSBkb24ndCBzZWUgdGhh dCBjb25kaXRpb24gY292ZXJlZCBpbiB0aGUgZHJhZnQuDQo+ID4+ID4gICAgSSB3b3VsZCBzYXkg dG8gaWdub3JlIHRoZSBleHRlbmRlZCBjb21tdW5pdHkuDQo+ID4+ID4NCj4gPj4gPiAgICBUaGFu a3MsDQo+ID4+ID4gICAgSmFrb2IuDQo+ID4+ID4NCj4gPj4gPiAgICA+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4+ID4gICAgPiBGcm9tOiBzaWRyIFttYWlsdG86c2lkci1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGhlIElFU0cNCj4gPj4gPiAgICA+IFNlbnQ6IFdlZG5l c2RheSwgSmFudWFyeSAxMSwgMjAxNyA3OjI1IEFNDQo+ID4+ID4gICAgPiBUbzogSUVURi1Bbm5v dW5jZSA8aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZz4NCj4gPj4gPiAgICA+IENjOiBkcmFmdC1pZXRm LXNpZHItb3JpZ2luLXZhbGlkYXRpb24tc2lnbmFsaW5nQGlldGYub3JnOw0KPiA+PiA+c2lkckBp ZXRmLm9yZzsgc2lkci1jaGFpcnNAaWV0Zi5vcmc7IFRoZSBJRVNHDQo+ID4+ID4gICAgPiA8aWVz Z0BpZXRmLm9yZz47IHNhbmR5QHRpc2xhYnMuY29tOyByZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3Jn DQo+ID4+ID4gICAgPiBTdWJqZWN0OiBbc2lkcl0gUHJvdG9jb2wgQWN0aW9uOiAnQkdQIFByZWZp eCBPcmlnaW4gVmFsaWRhdGlvbg0KPiA+PiA+U3RhdGUgRXh0ZW5kZWQgQ29tbXVuaXR5JyB0byBQ cm9wb3NlZCBTdGFuZGFyZA0KPiA+PiA+ICAgID4gKGRyYWZ0LWlldGYtc2lkci1vcmlnaW4tdmFs aWRhdGlvbi1zaWduYWxpbmctMTEudHh0KQ0KPiA+PiA+ICAgID4NCj4gPj4gPiAgICA+IFRoZSBJ RVNHIGhhcyBhcHByb3ZlZCB0aGUgZm9sbG93aW5nIGRvY3VtZW50Og0KPiA+PiA+ICAgID4gLSAn QkdQIFByZWZpeCBPcmlnaW4gVmFsaWRhdGlvbiBTdGF0ZSBFeHRlbmRlZCBDb21tdW5pdHknDQo+ ID4+ID4gICAgPiAgIChkcmFmdC1pZXRmLXNpZHItb3JpZ2luLXZhbGlkYXRpb24tc2lnbmFsaW5n LTExLnR4dCkgYXMNCj4gPj5Qcm9wb3NlZA0KPiA+PiA+ICAgID4gU3RhbmRhcmQNCj4gPj4gPiAg ICA+DQo+ID4+ID4gICAgPiBUaGlzIGRvY3VtZW50IGlzIHRoZSBwcm9kdWN0IG9mIHRoZSBTZWN1 cmUgSW50ZXItRG9tYWluIFJvdXRpbmcNCj4gPj4gPldvcmtpbmcNCj4gPj4gPiAgICA+IEdyb3Vw Lg0KPiA+PiA+ICAgID4NCj4gPj4gPiAgICA+IFRoZSBJRVNHIGNvbnRhY3QgcGVyc29ucyBhcmUg QWx2YXJvIFJldGFuYSwgQWxpYSBBdGxhcyBhbmQNCj4gPj5EZWJvcmFoDQo+ID4+ID4gICAgPiBC cnVuZ2FyZC4NCj4gPj4gPiAgICA+DQo+ID4+ID4gICAgPiBBIFVSTCBvZiB0aGlzIEludGVybmV0 IERyYWZ0IGlzOg0KPiA+PiA+ICAgID4NCj4gPj4NCj4gPj4+aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zaWRyLW9yaWdpbi12YWxpZGF0aW9uLXNpZ25hDQo+ID4+ PmxpDQo+ID4+ID5uZy8NCj4gPj4gPiAgICA+DQo+ID4+ID4gICAgPg0KPiA+PiA+ICAgID4NCj4g Pj4gPiAgICA+DQo+ID4+ID4gICAgPg0KPiA+PiA+ICAgID4gVGVjaG5pY2FsIFN1bW1hcnkNCj4g Pj4gPiAgICA+DQo+ID4+ID4gICAgPiAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgQkdQ IG9wYXF1ZSBleHRlbmRlZCBjb21tdW5pdHkgdG8NCj4gPj4gPmNhcnJ5DQo+ID4+ID4gICAgPiAg ICB0aGUgb3JpZ2luYXRpb24gQVMgdmFsaWRhdGlvbiBzdGF0ZSBpbnNpZGUgYW4gYXV0b25vbW91 cw0KPiA+PnN5c3RlbS4NCj4gPj4gPiAgICA+ICAgIElCR1Agc3BlYWtlcnMgdGhhdCByZWNlaXZl IHRoaXMgdmFsaWRhdGlvbiBzdGF0ZSBjYW4gY29uZmlndXJlDQo+ID4+ID5sb2NhbA0KPiA+PiA+ ICAgID4gICAgcG9saWNpZXMgYWxsb3dpbmcgaXQgdG8gaW5mbHVlbmNlIHRoZWlyIGRlY2lzaW9u IHByb2Nlc3MuDQo+ID4+ID4gICAgPg0KPiA+PiA+ICAgID4gV29ya2luZyBHcm91cCBTdW1tYXJ5 DQo+ID4+ID4gICAgPg0KPiA+PiA+ICAgID4gICBUaGlzIGRvY3VtZW50IGhhcyBoYWQgY29uc2lz dGVudCBpbnRlcmVzdCBmcm9tIHRoZSB3b3JraW5nDQo+ID4+Z3JvdXAuDQo+ID4+ID4gICAgPiAg IEJlY2F1c2UgaXQgZGVmaW5lcyBhIG5ldyBCR1AgY29tbXVuaXR5LCBpdCB3YXMgcmV2aWV3ZWQg YnkgdGhlDQo+ID4+aWRyDQo+ID4+ID4gICAgPiAgIHdvcmtpbmcgZ3JvdXAgYXMgd2VsbC4NCj4g Pj4gPiAgICA+DQo+ID4+ID4gICAgPiBEb2N1bWVudCBRdWFsaXR5DQo+ID4+ID4gICAgPg0KPiA+ PiA+ICAgID4gICBUaGUgZG9jdW1lbnQgaGFzIGJlZW4gaW1wbGVtZW50ZWQgYnkgbWFqb3Igcm91 dGVyIHZlbmRvcnMuDQo+ID4+ID4gICAgPiAgIEl0IGlzIGtub3duIHRvIGJlIGluIHVzZSBpbiB0 d28gbGFyZ2UgSVhQcywgQU1TLUlYIGFuZCBERS1DSVguDQo+ID4+ID4gICAgPg0KPiA+PiA+ICAg ID4gUGVyc29ubmVsDQo+ID4+ID4gICAgPg0KPiA+PiA+ICAgID4gICBEb2N1bWVudCBTaGVwaGVy ZDogU2FuZHJhIE11cnBoeQ0KPiA+PiA+ICAgID4gICBSZXNwb25zaWJsZSBBcmVhIERpcmVjdG9y OiBBbHZhcm8gUmV0YW5hDQo+ID4+ID4gICAgPg0KPiA+PiA+ICAgID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gPiAgICA+IHNpZHIgbWFpbGlu ZyBsaXN0DQo+ID4+ID4gICAgPiBzaWRyQGlldGYub3JnDQo+ID4+ID4gICAgPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpZHINCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4N Cj4gPj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4+ID5zaWRyIG1haWxpbmcgbGlzdA0KPiA+PiA+c2lkckBpZXRmLm9yZw0KPiA+PiA+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaWRyDQo+ID4NCg0K From nobody Fri Mar 3 16:13:33 2017 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 992731293D6; Fri, 3 Mar 2017 16:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhVky9pZ1goj; Fri, 3 Mar 2017 16:13:30 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A981293D8; Fri, 3 Mar 2017 16:13:30 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cjxK9-0001r6-MQ; Sat, 04 Mar 2017 00:13:26 +0000 Date: Sat, 04 Mar 2017 09:13:22 +0900 Message-ID: From: Randy Bush To: "Montgomery, Douglas (Fed)" In-Reply-To: References: <148414831932.11019.14685466226406323027.idtracker@ietfa.amsl.com> <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: "draft-ietf-sidr-origin-validation-signaling@ietf.org" , "sandy@tislabs.com" , "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-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: Sat, 04 Mar 2017 00:13:31 -0000 i am very confused. what is the actual problem here? if the community arrives at a router that has computed a validation state from local data, the community's state must be ignored. does the spec need to be clarified in this aspect? if so, text would be helpful. randy From nobody Fri Mar 3 19:59:27 2017 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 3C55A127076; Fri, 3 Mar 2017 19:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2kCTfzG1Xee; Fri, 3 Mar 2017 19:59:24 -0800 (PST) Received: from relay.kvm02.ops-netman.net (relay.kvm02.ops-netman.net [IPv6:2606:700:e:550:5c82:28ff:fe25:4960]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEACE127071; Fri, 3 Mar 2017 19:59:24 -0800 (PST) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id 5DE9E3FFC9; Sat, 4 Mar 2017 03:59:21 +0000 (UTC) Received: from morrowc.roam.corp.google.com.ops-netman.net (static-96-241-182-39.washdc.fios.verizon.net [96.241.182.39]) (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 C467B493FD33; Sat, 4 Mar 2017 03:59:20 +0000 (UTC) Date: Fri, 03 Mar 2017 22:59:20 -0500 Message-ID: From: Chris Morrow To: Randy Bush In-Reply-To: References: <148414831932.11019.14685466226406323027.idtracker@ietfa.amsl.com> <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com> 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: Cc: "draft-ietf-sidr-origin-validation-signaling@ietf.org" , "sidr@ietf.org" , "sidr-chairs@ietf.org" , "sandy@tislabs.com" Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-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: Sat, 04 Mar 2017 03:59:26 -0000 At Sat, 04 Mar 2017 09:13:22 +0900, Randy Bush wrote: > > i am very confused. what is the actual problem here? > > if the community arrives at a router that has computed a validation > state from local data, the community's state must be ignored. > > does the spec need to be clarified in this aspect? if so, text would be > helpful. It sounds like implementers are unsure if the 3rd back sentence is correct/intended. How about: Section 2, 3rd paragraph: "Similarly on the receiving IBGP speakers, the validation state of an IBGP route SHOULD be derived directly from the last octet of the extended community, if present." to: "Similarly on the receiving IBGP speakers, the validation state of an IBGP route SHOULD be derived directly from the last octet of the extended community, if present. A receiving router should use locally achieved validation state before trusting an IBGP neighbors state information." -chris From nobody Fri Mar 3 20:05:24 2017 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 18F1D129408; Fri, 3 Mar 2017 20:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OD4eTB-K_uzC; Fri, 3 Mar 2017 20:05:22 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F3C5127076; Fri, 3 Mar 2017 20:05:22 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ck0wT-00041b-IO; Sat, 04 Mar 2017 04:05:13 +0000 Date: Sat, 04 Mar 2017 13:05:11 +0900 Message-ID: From: Randy Bush To: Chris Morrow In-Reply-To: References: <148414831932.11019.14685466226406323027.idtracker@ietfa.amsl.com> <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: "draft-ietf-sidr-origin-validation-signaling@ietf.org" , "sidr@ietf.org" , "sidr-chairs@ietf.org" , "sandy@tislabs.com" Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-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: Sat, 04 Mar 2017 04:05:24 -0000 > Section 2, 3rd paragraph: > > "Similarly on the receiving IBGP speakers, the validation > state of an IBGP route SHOULD be derived directly from the last octet > of the extended community, if present." > > to: > "Similarly on the receiving IBGP speakers, the validation state of > an IBGP route SHOULD be derived directly from the last octet of the > extended community, if present. A receiving router should use > locally achieved validation state before trusting an IBGP neighbors > state information." sure. or, tersified, "Similarly, a receiving IBGP speaker, in the absence of validation state set based on local data, SHOULD derive a validations state from the last octet of the extended community, if present." randy From nobody Fri Mar 3 20:23:01 2017 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 D66A4129426; Fri, 3 Mar 2017 20:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEjI6CMfS9UZ; Fri, 3 Mar 2017 20:22:58 -0800 (PST) Received: from relay.kvm02.ops-netman.net (relay.kvm02.ops-netman.net [IPv6:2606:700:e:550:5c82:28ff:fe25:4960]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60F8C128E18; Fri, 3 Mar 2017 20:22:58 -0800 (PST) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id 902B43FFC9; Sat, 4 Mar 2017 04:22:56 +0000 (UTC) Received: from morrowc.roam.corp.google.com.ops-netman.net (static-96-241-182-39.washdc.fios.verizon.net [96.241.182.39]) (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 8481349460CF; Sat, 4 Mar 2017 04:22:55 +0000 (UTC) Date: Fri, 03 Mar 2017 23:22:55 -0500 Message-ID: From: Chris Morrow To: Randy Bush In-Reply-To: References: <148414831932.11019.14685466226406323027.idtracker@ietfa.amsl.com> <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com> 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: Cc: "draft-ietf-sidr-origin-validation-signaling@ietf.org" , "sidr@ietf.org" , Chris Morrow , "sidr-chairs@ietf.org" , "sandy@tislabs.com" Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-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: Sat, 04 Mar 2017 04:23:00 -0000 At Sat, 04 Mar 2017 13:05:11 +0900, Randy Bush wrote: > > > Section 2, 3rd paragraph: > > > > "Similarly on the receiving IBGP speakers, the validation > > state of an IBGP route SHOULD be derived directly from the last octet > > of the extended community, if present." > > > > to: > > "Similarly on the receiving IBGP speakers, the validation state of > > an IBGP route SHOULD be derived directly from the last octet of the > > extended community, if present. A receiving router should use > > locally achieved validation state before trusting an IBGP neighbors > > state information." > > sure. or, tersified, > > "Similarly, a receiving IBGP speaker, in the absence of validation > state set based on local data, SHOULD derive a validations state from > the last octet of the extended community, if present." great! From nobody Fri Mar 3 20:28:51 2017 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 79FE5127071; Fri, 3 Mar 2017 20:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDn1FQwYNtDB; Fri, 3 Mar 2017 20:28:48 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF02612711D; Fri, 3 Mar 2017 20:28:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2064; q=dns/txt; s=iport; t=1488601727; x=1489811327; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YtqtWCvYp0eBzEujqud/u/jJ7WWV2hJ2hfwzJTFtdcI=; b=l8bE11klqlNIXc6ElqqeKXIFS77YoUKbhh0jipKNsRs1FbKBiO9Xou0s q7mqSJuzFnOBBcPSO12t+lbXYk3YffbwBKN+FK5Ic9a6s5gKAAJ63GnuO 3olWmCfKOcBZi/ZhpCKYrb3gBuepupXfZA3o/lReaBSK0eEL4gUBnV4K/ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQCoQbpY/5ldJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1GBaweNZZFGlTeCDYYiAoJmPxgBAgEBAQEBAQFiKIRwAQEBBDo?= =?us-ascii?q?/DAQCAQgRBAEBHwUEBzIUCQgCBAENBQgMiWe1IosDAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBHYZOhG+KOQWcLAGSKZEokzoBHziBA1YVhUmBSnaHUyuBA4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.35,239,1484006400"; d="scan'208";a="214071918" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Mar 2017 04:28:46 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v244Slbl025790 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 4 Mar 2017 04:28:47 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 3 Mar 2017 22:28:46 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Fri, 3 Mar 2017 22:28:46 -0600 From: "Jakob Heitz (jheitz)" To: Randy Bush , Chris Morrow Thread-Topic: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt) Thread-Index: AQHSbB8KL4goLDO+zUCyR+oqQEK9nqF2Wu8wgAEcsQCADL9tgIAATY4AgAA/IwCAAAGigP//nPfg Date: Sat, 4 Mar 2017 04:28:46 +0000 Message-ID: <4f0301f24b794a5c8ea0ab9e86f97eb0@XCH-ALN-014.cisco.com> References: <148414831932.11019.14685466226406323027.idtracker@ietfa.amsl.com> <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.90.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sidr-origin-validation-signaling@ietf.org" , "sandy@tislabs.com" , "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-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: Sat, 04 Mar 2017 04:28:49 -0000 Both are a bit mushy. The ext-comm may come from an ebgp neighbor. I want to make sure that the not-found state is not interpreted as a locally achieved validation state. If the local state is not-found, then the received ext-comm should count. "Similarly on the receiving IBGP speakers, the validation state of an IBGP route SHOULD be derived directly from the last octet of the extended community, if present. If a receiving router is performing RPKI validation locally and has determined a state other than not-found, then the state determined by the extended community SHOULD NOT be used." Thanks, Jakob. > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Friday, March 03, 2017 8:05 PM > To: Chris Morrow > Cc: Montgomery, Douglas (Fed) ; Alvaro Retana (aretana) <= aretana@cisco.com>; Jakob Heitz (jheitz) > ; draft-ietf-sidr-origin-validation-signaling@ietf.org;= sandy@tislabs.com; sidr-chairs@ietf.org; > sidr@ietf.org > Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State = Extended Community' to Proposed Standard > (draft-ietf-sidr-origin-validation-signaling-11.txt) >=20 > > Section 2, 3rd paragraph: > > > > "Similarly on the receiving IBGP speakers, the validation > > state of an IBGP route SHOULD be derived directly from the last octe= t > > of the extended community, if present." > > > > to: > > "Similarly on the receiving IBGP speakers, the validation state of > > an IBGP route SHOULD be derived directly from the last octet of the > > extended community, if present. A receiving router should use > > locally achieved validation state before trusting an IBGP neighbors > > state information." >=20 > sure. or, tersified, >=20 > "Similarly, a receiving IBGP speaker, in the absence of validation > state set based on local data, SHOULD derive a validations state from > the last octet of the extended community, if present." >=20 > randy From nobody Fri Mar 3 20:36:17 2017 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 D56E812711D; Fri, 3 Mar 2017 20:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FM1w4h5y0Plo; Fri, 3 Mar 2017 20:36:15 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 225FB127071; Fri, 3 Mar 2017 20:36:15 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ck1QP-0004Cf-0M; Sat, 04 Mar 2017 04:36:09 +0000 Date: Sat, 04 Mar 2017 13:36:05 +0900 Message-ID: From: Randy Bush To: "Jakob Heitz (jheitz)" In-Reply-To: <4f0301f24b794a5c8ea0ab9e86f97eb0@XCH-ALN-014.cisco.com> References: <148414831932.11019.14685466226406323027.idtracker@ietfa.amsl.com> <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com> <4f0301f24b794a5c8ea0ab9e86f97eb0@XCH-ALN-014.cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: "draft-ietf-sidr-origin-validation-signaling@ietf.org" , "sidr@ietf.org" , Chris Morrow , "sidr-chairs@ietf.org" , "sandy@tislabs.com" Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-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: Sat, 04 Mar 2017 04:36:16 -0000 > The ext-comm may come from an ebgp neighbor. ok. saves a character. my kind of change :) "Similarly, a receiving BGP speaker, in the absence of validation state set based on local data, SHOULD derive a validations state from the last octet of the extended community, if present." randy From nobody Fri Mar 3 20:37:36 2017 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 8193E12944A; Fri, 3 Mar 2017 20:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63xOTlBgZlkj; Fri, 3 Mar 2017 20:37:33 -0800 (PST) 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 7E12412711D; Fri, 3 Mar 2017 20:37:33 -0800 (PST) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id 7DD4C3FFC9; Sat, 4 Mar 2017 04:37:32 +0000 (UTC) Received: from morrowc.roam.corp.google.com.ops-netman.net (static-96-241-182-39.washdc.fios.verizon.net [96.241.182.39]) (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 E4975494B6FC; Sat, 4 Mar 2017 04:37:31 +0000 (UTC) Date: Fri, 03 Mar 2017 23:37:31 -0500 Message-ID: From: Chris Morrow To: Randy Bush In-Reply-To: References: <148414831932.11019.14685466226406323027.idtracker@ietfa.amsl.com> <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com> <4f0301f24b794a5c8ea0ab9e86f97eb0@XCH-ALN-014.cisco.com> 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: Cc: "draft-ietf-sidr-origin-validation-signaling@ietf.org" , "sidr@ietf.org" , Chris Morrow , "sidr-chairs@ietf.org" , "sandy@tislabs.com" Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-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: Sat, 04 Mar 2017 04:37:34 -0000 At Sat, 04 Mar 2017 13:36:05 +0900, Randy Bush wrote: > > > The ext-comm may come from an ebgp neighbor. ebgp neighbor? the text talks about ibgp, and about explicitly ignoring ebgp senders of this community (by default). right? > > ok. saves a character. my kind of change :) > > "Similarly, a receiving BGP speaker, in the absence of validation > state set based on local data, SHOULD derive a validations state from > the last octet of the extended community, if present." > > randy From nobody Fri Mar 3 20:40:08 2017 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 B5124129452; Fri, 3 Mar 2017 20:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEUuu6BoiZdT; Fri, 3 Mar 2017 20:40:05 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A41512944A; Fri, 3 Mar 2017 20:40:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1619; q=dns/txt; s=iport; t=1488602405; x=1489812005; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NzrXy9yJiahjg6XdzN0zKRr3ZsWJljbRgHmmUwdFKvQ=; b=Asy8erN/sh0QxoNb6Yrwu2x+MKFHFn7rySxm5V34o4RXRbTCfhepod4s 8g5KmCYmkKC4gkZJOUDCoBSYkeKH1aclmOEamh27ViAzZZ5cuT1e9E4TR LX+3dA8aNxrEh3gvq87tObgLpkpSL6rjDhYh+AcbK8D939eFwX6dcf0f6 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQANRLpY/5NdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1GBaweNZZFGlTeCDYYiAoJmPxgBAgEBAQEBAQFiKIRwAQEBBDo?= =?us-ascii?q?/DAQCAQgRBAEBAR4FBAcyFAkIAgQBDQUIDIlntSOLAwEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2GToRvhD6FewEEnCwBkimRKJM6AR84gQNWFYVJgUp2h1MrgQOBDQE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.35,239,1484006400"; d="scan'208";a="215894634" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Mar 2017 04:40:04 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v244e4mh015503 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 4 Mar 2017 04:40:04 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 3 Mar 2017 22:40:03 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Fri, 3 Mar 2017 22:40:03 -0600 From: "Jakob Heitz (jheitz)" To: Chris Morrow , Randy Bush Thread-Topic: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt) Thread-Index: AQHSbB8KL4goLDO+zUCyR+oqQEK9nqF2Wu8wgAEcsQCADL9tgIAATY4AgAA/IwCAAAGigP//nPfggABrq4CAAABngP//nBXw Date: Sat, 4 Mar 2017 04:40:03 +0000 Message-ID: References: <148414831932.11019.14685466226406323027.idtracker@ietfa.amsl.com> <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com> <4f0301f24b794a5c8ea0ab9e86f97eb0@XCH-ALN-014.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.90.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sidr-origin-validation-signaling@ietf.org" , "sandy@tislabs.com" , "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-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: Sat, 04 Mar 2017 04:40:07 -0000 However it SHOULD be possible to configure an implementation to send or accept the community when warranted. An example of a case where the community would reasonably be received from, or sent to, an EBGP peer is when two adjacent ASes are under control of the same administration. A second example is documented in [I-D.ietf-sidr-route-server-rpki-light]. Thanks, Jakob. > -----Original Message----- > From: Chris Morrow [mailto:morrowc@ops-netman.net] > Sent: Friday, March 03, 2017 8:38 PM > To: Randy Bush > Cc: Jakob Heitz (jheitz) ; Chris Morrow ; Montgomery, Douglas (Fed) > ; Alvaro Retana (aretana) ; draft-ietf= -sidr-origin-validation-signaling@ietf.org; > sandy@tislabs.com; sidr-chairs@ietf.org; sidr@ietf.org > Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State = Extended Community' to Proposed Standard > (draft-ietf-sidr-origin-validation-signaling-11.txt) >=20 > At Sat, 04 Mar 2017 13:36:05 +0900, > Randy Bush wrote: > > > > > The ext-comm may come from an ebgp neighbor. >=20 > ebgp neighbor? the text talks about ibgp, and about explicitly ignoring e= bgp senders of this community (by default). >=20 > right? >=20 > > > > ok. saves a character. my kind of change :) > > > > "Similarly, a receiving BGP speaker, in the absence of validation > > state set based on local data, SHOULD derive a validations state fro= m > > the last octet of the extended community, if present." > > > > randy From nobody Fri Mar 3 20:42:24 2017 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 BFA48129452; Fri, 3 Mar 2017 20:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ss5I0I1SDChq; Fri, 3 Mar 2017 20:42:23 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F29EB12711D; Fri, 3 Mar 2017 20:42:22 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ck1WN-0004G3-3X; Sat, 04 Mar 2017 04:42:19 +0000 Date: Sat, 04 Mar 2017 13:42:15 +0900 Message-ID: From: Randy Bush To: Chris Morrow In-Reply-To: References: <148414831932.11019.14685466226406323027.idtracker@ietfa.amsl.com> <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com> <4f0301f24b794a5c8ea0ab9e86f97eb0@XCH-ALN-014.cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: "draft-ietf-sidr-origin-validation-signaling@ietf.org" , "sidr@ietf.org" , "sidr-chairs@ietf.org" , "sandy@tislabs.com" Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-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: Sat, 04 Mar 2017 04:42:24 -0000 > ebgp neighbor? the text talks about ibgp, and about explicitly > ignoring ebgp senders of this community (by default). if it does not say MUST NOT accept from ebgp, the jakob has to have code. imiho, it sould say MUST NOT accept from engp. randy From nobody Fri Mar 3 21:18:37 2017 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 C0D97129437; Fri, 3 Mar 2017 21:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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=netorgft1331857.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 h4vwikF5J66n; Fri, 3 Mar 2017 21:18:33 -0800 (PST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) (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 E6609127A90; Fri, 3 Mar 2017 21:18:32 -0800 (PST) Received: from pure.maildistiller.com (unknown [10.110.50.29]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id 645B660061; Sat, 4 Mar 2017 05:18:30 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx7-us1.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id BF1DD6004B; Sat, 4 Mar 2017 05:18:29 +0000 (UTC) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0113.outbound.protection.outlook.com [207.46.163.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx7-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 70004540075; Sat, 4 Mar 2017 05:18:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=G+PrgPlZdPH5iLnjAUEjbbzowliFZNTT8EMqFQ7Gxuo=; b=loIYSMzrAeXLtI32ZncPbcO103nbXBOC2PNCWhJP+UzOtev56WSmMXJB9oAkXZfu/Qk/FSnmx9FMNYqJ84ZlHD6AQWPaDhoHtfqeFNBEzi2oO7x8aAyUcV103VWWMYRRGDRQoXP+hHQcZzUSdWwcNovjzbdZTlDABvCdrXRKA5o= Received: from BY2PR18MB0262.namprd18.prod.outlook.com (10.163.72.152) by BY2PR18MB0261.namprd18.prod.outlook.com (10.163.72.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Sat, 4 Mar 2017 05:18:17 +0000 Received: from BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) by BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) with mapi id 15.01.0933.020; Sat, 4 Mar 2017 05:18:16 +0000 From: Keyur Patel To: "Jakob Heitz (jheitz)" Thread-Topic: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt) Thread-Index: AQHSbB7tzlS1UVmWk0KSI6cn7Yzvt6F3XtWAgAAICACADGubgIAATY4AgAA/IwCAAAGigIAABpcAgAACC4CAAABngIAAALWAgAAKrlM= Date: Sat, 4 Mar 2017 05:18:16 +0000 Message-ID: <316227B7-8EB3-43C4-A164-926DDCDBA8FD@arrcus.com> References: <148414831932.11019.14685466226406323027.idtracker@ietfa.amsl.com> <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com> <4f0301f24b794a5c8ea0ab9e86f97eb0@XCH-ALN-014.cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=arrcus.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2601:646:8980:4f18:8544:29f6:59d6:4e22] x-ms-office365-filtering-correlation-id: 164b991b-f9a2-47cc-70d9-08d462bddd69 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BY2PR18MB0261; x-microsoft-exchange-diagnostics: 1; BY2PR18MB0261; 7:3mCnApb5dKfzuggIp2y/0cfA4d4l8JWFXtKh0P3Ay0uVA9aBmO3JAuidw1HlrD0EDp2fQY6wcVIRAYk3KPsYqKStAIUnSDSMKTC3Zjc2UEuEjuaaKrJnFUV3nDXsczbMt3bpyaG64vJlM2P04BS8CuiAhBX/rXtCS8rO9JI3TYkiqjfbvlry9np+MVK1B8c1IIyDBU+rOm9dmtiuDnU132ZWnmN54kntNi3/QpHScEcAq3Es96LvSGN7o/gxYqCewXq32m/PcySpQ/9OfKua5kkPRFMUYvABmxoLafy6+fSrjvHR72+QrHMS0X/DM4HYx+dBBBgD2JqWODL98dQrgw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(2016111802025)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148)(6042181)(6043046); SRVR:BY2PR18MB0261; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0261; x-forefront-prvs: 0236114672 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(13464003)(24454002)(377454003)(93886004)(36756003)(2906002)(8656002)(5003630100001)(230783001)(50986999)(3280700002)(86362001)(76176999)(189998001)(3660700001)(54906002)(99286003)(54356999)(7736002)(6506006)(6436002)(4326008)(25786008)(305945005)(6512007)(6116002)(102836003)(106116001)(77096006)(229853002)(5660300001)(110136004)(33656002)(6916009)(38730400002)(53546006)(8936002)(2900100001)(92566002)(8676002)(122556002)(6246003)(2950100002)(81166006)(6486002)(53936002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0261; H:BY2PR18MB0262.namprd18.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2017 05:18:16.6910 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0261 X-MDID: 1488604710-rvNaIPXJje8G Archived-At: Cc: "draft-ietf-sidr-origin-validation-signaling@ietf.org" , "sidr@ietf.org" , Chris Morrow , "sidr-chairs@ietf.org" , "sandy@tislabs.com" Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-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: Sat, 04 Mar 2017 05:18:36 -0000 Jacob, Ebgp Peers are out of scope. Imho, implementations are free to implement re= ceipt and processing of a community from a ebgp peer as a knob. The standar= d doesn't have to accommodate knobs. Regards, Keyur Sent from my iPhone > On Mar 3, 2017, at 8:40 PM, Jakob Heitz (jheitz) wrote= : >=20 > However it SHOULD be possible to > configure an implementation to send or accept the community when > warranted. An example of a case where the community would reasonably > be received from, or sent to, an EBGP peer is when two adjacent ASes > are under control of the same administration. A second example is > documented in [I-D.ietf-sidr-route-server-rpki-light]. >=20 > Thanks, > Jakob. >=20 >> -----Original Message----- >> From: Chris Morrow [mailto:morrowc@ops-netman.net] >> Sent: Friday, March 03, 2017 8:38 PM >> To: Randy Bush >> Cc: Jakob Heitz (jheitz) ; Chris Morrow ; Montgomery, Douglas (Fed) >> ; Alvaro Retana (aretana) ; draft-iet= f-sidr-origin-validation-signaling@ietf.org; >> sandy@tislabs.com; sidr-chairs@ietf.org; sidr@ietf.org >> Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State= Extended Community' to Proposed Standard >> (draft-ietf-sidr-origin-validation-signaling-11.txt) >>=20 >> At Sat, 04 Mar 2017 13:36:05 +0900, >> Randy Bush wrote: >>>=20 >>>> The ext-comm may come from an ebgp neighbor. >>=20 >> ebgp neighbor? the text talks about ibgp, and about explicitly ignoring = ebgp senders of this community (by default). >>=20 >> right? >>=20 >>>=20 >>> ok. saves a character. my kind of change :) >>>=20 >>> "Similarly, a receiving BGP speaker, in the absence of validation >>> state set based on local data, SHOULD derive a validations state from >>> the last octet of the extended community, if present." >>>=20 >>> randy From nobody Fri Mar 3 21:23:59 2017 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 49F751293EE; Fri, 3 Mar 2017 21:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxKW9FGAqVhn; Fri, 3 Mar 2017 21:23:55 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C886128DF6; Fri, 3 Mar 2017 21:23:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2174; q=dns/txt; s=iport; t=1488605035; x=1489814635; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tV9YZKJxUQchbasnrCTKd4F96yug3xoUabFFp4P0SrQ=; b=fFsTEAC7fjwgip4xC/tgclNEvDuoG+BLipxPBIrv2XuJpfrgjVN2dIYr TX+oTKRH82SQCOi/Fa7yxT4txamWEiQSH3KO339EH+F/UUl7yOYP2UaOX mit6fQ2CAVf55DcnP8FrngHCQppiX0I2adfOe2VcLzwJimOXiRtl+Yy6I I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A7AQBcTrpY/5ldJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1GBa41skScflTeCDYYiAoJmPxgBAgEBAQEBAQFiKIRwAQEBAwE?= =?us-ascii?q?6PwUHBAIBCBEEAQEBHQEFBAcyFAkIAgQOBRSJXwi1HIsDAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBHYZOggUIgmKEPhaDNIIxAQSVdYY3AZIykR+TOgEfOIEDVhVQAYR?= =?us-ascii?q?4gUp2h1MrghABAQE?= X-IronPort-AV: E=Sophos;i="5.35,239,1484006400"; d="scan'208";a="391871568" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Mar 2017 05:23:54 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v245Ns7I026227 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 4 Mar 2017 05:23:54 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 3 Mar 2017 23:23:53 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Fri, 3 Mar 2017 23:23:53 -0600 From: "Jakob Heitz (jheitz)" To: Keyur Patel Thread-Topic: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt) Thread-Index: AQHSbB8KL4goLDO+zUCyR+oqQEK9nqF2Wu8wgAEcsQCADL9tgIAATY4AgAA/IwCAAAGigP//nPfggABrq4CAAABngP//nBXwgABvTQD//5z+sA== Date: Sat, 4 Mar 2017 05:23:53 +0000 Message-ID: <6AFE0652-9306-4608-B029-106BD153D38E@cisco.com> References: <148414831932.11019.14685466226406323027.idtracker@ietfa.amsl.com> <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com> <4f0301f24b794a5c8ea0ab9e86f97eb0@XCH-ALN-014.cisco.com> , , <316227B7-8EB3-43C4-A164-926DDCDBA8FD@arrcus.com> In-Reply-To: <316227B7-8EB3-43C4-A164-926DDCDBA8FD@arrcus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sidr-origin-validation-signaling@ietf.org" , "sidr@ietf.org" , Chris Morrow , "sidr-chairs@ietf.org" , "sandy@tislabs.com" Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-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: Sat, 04 Mar 2017 05:23:57 -0000 I pasted from the draft. Thanks, Jakob. > On Mar 3, 2017, at 9:18 PM, Keyur Patel wrote: >=20 > Jacob, >=20 > Ebgp Peers are out of scope. Imho, implementations are free to implement = receipt and processing of a community from a ebgp peer as a knob. The stand= ard doesn't have to accommodate knobs. >=20 > Regards, > Keyur >=20 > Sent from my iPhone >=20 >> On Mar 3, 2017, at 8:40 PM, Jakob Heitz (jheitz) wrot= e: >>=20 >> However it SHOULD be possible to >> configure an implementation to send or accept the community when >> warranted. An example of a case where the community would reasonably >> be received from, or sent to, an EBGP peer is when two adjacent ASes >> are under control of the same administration. A second example is >> documented in [I-D.ietf-sidr-route-server-rpki-light]. >>=20 >> Thanks, >> Jakob. >>=20 >>> -----Original Message----- >>> From: Chris Morrow [mailto:morrowc@ops-netman.net] >>> Sent: Friday, March 03, 2017 8:38 PM >>> To: Randy Bush >>> Cc: Jakob Heitz (jheitz) ; Chris Morrow ; Montgomery, Douglas (Fed) >>> ; Alvaro Retana (aretana) ; draft-ie= tf-sidr-origin-validation-signaling@ietf.org; >>> sandy@tislabs.com; sidr-chairs@ietf.org; sidr@ietf.org >>> Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation Stat= e Extended Community' to Proposed Standard >>> (draft-ietf-sidr-origin-validation-signaling-11.txt) >>>=20 >>> At Sat, 04 Mar 2017 13:36:05 +0900, >>> Randy Bush wrote: >>>>=20 >>>>> The ext-comm may come from an ebgp neighbor. >>>=20 >>> ebgp neighbor? the text talks about ibgp, and about explicitly ignoring= ebgp senders of this community (by default). >>>=20 >>> right? >>>=20 >>>>=20 >>>> ok. saves a character. my kind of change :) >>>>=20 >>>> "Similarly, a receiving BGP speaker, in the absence of validation >>>> state set based on local data, SHOULD derive a validations state from >>>> the last octet of the extended community, if present." >>>>=20 >>>> randy From nobody Mon Mar 6 08:34:57 2017 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 99156129542; Mon, 6 Mar 2017 08:34:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148881809662.14983.2177764565050758825.idtracker@ietfa.amsl.com> Date: Mon, 06 Mar 2017 08:34:56 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-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: Mon, 06 Mar 2017 16:34:56 -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 Algorithms, Key Formats, & Signature Formats Authors : Sean Turner Oliver Borchert Filename : draft-ietf-sidr-bgpsec-algs-17.txt Pages : 15 Date : 2017-03-06 Abstract: This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key size and signature format used in BGPsec (Border Gateway Protocol Security). This document updates the Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RFC 7935). This document also includes example BGPsec Update messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-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 Mon Mar 6 08:41:24 2017 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 C51881298A5; Mon, 6 Mar 2017 08:41:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Matthew Miller To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148881846080.15058.7367435968376657921.idtracker@ietfa.amsl.com> Date: Mon, 06 Mar 2017 08:41:00 -0800 Archived-At: Cc: draft-ietf-sidr-rpki-rtr-rfc6810-bis.all@ietf.org, ietf@ietf.org, sidr@ietf.org Subject: [sidr] Review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-08 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 Mar 2017 16:41:01 -0000 Reviewer: Matthew Miller Review result: Has Nits [ re-posting old review to get it onto the mailing list archives; some bugs prevented it the first time ] I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Document: Reviewer: Matthew A. Miller Review Date: 2017-02-14 IETF LC End Date: 2017-01-30 IESG Telechat date: 2017-02-16 Summary: This document is ready for publication as a Proposed Standard, but has a minor concern that should be addressed. This document describes a protocol for distributing RPKI information to routers from trusted caches. Major issues: NONE Minor issues: * In Section 5.1. "Fields of a PDU", for the Flags: definition, it states that: """ The remaining bits in the flags field are reserved for future use. In protocol version 1, they MUST be 0 on transmission and SHOULD be ignored on receipt. """ However, this seems backwards to me. Would it seem safer that the reserved flags "MUST be ignored on receipt". Nits/editorial comments: NONE From nobody Mon Mar 6 08:54:57 2017 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 A461D129878 for ; Mon, 6 Mar 2017 08:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 HfKXwHsmaI0N for ; Mon, 6 Mar 2017 08:54:54 -0800 (PST) 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 48B1412945A for ; Mon, 6 Mar 2017 08:54:54 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id p64so44645987qke.1 for ; Mon, 06 Mar 2017 08:54:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=ipCd0BRGxgagFc3x6Z7GHd6OQw4/1XpWGW+RAlZbonM=; b=I7XdgRxZbnWg4uS83GYtu7VLpt7P5iJ0d5UNVlqWV9ipxdFn3Aa8gpRCphH1jif8S0 NZuuer8V770Tkv+Prvujp99rt6+I+lXO/0cJ8Fc0mE7On6zVERbsXPjjPQrSllGWAwJ3 G8SQnfCMmnw7meTvuriqCaS17YYMDroQPfEYA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=ipCd0BRGxgagFc3x6Z7GHd6OQw4/1XpWGW+RAlZbonM=; b=kbceEF0ZkPuyWu95PdgG3sQjqjV43eF+wmcEtD/Sq9TURhekP/Mi3HUmmkAXKiyVO0 XdT9AHgWS9GCsMQofdZtJ3p1HyMGYAGT53IgMO9E+MzqtpglI1G/OWfAjBEywLKe9MET sv84QUXY8Lp1zrFBa6f7vcjWsFBnPAtVDtpb+xcN+miDhiRlFyI7OmpfdaVuL1DcbunB sANsvdH9Bl0gO4ZeHjxogMjiDz0XhGXfHQ3MnOhBr/+flBp4nwGYrNUxZmTtgwAqHu0h 8Fz1VKcS/JLTGb5ZN/bN8N1kcFlMNs9w+QXdhwP7fDvJQHGbWdgo9/uAxXeNoBHgL7Lq 8pkA== X-Gm-Message-State: AMke39mB23FItulXxv0O3FgrdCIwzVEgt4u2hfPRiLXrKM9ML3iEle+VhsbjsG/91S/93w== X-Received: by 10.200.51.152 with SMTP id c24mr18082548qtb.31.1488819292989; Mon, 06 Mar 2017 08:54:52 -0800 (PST) Received: from [172.16.0.92] ([96.231.228.203]) by smtp.gmail.com with ESMTPSA id i140sm10825944qke.2.2017.03.06.08.54.50 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 06 Mar 2017 08:54:51 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <148881809662.14983.2177764565050758825.idtracker@ietfa.amsl.com> Date: Mon, 6 Mar 2017 11:54:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148881809662.14983.2177764565050758825.idtracker@ietfa.amsl.com> To: sidr list X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-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: Mon, 06 Mar 2017 16:54:55 -0000 This version addresses the IESG comments we got from Alexey (drive home = the point that these algs are different than the rest of the RPKI) and = Stephen (add examples). As you may have seen, Oliver did a lot of work = on the examples so he=E2=80=99s now listed as an author. I=E2=80=99m hoping this is the last step prior to approval, but I=E2=80=99= ll leave that in Alvaro/Chris/Sandy=E2=80=99s hands. spt > On Mar 6, 2017, at 11:34, 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 : BGPsec Algorithms, Key Formats, & Signature = Formats > Authors : Sean Turner > Oliver Borchert > Filename : draft-ietf-sidr-bgpsec-algs-17.txt > Pages : 15 > Date : 2017-03-06 >=20 > Abstract: > This document specifies the algorithms, algorithm parameters, > asymmetric key formats, asymmetric key size and signature format = used > in BGPsec (Border Gateway Protocol Security). This document updates > the Profile for Algorithms and Key Sizes for Use in the Resource > Public Key Infrastructure (RFC 7935). >=20 > This document also includes example BGPsec Update messages as well > as the private keys used to generate the messages and the > certificates necessary to validate those signatures. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-17 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-algs-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 Tue Mar 7 07:43:34 2017 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 3B986126D74; Tue, 7 Mar 2017 06:43:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAVVh4yuHfZo; Tue, 7 Mar 2017 06:42:48 -0800 (PST) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29E2D12947A; Tue, 7 Mar 2017 06:38:43 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from ) id 1clFJX-0006Lb-QL; Tue, 07 Mar 2017 14:38:09 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-249.ripe.net) by titi.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1clFJX-0006ur-IC; Tue, 07 Mar 2017 14:38:07 +0100 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: <148845266459.19507.8615948310870059270.idtracker@ietfa.amsl.com> Date: Tue, 7 Mar 2017 14:38:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <21741F58-4A12-4A85-9DFF-75E2C0678469@ripe.net> References: <148845266459.19507.8615948310870059270.idtracker@ietfa.amsl.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------ X-RIPE-Spam-Report: Spam Total Points: -6.0 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP 1.5 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719e3792d7a463aa3c15896e7a9bc5b3991 Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, draft-ietf-sidr-delta-protocol@ietf.org Subject: Re: [sidr] Alexey Melnikov's Discuss on draft-ietf-sidr-delta-protocol-07: (with DISCUSS and COMMENT) 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 Mar 2017 14:43:02 -0000 Hi all, > On 02 Mar 2017, at 12:04, Alexey Melnikov = wrote: >=20 > Alexey Melnikov has entered the following ballot position for > draft-ietf-sidr-delta-protocol-07: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I would be happy to ballot Yes on this document, as it is well written > and is a useful piece of work. However I have one issue (and a few = minor > comments) that I would like to DISCUSS before doing so: >=20 > In Section 5.3 the document says: >=20 > 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) [RFC2818]. >=20 > RFC 7525 is referencing RFC 6125 for server hostname validation. > Unfortunately this is not detailed enough to perform hostname = validation, > because reference to RFC 6125 requires specifying answers to every > question in section 3 of RFC 6125. (And there is no generic RFC that > specifies how this is done for protocols using HTTP.) One example of = how > this might look like is in Section 9.2 of > = . > For your convenience the relevant text is pasted below: >=20 > Routers MUST also verify the cache's TLS server certificate, using > subjectAltName dNSName identities as described in [RFC6125], to > avoid > man-in-the-middle attacks. The rules and guidelines defined in > [RFC6125] apply here, with the following considerations: >=20 > Support for DNS-ID identifier type (that is, the dNSName identity > in the subjectAltName extension) is REQUIRED in rpki-rtr server > and client implementations which use TLS. Certification > authorities which issue rpki-rtr server certificates MUST support > the DNS-ID identifier type, and the DNS-ID identifier type MUST > be > present in rpki-rtr server certificates. >=20 > DNS names in rpki-rtr server certificates SHOULD NOT contain the > wildcard character "*". >=20 > rpki-rtr implementations which use TLS MUST NOT use CN-ID > identifiers; a CN field may be present in the server > certificate's > subject name, but MUST NOT be used for authentication within the > rules described in [RFC6125]. >=20 > The only thing missing from the above is explicit mentioning that = SRV-ID > and URI-ID are not used. (I think the same should apply to your > document.) Considering that we also say: Relying Party tools SHOULD log any TLS certificate or host name validation issues thus found, so that an operator can investigate the cause. However, such validation issues are often due to configuration errors, or a lack of a common TLS trust anchor. In these cases it is better if the Relying Party retrieves the signed RPKI data regardless, and performs validation on it. Therefore Relying Party MUST continue to retrieve the data in case of errors. The Relying Party MAY choose to log encountered issues only when fetching the notification update file, but not when it subsequently fetches snapshot or delta files from the same host. Furthermore the Relying Party MAY provide a way for operators to accept untrusted connections for a given host, after the cause has been identified. And because in practice Relying Party software will use standard = software libraries to do retrieval and verification, and it may be hard = or even impossible to configure these libraries to do the verification = as described.. would you agree with the following? Essentially taking = your suggested lead, but never exceeding "SHOULD" in the "how" of the = TLS certificate and host name validation that itself is a SHOULD, i.e.: Note that a Man-in-the-Middle (MITM) cannot produce validly signed RPKI data, but can perform withhold or replay attacks targeting an Relying Party, and keep the Relying Party from learning about changes in the RPKI. Because of this Relying Parties SHOULD do TLS certificate and host name validation when they fetch from an RRDP Repository Server, using subjectAltName dNSName identities as described in [RFC6125]. The rules and guidelines defined in [RFC6125] apply here, with the following considerations: o Relying Parties and Repository Servers SHOULD support the DNS-ID identifier type. The DNS-ID identifier type SHOULD be present in Repository Server certificates. o DNS names in Repository Server certificates SHOULD NOT contain the wildcard character "*". o A CN field may be present in Repository Server certificates's subject name, but SHOULD NOT be used for authentication within the rules described in [RFC6125]. o This protocol does not require the use of SRV-IDs. o This protocol does not require the use of URI-IDs. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > In 3.2: HTTPS reference is out-of-date. updated to RFC7230 > SHA-256 needs a reference. ok, added a normative reference (same as in the publication protocol = document): [SHS] National Institute of Standards and Technology, "Secure Hash Standard", March 2012, . From aamelnikov@fastmail.fm Tue Mar 7 07:16:10 2017 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 0A0B0129440; Tue, 7 Mar 2017 07:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=FoAjW4kC; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=D5Tm4NQR Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFP6e_hkWyLW; Tue, 7 Mar 2017 07:16:08 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0108126DFB; Tue, 7 Mar 2017 07:15:51 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 0E3D120A7F; Tue, 7 Mar 2017 10:15:50 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Tue, 07 Mar 2017 10:15:50 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=nwx7FbiFPxSNbSWMH2/W8ox/ig k=; b=FoAjW4kCXtJvNkSJpC9s/efx5Imst40ppBHiFYDTvXHQFwtNvcMibjoj+A Wbzd4bw9y8HWW9G3SjM/jgi933RY6WZtOK14wUOrijqmKk1j9dPQW8L3Cp0fIzHY iQ5BQ9dRdceqkaaHmHgWw4r3JE1wCV1XLyWwy6FzONuHPzxiA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=nw x7FbiFPxSNbSWMH2/W8ox/igk=; b=D5Tm4NQRuwVl5wljctEJd4cqgczeFpZplv WrEXp7Qazv+ODKD3GR7uq5yF6OLD6mbfzBGo+WI6eKpDys34uHDRNWlaoH7Y7L9N V1dvSrYK1xafRCMR9RCkU+LkERzTL1abCvXFKPEVj8MAuSKeVcUuNTzLW9PTaIeL dioNosU3Q= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id DFCA66AC15; Tue, 7 Mar 2017 10:15:49 -0500 (EST) Message-Id: <1488899749.1393566.903326592.39278005@webmail.messagingengine.com> From: Alexey Melnikov To: Tim Bruijnzeels MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-9f47d516 Date: Tue, 07 Mar 2017 15:15:49 +0000 In-Reply-To: <21741F58-4A12-4A85-9DFF-75E2C0678469@ripe.net> References: <148845266459.19507.8615948310870059270.idtracker@ietfa.amsl.com> <21741F58-4A12-4A85-9DFF-75E2C0678469@ripe.net> Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, draft-ietf-sidr-delta-protocol@ietf.org Subject: Re: [sidr] Alexey Melnikov's Discuss on draft-ietf-sidr-delta-protocol-07: (with DISCUSS and COMMENT) 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 Mar 2017 15:16:10 -0000 Hi Tim, On Tue, Mar 7, 2017, at 01:38 PM, Tim Bruijnzeels wrote: > Hi all, > > > On 02 Mar 2017, at 12:04, Alexey Melnikov wrote: > > > > Alexey Melnikov has entered the following ballot position for > > draft-ietf-sidr-delta-protocol-07: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I would be happy to ballot Yes on this document, as it is well written > > and is a useful piece of work. However I have one issue (and a few minor > > comments) that I would like to DISCUSS before doing so: > > > > In Section 5.3 the document says: > > > > 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) [RFC2818]. > > > > RFC 7525 is referencing RFC 6125 for server hostname validation. > > Unfortunately this is not detailed enough to perform hostname validation, > > because reference to RFC 6125 requires specifying answers to every > > question in section 3 of RFC 6125. (And there is no generic RFC that > > specifies how this is done for protocols using HTTP.) One example of how > > this might look like is in Section 9.2 of > > . > > For your convenience the relevant text is pasted below: > > > > Routers MUST also verify the cache's TLS server certificate, using > > subjectAltName dNSName identities as described in [RFC6125], to > > avoid > > man-in-the-middle attacks. The rules and guidelines defined in > > [RFC6125] apply here, with the following considerations: > > > > Support for DNS-ID identifier type (that is, the dNSName identity > > in the subjectAltName extension) is REQUIRED in rpki-rtr server > > and client implementations which use TLS. Certification > > authorities which issue rpki-rtr server certificates MUST support > > the DNS-ID identifier type, and the DNS-ID identifier type MUST > > be > > present in rpki-rtr server certificates. > > > > DNS names in rpki-rtr server certificates SHOULD NOT contain the > > wildcard character "*". > > > > rpki-rtr implementations which use TLS MUST NOT use CN-ID > > identifiers; a CN field may be present in the server > > certificate's > > subject name, but MUST NOT be used for authentication within the > > rules described in [RFC6125]. > > > > The only thing missing from the above is explicit mentioning that SRV-ID > > and URI-ID are not used. (I think the same should apply to your > > document.) > > Considering that we also say: > > Relying Party tools SHOULD log any TLS certificate or host name > validation issues thus found, so that an operator can investigate the > cause. However, such validation issues are often due to > configuration errors, or a lack of a common TLS trust anchor. In > these cases it is better if the Relying Party retrieves the signed > RPKI data regardless, and performs validation on it. Therefore > Relying Party MUST continue to retrieve the data in case of errors. > The Relying Party MAY choose to log encountered issues only when > fetching the notification update file, but not when it subsequently > fetches snapshot or delta files from the same host. Furthermore the > Relying Party MAY provide a way for operators to accept untrusted > connections for a given host, after the cause has been identified. > > > And because in practice Relying Party software will use standard software > libraries to do retrieval and verification, and it may be hard or even > impossible to configure these libraries to do the verification as > described.. would you agree with the following? Essentially taking your > suggested lead, but never exceeding "SHOULD" in the "how" of the TLS > certificate and host name validation that itself is a SHOULD, i.e.: I think it would be clearer to say that *if* validation is done, it will use the following MUST/MUST NOTs. (And if validation fails, you log as you recommend elsewhere.) Otherwise it would not be very clear when it is Ok to violate various SHOULD/SHOULD NOTs. > Note that a Man-in-the-Middle (MITM) cannot produce validly signed > RPKI data, but can perform withhold or replay attacks targeting an > Relying Party, and keep the Relying Party from learning about changes > in the RPKI. Because of this Relying Parties SHOULD do TLS > certificate and host name validation when they fetch from an RRDP > Repository Server, using subjectAltName dNSName identities as > described in [RFC6125]. The rules and guidelines defined in > [RFC6125] apply here, with the following considerations: > > o Relying Parties and Repository Servers SHOULD support the DNS-ID > identifier type. The DNS-ID identifier type SHOULD be present in > Repository Server certificates. > > o DNS names in Repository Server certificates SHOULD NOT contain the > wildcard character "*". > > o A CN field may be present in Repository Server certificates's > subject name, but SHOULD NOT be used for authentication within the > rules described in [RFC6125]. > > o This protocol does not require the use of SRV-IDs. > > o This protocol does not require the use of URI-IDs. > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > In 3.2: HTTPS reference is out-of-date. > > updated to RFC7230 > > > SHA-256 needs a reference. > > ok, added a normative reference (same as in the publication protocol > document): > > [SHS] National Institute of Standards and Technology, "Secure > Hash Standard", March 2012, > fips-180-4.pdf>. > From nobody Wed Mar 8 01:29:22 2017 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 9F781128DF6; Wed, 8 Mar 2017 01:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKHMOF8CTMij; Wed, 8 Mar 2017 01:29:16 -0800 (PST) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25A25127071; Wed, 8 Mar 2017 01:29:16 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from ) id 1clXuA-0009jl-6B; Wed, 08 Mar 2017 10:29:12 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-29.ripe.net) by titi.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1clXu9-0000IL-UF; Wed, 08 Mar 2017 10:29:10 +0100 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_73ADC7BB-1BA6-4307-A083-7AC16272656C" From: Tim Bruijnzeels In-Reply-To: <1488899749.1393566.903326592.39278005@webmail.messagingengine.com> Date: Wed, 8 Mar 2017 10:29:09 +0100 Message-Id: <59445365-C238-4623-9C56-F640CF607C22@ripe.net> References: <148845266459.19507.8615948310870059270.idtracker@ietfa.amsl.com> <21741F58-4A12-4A85-9DFF-75E2C0678469@ripe.net> <1488899749.1393566.903326592.39278005@webmail.messagingengine.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------ X-RIPE-Spam-Report: Spam Total Points: -6.0 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 HTML_MESSAGE BODY: HTML included in message 1.5 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07194d51533466a958862265b4aba739d129 Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, draft-ietf-sidr-delta-protocol@ietf.org Subject: Re: [sidr] Alexey Melnikov's Discuss on draft-ietf-sidr-delta-protocol-07: (with DISCUSS and COMMENT) 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, 08 Mar 2017 09:29:20 -0000 --Apple-Mail=_73ADC7BB-1BA6-4307-A083-7AC16272656C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Alexey > On 07 Mar 2017, at 16:15, Alexey Melnikov = wrote: >=20 > Hi Tim, >=20 > On Tue, Mar 7, 2017, at 01:38 PM, Tim Bruijnzeels wrote: >> Hi all, >>=20 >>> On 02 Mar 2017, at 12:04, Alexey Melnikov = wrote: >>>=20 >>> Alexey Melnikov has entered the following ballot position for >>> draft-ietf-sidr-delta-protocol-07: Discuss >>>=20 >>> When responding, please keep the subject line intact and reply to = all >>> email addresses included in the To and CC lines. (Feel free to cut = this >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> I would be happy to ballot Yes on this document, as it is well = written >>> and is a useful piece of work. However I have one issue (and a few = minor >>> comments) that I would like to DISCUSS before doing so: >>>=20 >>> In Section 5.3 the document says: >>>=20 >>> 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) [RFC2818]. >>>=20 >>> RFC 7525 is referencing RFC 6125 for server hostname validation. >>> Unfortunately this is not detailed enough to perform hostname = validation, >>> because reference to RFC 6125 requires specifying answers to every >>> question in section 3 of RFC 6125. (And there is no generic RFC that >>> specifies how this is done for protocols using HTTP.) One example of = how >>> this might look like is in Section 9.2 of >>> = . >>> For your convenience the relevant text is pasted below: >>>=20 >>> Routers MUST also verify the cache's TLS server certificate, using >>> subjectAltName dNSName identities as described in [RFC6125], to >>> avoid >>> man-in-the-middle attacks. The rules and guidelines defined in >>> [RFC6125] apply here, with the following considerations: >>>=20 >>> Support for DNS-ID identifier type (that is, the dNSName = identity >>> in the subjectAltName extension) is REQUIRED in rpki-rtr server >>> and client implementations which use TLS. Certification >>> authorities which issue rpki-rtr server certificates MUST = support >>> the DNS-ID identifier type, and the DNS-ID identifier type MUST >>> be >>> present in rpki-rtr server certificates. >>>=20 >>> DNS names in rpki-rtr server certificates SHOULD NOT contain the >>> wildcard character "*". >>>=20 >>> rpki-rtr implementations which use TLS MUST NOT use CN-ID >>> identifiers; a CN field may be present in the server >>> certificate's >>> subject name, but MUST NOT be used for authentication within the >>> rules described in [RFC6125]. >>>=20 >>> The only thing missing from the above is explicit mentioning that = SRV-ID >>> and URI-ID are not used. (I think the same should apply to your >>> document.) >>=20 >> Considering that we also say: >>=20 >> Relying Party tools SHOULD log any TLS certificate or host name >> validation issues thus found, so that an operator can investigate = the >> cause. However, such validation issues are often due to >> configuration errors, or a lack of a common TLS trust anchor. In >> these cases it is better if the Relying Party retrieves the signed >> RPKI data regardless, and performs validation on it. Therefore >> Relying Party MUST continue to retrieve the data in case of errors. >> The Relying Party MAY choose to log encountered issues only when >> fetching the notification update file, but not when it subsequently >> fetches snapshot or delta files from the same host. Furthermore = the >> Relying Party MAY provide a way for operators to accept untrusted >> connections for a given host, after the cause has been identified. >>=20 >>=20 >> And because in practice Relying Party software will use standard = software >> libraries to do retrieval and verification, and it may be hard or = even >> impossible to configure these libraries to do the verification as >> described.. would you agree with the following? Essentially taking = your >> suggested lead, but never exceeding "SHOULD" in the "how" of the TLS >> certificate and host name validation that itself is a SHOULD, i.e.: >=20 > I think it would be clearer to say that *if* validation is done, it = will > use the following MUST/MUST NOTs. (And if validation fails, you log as > you recommend elsewhere.) Otherwise it would not be very clear when it > is Ok to violate various SHOULD/SHOULD NOTs. I see your point regarding clarity, but my main point is that I believe = it would be overkill to have MUSTs. It may not be possible to enforce = this behaviour in standard libraries of the language of choice for = Relying Party implementations (currently Java (RIPE NCC), Python = (rcynic) and C I believe for RIPSTR). And since we have RPKI object = security I don't believe it would be a big issue if for example a = wildcard certificate is used. I really do not want to have to implement our own https client library = for this. It would require a lot of work and maintenance, and on the = whole it would make our implementation brittle. I want to be able to use = one of the widely used and tested standard libraries for this, even if = they violate a SHOULD. Of course I am willing to see whether we can = tweak behaviour of said libraries, but again this may not possible. If you agree, would it help if we moved the text around a bit (so that = the security motivation comes first) and add this explanation explicitly = at the end: 4.3. HTTPS considerations Note that a Man-in-the-Middle (MITM) cannot produce validly signed RPKI data, but can perform withhold or replay attacks targeting an Relying Party, and keep the Relying Party from learning about changes in the RPKI. Because of this Relying Parties SHOULD do TLS certificate and host name validation when they fetch from an RRDP Repository Server. Relying Party tools SHOULD log any TLS certificate or host name validation issues found, so that an operator can investigate the cause. However, such validation issues are often due to configuration errors, or a lack of a common TLS trust anchor. In these cases it is better if the Relying Party retrieves the signed RPKI data regardless, and performs validation on it. Therefore Relying Party MUST continue to retrieve the data in case of errors. The Relying Party MAY choose to log encountered issues only when fetching the notification update file, but not when it subsequently fetches snapshot or delta files from the same host. Furthermore the Relying Party MAY provide a way for operators to accept untrusted connections for a given host, after the cause has been identified. It is RECOMMENDED that Relying Parties and Repository Servers follow the Best Current Practices outlined in [RFC7525] on the use of HTTP over TLS (HTTPS) [RFC7230]. Relying Parties SHOULD do TLS certificate and host name validation using subjectAltName dNSName identities as described in [RFC6125]. The rules and guidelines defined in [RFC6125] apply here, with the following considerations: o Relying Parties and Repository Servers SHOULD support the DNS-ID identifier type. The DNS-ID identifier type SHOULD be present in Repository Server certificates. o DNS names in Repository Server certificates SHOULD NOT contain the wildcard character "*". o A CN field may be present in Repository Server certificates's subject name, but SHOULD NOT be used for authentication within the rules described in [RFC6125]. o This protocol does not require the use of SRV-IDs. o This protocol does not require the use of URI-IDs. Note however that this validation is done on a best effort basis, and serves to highlight potential issues, but RPKI object security does not depend on this. Therefore Relying Parties MAY deviate from the validation steps listed above, in particular in case standard widely used software libraries in the language of the Relying Party software implementation do not support and/or cannot be configured to function this way. Thanks Tim >=20 >> Note that a Man-in-the-Middle (MITM) cannot produce validly signed >> RPKI data, but can perform withhold or replay attacks targeting an >> Relying Party, and keep the Relying Party from learning about = changes >> in the RPKI. Because of this Relying Parties SHOULD do TLS >> certificate and host name validation when they fetch from an RRDP >> Repository Server, using subjectAltName dNSName identities as >> described in [RFC6125]. The rules and guidelines defined in >> [RFC6125] apply here, with the following considerations: >>=20 >> o Relying Parties and Repository Servers SHOULD support the DNS-ID >> identifier type. The DNS-ID identifier type SHOULD be present in >> Repository Server certificates. >>=20 >> o DNS names in Repository Server certificates SHOULD NOT contain = the >> wildcard character "*". >>=20 >> o A CN field may be present in Repository Server certificates's >> subject name, but SHOULD NOT be used for authentication within = the >> rules described in [RFC6125]. >>=20 >> o This protocol does not require the use of SRV-IDs. >>=20 >> o This protocol does not require the use of URI-IDs. >>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> In 3.2: HTTPS reference is out-of-date. >>=20 >> updated to RFC7230 >>=20 >>> SHA-256 needs a reference. >>=20 >> ok, added a normative reference (same as in the publication protocol >> document): >>=20 >> [SHS] National Institute of Standards and Technology, "Secure >> Hash Standard", March 2012, >> > fips-180-4.pdf>. --Apple-Mail=_73ADC7BB-1BA6-4307-A083-7AC16272656C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Alexey

On 07 Mar 2017, at 16:15, = Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

Hi Tim,

On Tue, Mar 7, 2017, at 01:38 PM, Tim = Bruijnzeels wrote:
Hi all,

On 02 Mar 2017, at 12:04, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

Alexey Melnikov has entered the following ballot position = for
draft-ietf-sidr-delta-protocol-07: Discuss

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)


Please = refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor 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-delta-protocol= /



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

I would be happy to ballot Yes on = this document, as it is well written
and is a useful piece = of work. However I have one issue (and a few minor
comments)= that I would like to DISCUSS before doing so:

In Section 5.3 the document says:

 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) [RFC2818].

RFC 7525 is referencing RFC 6125 for server hostname = validation.
Unfortunately this is not detailed enough to = perform hostname validation,
because reference to RFC 6125 = requires specifying answers to every
question in section 3 = of RFC 6125. (And there is no generic RFC that
specifies = how this is done for protocols using HTTP.) One example of how
this might look like is in Section 9.2 of
<https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-r= fc6810-bis/?include_text=3D1>.
For your convenience the = relevant text is pasted below:

 Routers = MUST also verify the cache's TLS server certificate, using
 subjectAltName dNSName identities as described in = [RFC6125], to
avoid
 man-in-the-middle = attacks.  The rules and guidelines defined in
 [RFC6125] apply here, with the following = considerations:

    Support for DNS-ID identifier type = (that is, the dNSName identity
    in = the subjectAltName extension) is REQUIRED in rpki-rtr server
    and client implementations which use = TLS.  Certification
    authorities= which issue rpki-rtr server certificates MUST support
    the DNS-ID identifier type, and the = DNS-ID identifier type MUST
be
    present in rpki-rtr server = certificates.

    DNS = names in rpki-rtr server certificates SHOULD NOT contain the
    wildcard character "*".

    rpki-rtr = implementations which use TLS MUST NOT use CN-ID
    identifiers; a CN field may be = present in the server
certificate's
    subject name, but MUST NOT be used = for authentication within the
    rules = described in [RFC6125].

The only thing = missing from the above is explicit mentioning that SRV-ID
and URI-ID are not used. (I think the same should apply to = your
document.)

Considering that we also say:

  Relying Party tools SHOULD log any TLS = certificate or host name
  validation issues = thus found, so that an operator can investigate the
  cause.  However, such validation issues are = often due to
  configuration errors, or a lack = of a common TLS trust anchor.  In
  these = cases it is better if the Relying Party retrieves the signed
  RPKI data regardless, and performs validation on = it.  Therefore
  Relying Party MUST = continue to retrieve the data in case of errors.
  The Relying Party MAY choose to log encountered = issues only when
  fetching the notification = update file, but not when it subsequently
  fetches snapshot or delta files from the same = host.  Furthermore the
  Relying Party MAY = provide a way for operators to accept untrusted
  connections for a given host, after the cause has = been identified.


And because = in practice Relying Party software will use standard software
libraries to do retrieval and verification, and it may be = hard or even
impossible to configure these libraries to do = the verification as
described.. would you agree with the = following? Essentially taking your
suggested lead, but = never exceeding "SHOULD" in the "how" of the TLS
certificate= and host name validation that itself is a SHOULD, i.e.:

I think it would be clearer to say that *if* = validation is done, it will
use the following MUST/MUST NOTs. (And if = validation fails, you log as
you recommend elsewhere.) Otherwise it = would not be very clear when it
is Ok to violate various SHOULD/SHOULD = NOTs.

I see your = point regarding clarity, but my main point is that I believe it would be = overkill to have MUSTs. It may not be possible to enforce this behaviour = in standard libraries of the language of choice for Relying Party = implementations (currently Java (RIPE NCC), Python (rcynic) and C I = believe for RIPSTR). And since we have RPKI object security I don't = believe it would be a big issue if for example a wildcard certificate is = used.

I really do not want to have = to implement our own https client library for this. It would require a = lot of work and maintenance, and on the whole it would make our = implementation brittle. I want to be able to use one of the widely used = and tested standard libraries for this, even if they violate a SHOULD. = Of course I am willing to see whether we can tweak behaviour of said = libraries, but again this may not possible.

If you agree, would it help if we moved the text = around a bit (so that the security motivation comes first) and add this = explanation explicitly at the end:

4.3.  HTTPS considerations

   Note that a Man-in-the-Middle (MITM) cannot = produce validly signed
   RPKI data, but can = perform withhold or replay attacks targeting an
  =  Relying Party, and keep the Relying Party from learning about = changes
   in the RPKI.  Because of this = Relying Parties SHOULD do TLS
   certificate and = host name validation when they fetch from an RRDP
  =  Repository Server.

  =  Relying Party tools SHOULD log any TLS certificate or host name
   validation issues found, so that an operator can = investigate the
   cause.  However, such = validation issues are often due to
  =  configuration errors, or a lack of a common TLS trust anchor. =  In
   these cases it is better if the = Relying Party retrieves the signed
   RPKI data = regardless, and performs validation on it.  Therefore
   Relying Party MUST continue to retrieve the data = in case of errors.
   The Relying Party MAY = choose to log encountered issues only when
  =  fetching the notification update file, but not when it = subsequently
   fetches snapshot or delta files = from the same host.  Furthermore the
  =  Relying Party MAY provide a way for operators to accept = untrusted
   connections for a given host, after = the cause has been identified.

  =  It is RECOMMENDED that Relying Parties and Repository Servers = follow
   the Best Current Practices outlined in = [RFC7525] on the use of HTTP
   over TLS (HTTPS) = [RFC7230].  Relying Parties SHOULD do TLS
  =  certificate and host name validation using subjectAltName = dNSName
   identities as described in [RFC6125]. =  The rules and guidelines
   defined in = [RFC6125] apply here, with the following considerations:
   o  Relying Parties and Repository Servers = SHOULD support the DNS-ID
      identifier = type.  The DNS-ID identifier type SHOULD be present in
      Repository Server certificates.

   o  DNS names in Repository = Server certificates SHOULD NOT contain the
    =   wildcard character "*".

  =  o  A CN field may be present in Repository Server = certificates's
      subject name, but = SHOULD NOT be used for authentication within the
  =     rules described in [RFC6125].

   o  This protocol does not require the use = of SRV-IDs.

   o  This = protocol does not require the use of URI-IDs.

   Note however that this validation is done on a = best effort basis, and
   serves to highlight = potential issues, but RPKI object security does
  =  not depend on this.  Therefore Relying Parties MAY deviate = from the
   validation steps listed above, in = particular in case standard widely
   used = software libraries in the language of the Relying Party software
   implementation do not support and/or cannot be = configured to function
   this = way.








Thanks
Tim




  Note that a Man-in-the-Middle (MITM) cannot = produce validly signed
  RPKI data, but can = perform withhold or replay attacks targeting an
  Relying Party, and keep the Relying Party from = learning about changes
  in the RPKI. =  Because of this Relying Parties SHOULD do TLS
  certificate and host name validation when they = fetch from an RRDP
  Repository Server, using = subjectAltName dNSName identities as
  described = in [RFC6125].  The rules and guidelines defined in
  [RFC6125] apply here, with the following = considerations:

  o  Relying = Parties and Repository Servers SHOULD support the DNS-ID
     identifier type. The DNS-ID = identifier type SHOULD be present in
     Repository Server = certificates.

  o  DNS names = in Repository Server certificates SHOULD NOT contain the
     wildcard character "*".

  o  A CN field may be present = in Repository Server certificates's
     subject name, but SHOULD NOT be = used for authentication within the
     rules described in = [RFC6125].

  o  This = protocol does not require the use of SRV-IDs.

  o  This protocol does not require the use of = URI-IDs.



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

In 3.2: HTTPS reference is = out-of-date.

updated to = RFC7230

SHA-256 needs a reference.

ok, added a normative reference (same as in the publication = protocol
document):

  [SHS]      National = Institute of Standards and Technology, "Secure
          &nb= sp;  Hash Standard", March 2012,
          &nb= sp;  <http://csrc.nist.gov/publications/fips/fips180-4/
          &nb= sp;  fips-180-4.pdf>.
= --Apple-Mail=_73ADC7BB-1BA6-4307-A083-7AC16272656C-- From nobody Wed Mar 8 01:48:47 2017 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 7C5BD12943F; Wed, 8 Mar 2017 01:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=ouyApIL6; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=fbso+PGz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SK-9_J98m5NQ; Wed, 8 Mar 2017 01:48:42 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CCF6129431; Wed, 8 Mar 2017 01:48:42 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id B867D20CF0; Wed, 8 Mar 2017 04:48:41 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 08 Mar 2017 04:48:41 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=8s2Dqzdzt07NvCQ EXuQN2/nnDyI=; b=ouyApIL6c1P69fOKwDdFMAAOGPXcE/U1Fbbj/p0D3v7rRkU 84sqyXg32/UFCXP7vkKiyWQg9/nYPb3Gb56E9Duy48hvo439Q3NVplHdj+wLumjR e83k/mFAIBh/212Bg3lpiXRUr0VklRxmVWMcp+aHHcFCLyUgAmf9PTe2Rblc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=8s2Dqzdzt07NvCQEXuQN2/nnDyI=; b=fbso+PGz+tly16b2CoBs SXpwxJPyEiPSMNq2fY5CE9WF3qXdg1QMGfY0xsZX7iIW0g3aJn8HnKks3V4d1Cmy siHipa0/Lw3ip80WLgLhGoh1rVvI8LvEouVoT8v/3+C466bcCzmgYF4o9dD5aCdJ I+dJwTtiyifOT3qEGIZyNKA= X-ME-Sender: X-Sasl-enc: moILcZzpeOdEWed2fvopcaLm2bXCkiuipwKx6trgCerF 1488966521 Received: from [10.232.159.250] (unknown [185.69.145.100]) by mail.messagingengine.com (Postfix) with ESMTPA id 0AF8C7E41F; Wed, 8 Mar 2017 04:48:41 -0500 (EST) Content-Type: multipart/alternative; boundary=Apple-Mail-65653715-2444-4E89-BE9B-905D5871AB83 Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: <59445365-C238-4623-9C56-F640CF607C22@ripe.net> Date: Wed, 8 Mar 2017 10:01:21 +0000 Content-Transfer-Encoding: 7bit Message-Id: References: <148845266459.19507.8615948310870059270.idtracker@ietfa.amsl.com> <21741F58-4A12-4A85-9DFF-75E2C0678469@ripe.net> <1488899749.1393566.903326592.39278005@webmail.messagingengine.com> <59445365-C238-4623-9C56-F640CF607C22@ripe.net> To: Tim Bruijnzeels Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, draft-ietf-sidr-delta-protocol@ietf.org Subject: Re: [sidr] Alexey Melnikov's Discuss on draft-ietf-sidr-delta-protocol-07: (with DISCUSS and COMMENT) 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, 08 Mar 2017 09:48:45 -0000 --Apple-Mail-65653715-2444-4E89-BE9B-905D5871AB83 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Tim, (Top post) I think your latest suggested text is good enough, so polishing it more is n= ot going to improve the document in a significant way. So please post a new v= ersion with it. Thank you, Alexey > On 8 Mar 2017, at 09:29, Tim Bruijnzeels wrote: >=20 > Hi Alexey >=20 >> On 07 Mar 2017, at 16:15, Alexey Melnikov wrote:= >>=20 >> Hi Tim, >>=20 >>> On Tue, Mar 7, 2017, at 01:38 PM, Tim Bruijnzeels wrote: >>> Hi all, >>>=20 >>>> On 02 Mar 2017, at 12:04, Alexey Melnikov wrot= e: >>>>=20 >>>> Alexey Melnikov has entered the following ballot position for >>>> draft-ietf-sidr-delta-protocol-07: Discuss >>>>=20 >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this= >>>> introductory paragraph, however.) >>>>=20 >>>>=20 >>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml >>>> for more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ >>>>=20 >>>>=20 >>>>=20 >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>>=20 >>>> I would be happy to ballot Yes on this document, as it is well written >>>> and is a useful piece of work. However I have one issue (and a few mino= r >>>> comments) that I would like to DISCUSS before doing so: >>>>=20 >>>> In Section 5.3 the document says: >>>>=20 >>>> 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) [RFC2818]. >>>>=20 >>>> RFC 7525 is referencing RFC 6125 for server hostname validation. >>>> Unfortunately this is not detailed enough to perform hostname validatio= n, >>>> because reference to RFC 6125 requires specifying answers to every >>>> question in section 3 of RFC 6125. (And there is no generic RFC that >>>> specifies how this is done for protocols using HTTP.) One example of ho= w >>>> this might look like is in Section 9.2 of >>>> . >>>> For your convenience the relevant text is pasted below: >>>>=20 >>>> Routers MUST also verify the cache's TLS server certificate, using >>>> subjectAltName dNSName identities as described in [RFC6125], to >>>> avoid >>>> man-in-the-middle attacks. The rules and guidelines defined in >>>> [RFC6125] apply here, with the following considerations: >>>>=20 >>>> Support for DNS-ID identifier type (that is, the dNSName identity >>>> in the subjectAltName extension) is REQUIRED in rpki-rtr server >>>> and client implementations which use TLS. Certification >>>> authorities which issue rpki-rtr server certificates MUST support >>>> the DNS-ID identifier type, and the DNS-ID identifier type MUST >>>> be >>>> present in rpki-rtr server certificates. >>>>=20 >>>> DNS names in rpki-rtr server certificates SHOULD NOT contain the >>>> wildcard character "*". >>>>=20 >>>> rpki-rtr implementations which use TLS MUST NOT use CN-ID >>>> identifiers; a CN field may be present in the server >>>> certificate's >>>> subject name, but MUST NOT be used for authentication within the >>>> rules described in [RFC6125]. >>>>=20 >>>> The only thing missing from the above is explicit mentioning that SRV-I= D >>>> and URI-ID are not used. (I think the same should apply to your >>>> document.) >>>=20 >>> Considering that we also say: >>>=20 >>> Relying Party tools SHOULD log any TLS certificate or host name >>> validation issues thus found, so that an operator can investigate the >>> cause. However, such validation issues are often due to >>> configuration errors, or a lack of a common TLS trust anchor. In >>> these cases it is better if the Relying Party retrieves the signed >>> RPKI data regardless, and performs validation on it. Therefore >>> Relying Party MUST continue to retrieve the data in case of errors. >>> The Relying Party MAY choose to log encountered issues only when >>> fetching the notification update file, but not when it subsequently >>> fetches snapshot or delta files from the same host. Furthermore the >>> Relying Party MAY provide a way for operators to accept untrusted >>> connections for a given host, after the cause has been identified. >>>=20 >>>=20 >>> And because in practice Relying Party software will use standard softwar= e >>> libraries to do retrieval and verification, and it may be hard or even >>> impossible to configure these libraries to do the verification as >>> described.. would you agree with the following? Essentially taking your >>> suggested lead, but never exceeding "SHOULD" in the "how" of the TLS >>> certificate and host name validation that itself is a SHOULD, i.e.: >>=20 >> I think it would be clearer to say that *if* validation is done, it will >> use the following MUST/MUST NOTs. (And if validation fails, you log as >> you recommend elsewhere.) Otherwise it would not be very clear when it >> is Ok to violate various SHOULD/SHOULD NOTs. >=20 > I see your point regarding clarity, but my main point is that I believe it= would be overkill to have MUSTs. It may not be possible to enforce this beh= aviour in standard libraries of the language of choice for Relying Party imp= lementations (currently Java (RIPE NCC), Python (rcynic) and C I believe for= RIPSTR). And since we have RPKI object security I don't believe it would be= a big issue if for example a wildcard certificate is used. >=20 > I really do not want to have to implement our own https client library for= this. It would require a lot of work and maintenance, and on the whole it w= ould make our implementation brittle. I want to be able to use one of the wi= dely used and tested standard libraries for this, even if they violate a SHO= ULD. Of course I am willing to see whether we can tweak behaviour of said li= braries, but again this may not possible. >=20 > If you agree, would it help if we moved the text around a bit (so that the= security motivation comes first) and add this explanation explicitly at the= end: >=20 > 4.3. HTTPS considerations >=20 > Note that a Man-in-the-Middle (MITM) cannot produce validly signed > RPKI data, but can perform withhold or replay attacks targeting an > Relying Party, and keep the Relying Party from learning about changes > in the RPKI. Because of this Relying Parties SHOULD do TLS > certificate and host name validation when they fetch from an RRDP > Repository Server. >=20 > Relying Party tools SHOULD log any TLS certificate or host name > validation issues found, so that an operator can investigate the > cause. However, such validation issues are often due to > configuration errors, or a lack of a common TLS trust anchor. In > these cases it is better if the Relying Party retrieves the signed > RPKI data regardless, and performs validation on it. Therefore > Relying Party MUST continue to retrieve the data in case of errors. > The Relying Party MAY choose to log encountered issues only when > fetching the notification update file, but not when it subsequently > fetches snapshot or delta files from the same host. Furthermore the > Relying Party MAY provide a way for operators to accept untrusted > connections for a given host, after the cause has been identified. >=20 > It is RECOMMENDED that Relying Parties and Repository Servers follow > the Best Current Practices outlined in [RFC7525] on the use of HTTP > over TLS (HTTPS) [RFC7230]. Relying Parties SHOULD do TLS > certificate and host name validation using subjectAltName dNSName > identities as described in [RFC6125]. The rules and guidelines > defined in [RFC6125] apply here, with the following considerations: >=20 > o Relying Parties and Repository Servers SHOULD support the DNS-ID > identifier type. The DNS-ID identifier type SHOULD be present in > Repository Server certificates. >=20 > o DNS names in Repository Server certificates SHOULD NOT contain the > wildcard character "*". >=20 > o A CN field may be present in Repository Server certificates's > subject name, but SHOULD NOT be used for authentication within the > rules described in [RFC6125]. >=20 > o This protocol does not require the use of SRV-IDs. >=20 > o This protocol does not require the use of URI-IDs. >=20 > Note however that this validation is done on a best effort basis, and > serves to highlight potential issues, but RPKI object security does > not depend on this. Therefore Relying Parties MAY deviate from the > validation steps listed above, in particular in case standard widely > used software libraries in the language of the Relying Party software > implementation do not support and/or cannot be configured to function > this way. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Thanks > Tim >=20 >=20 >=20 >>=20 >>> Note that a Man-in-the-Middle (MITM) cannot produce validly signed >>> RPKI data, but can perform withhold or replay attacks targeting an >>> Relying Party, and keep the Relying Party from learning about changes >>> in the RPKI. Because of this Relying Parties SHOULD do TLS >>> certificate and host name validation when they fetch from an RRDP >>> Repository Server, using subjectAltName dNSName identities as >>> described in [RFC6125]. The rules and guidelines defined in >>> [RFC6125] apply here, with the following considerations: >>>=20 >>> o Relying Parties and Repository Servers SHOULD support the DNS-ID >>> identifier type. The DNS-ID identifier type SHOULD be present in >>> Repository Server certificates. >>>=20 >>> o DNS names in Repository Server certificates SHOULD NOT contain the >>> wildcard character "*". >>>=20 >>> o A CN field may be present in Repository Server certificates's >>> subject name, but SHOULD NOT be used for authentication within the >>> rules described in [RFC6125]. >>>=20 >>> o This protocol does not require the use of SRV-IDs. >>>=20 >>> o This protocol does not require the use of URI-IDs. >>>=20 >>>>=20 >>>>=20 >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>>=20 >>>> In 3.2: HTTPS reference is out-of-date. >>>=20 >>> updated to RFC7230 >>>=20 >>>> SHA-256 needs a reference. >>>=20 >>> ok, added a normative reference (same as in the publication protocol >>> document): >>>=20 >>> [SHS] National Institute of Standards and Technology, "Secure >>> Hash Standard", March 2012, >>> >> fips-180-4.pdf>. >=20 --Apple-Mail-65653715-2444-4E89-BE9B-905D5871AB83 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Tim,
(Top post)

I think your latest suggested text is goo= d enough, so polishing it more is not going to improve the document in a sig= nificant way. So please post a new version with it.

Thank you,
Alexey

On 8 Mar 2017, at 09:29, Tim Brui= jnzeels <tim@ripe.net> wrote:
<= br>
Hi Alexey

On 07 Mar 2017,= at 16:15, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

Hi Tim,

On Tue, Mar 7, 2017, at 01:38 PM, Tim Bruijnzeels wrote= :
Hi all,
On 02 Mar 2017, at 12:04, A= lexey Melnikov <aame= lnikov@fastmail.fm> wrote:

Alexey Melnik= ov has entered the following ballot position for
draft-ietf-si= dr-delta-protocol-07: Discuss

When responding, p= lease keep the subject line intact and reply to all
email addr= esses 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 p= ositions.


The document, along wi= th other ballot positions, can be found here:
http= s://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/



----------------------------= ------------------------------------------
DISCUSS:
----------------------------------------------------------------------
I would be happy to ballot Yes on this document, a= s it is well written
and is a useful piece of work. However I h= ave one issue (and a few minor
comments) that I would like to D= ISCUSS before doing so:

In Section 5.3 the docu= ment says:

 It is RECOMMENDED that Relying= Parties and Publication Servers
follow
 th= e Best Current Practices outlined in [RFC7525] on the use of HTTP
 over TLS (HTTPS) [RFC2818].

RFC 7525 i= s referencing RFC 6125 for server hostname validation.
Unfortu= nately this is not detailed enough to perform hostname validation,
because reference to RFC 6125 requires specifying answers to every
question in section 3 of RFC 6125. (And there is no generic RFC that=
specifies how this is done for protocols using HTTP.) One exa= mple of how
this might look like is in Section 9.2 of
<https://datatracker.ietf.org/doc/draft-iet= f-sidr-rpki-rtr-rfc6810-bis/?include_text=3D1>.
For you= r convenience the relevant text is pasted below:

 Routers MUST also verify the cache's TLS server certificate, using subjectAltName dNSName identities as described in [RFC612= 5], to
avoid
 man-in-the-middle attacks. &n= bsp;The rules and guidelines defined in
 [RFC6125] apply h= ere, with the following considerations:

 &= nbsp;  Support for DNS-ID identifier type (that is, the dNSName id= entity
    in the subjectAltName extension= ) is REQUIRED in rpki-rtr server
    and c= lient implementations which use TLS.  Certification
 = ;   authorities which issue rpki-rtr server certificates MUST= support
    the DNS-ID identifier type, a= nd the DNS-ID identifier type MUST
be
 &nbs= p;  present in rpki-rtr server certificates.

    DNS names in rpki-rtr server certificates SH= OULD NOT contain the
    wildcard characte= r "*".

    rpki-rtr impleme= ntations which use TLS MUST NOT use CN-ID
   &n= bsp;identifiers; a CN field may be present in the server
certi= ficate's
    subject name, but MUST NOT be= used for authentication within the
    ru= les described in [RFC6125].

The only thing miss= ing from the above is explicit mentioning that SRV-ID
and URI-= ID are not used. (I think the same should apply to your
docume= nt.)

Considering that we also say:=

  Relying Party tools SHOULD log any= TLS certificate or host name
  validation issues th= us found, so that an operator can investigate the
  = cause.  However, such validation issues are often due to
=   configuration errors, or a lack of a common TLS trust anchor. &n= bsp;In
  these cases it is better if the Relying Par= ty retrieves the signed
  RPKI data regardless, and p= erforms validation on it.  Therefore
  Relying P= arty MUST continue to retrieve the data in case of errors.
&nb= sp; The Relying Party MAY choose to log encountered issues only when  fetching the notification update file, but not when i= t subsequently
  fetches snapshot or delta files fro= m the same host.  Furthermore the
  Relying Par= ty MAY provide a way for operators to accept untrusted
 &= nbsp;connections for a given host, after the cause has been identified.


And because in practice Relying Part= y software will use standard software
libraries to do retrieva= l and verification, and it may be hard or even
impossible to c= onfigure these libraries to do the verification as
described..= would you agree with the following? Essentially taking your
s= uggested lead, but never exceeding "SHOULD" in the "how" of the TLS
certificate and host name validation that itself is a SHOULD, i.e.:

I think it would be clearer to say that *if* validation is done= , it will
use the following MUST/MUST NOTs. (And if validation fails, you log as
you reco= mmend elsewhere.) Otherwise it would not be very clear when it
is Ok to violate var= ious SHOULD/SHOULD NOTs.

I see your point regarding clarity, but my main point is that I= believe it would be overkill to have MUSTs. It may not be possible to enfor= ce this behaviour in standard libraries of the language of choice for Relyin= g Party implementations (currently Java (RIPE NCC), Python (rcynic) and C I b= elieve for RIPSTR). And since we have RPKI object security I don't believe i= t would be a big issue if for example a wildcard certificate is used.
<= div>
I really do not want to have to implement our o= wn https client library for this. It would require a lot of work and mainten= ance, and on the whole it would make our implementation brittle. I want to b= e able to use one of the widely used and tested standard libraries for this,= even if they violate a SHOULD. Of course I am willing to see whether we can= tweak behaviour of said libraries, but again this may not possible.

If you agree, would it help if we moved the tex= t around a bit (so that the security motivation comes first) and add this ex= planation explicitly at the end:

4.3. &n= bsp;HTTPS considerations

   Note that= a Man-in-the-Middle (MITM) cannot produce validly signed
&nbs= p;  RPKI data, but can perform withhold or replay attacks targeting an<= br class=3D"">   Relying Party, and keep the Relying Party from le= arning about changes
   in the RPKI.  Because o= f this Relying Parties SHOULD do TLS
   certificate a= nd host name validation when they fetch from an RRDP
  &n= bsp;Repository Server.

   Relying Par= ty tools SHOULD log any TLS certificate or host name
  &n= bsp;validation issues found, so that an operator can investigate the
   cause.  However, such validation issues are often d= ue to
   configuration errors, or a lack of a common= TLS trust anchor.  In
   these cases it is bet= ter if the Relying Party retrieves the signed
   RPK= I data regardless, and performs validation on it.  Therefore
   Relying Party MUST continue to retrieve the data in case of e= rrors.
   The Relying Party MAY choose to log encoun= tered issues only when
   fetching the notification u= pdate file, but not when it subsequently
   fetches s= napshot or delta files from the same host.  Furthermore the
   Relying Party MAY provide a way for operators to accept untr= usted
   connections for a given host, after the cau= se has been identified.

   It is RECO= MMENDED that Relying Parties and Repository Servers follow
&nb= sp;  the Best Current Practices outlined in [RFC7525] on the use of HTT= P
   over TLS (HTTPS) [RFC7230].  Relying Parti= es SHOULD do TLS
   certificate and host name valida= tion using subjectAltName dNSName
   identities as d= escribed in [RFC6125].  The rules and guidelines
  &= nbsp;defined in [RFC6125] apply here, with the following considerations:

   o  Relying Parties and Repository= Servers SHOULD support the DNS-ID
      identi= fier type.  The DNS-ID identifier type SHOULD be present in
      Repository Server certificates.

   o  DNS names in Repository Server certificates SH= OULD NOT contain the
      wildcard character "= *".

   o  A CN field may be pres= ent in Repository Server certificates's
      s= ubject name, but SHOULD NOT be used for authentication within the
      rules described in [RFC6125].

   o  This protocol does not require the use of SRV-ID= s.

   o  This protocol does not r= equire the use of URI-IDs.

   Note ho= wever that this validation is done on a best effort basis, and
   serves to highlight potential issues, but RPKI object security= does
   not depend on this.  Therefore Relying= Parties MAY deviate from the
   validation steps li= sted above, in particular in case standard widely
   = ;used software libraries in the language of the Relying Party software
   implementation do not support and/or cannot be configu= red to function
   this way.








Thanks
Tim




  Note that a Man-in-the-Middle (MITM) cannot produce validly si= gned
  RPKI data, but can perform withhold or replay= attacks targeting an
  Relying Party, and keep the R= elying Party from learning about changes
  in the RP= KI.  Because of this Relying Parties SHOULD do TLS
 =  certificate and host name validation when they fetch from an RRDP
  Repository Server, using subjectAltName dNSName identi= ties as
  described in [RFC6125].  The rules an= d guidelines defined in
  [RFC6125] apply here, with= the following considerations:

  o &n= bsp;Relying Parties and Repository Servers SHOULD support the DNS-ID
     identifier type. The DNS-ID identifier t= ype SHOULD be present in
     Reposit= ory Server certificates.

  o  DN= S names in Repository Server certificates SHOULD NOT contain the
     wildcard character "*".

  o  A CN field may be present in Repository Server= certificates's
     subject name, bu= t SHOULD NOT be used for authentication within the
  = ;   rules described in [RFC6125].

  o  This protocol does not require the use of SRV-IDs.

  o  This protocol does not require t= he use of URI-IDs.



-------------------------------------= ---------------------------------
COMMENT:
-----= -----------------------------------------------------------------

In 3.2: HTTPS reference is out-of-date.

updated to RFC7230

SHA-256 needs a reference.

ok, added a normative reference (same as in the pu= blication protocol
document):

&nb= sp; [SHS]      National Institute of Standards= and Technology, "Secure
      &= nbsp;      Hash Standard", March 2012,
           &nb= sp; <http://csrc.nist.gov/publications/fips/fips180-4/
            &n= bsp;fips-180-4.pdf>.

=
= --Apple-Mail-65653715-2444-4E89-BE9B-905D5871AB83-- From nobody Wed Mar 8 06:11:03 2017 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 C499D129698; Wed, 8 Mar 2017 06:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6TVcg-Z4bec; Wed, 8 Mar 2017 06:10:54 -0800 (PST) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DECD129472; Wed, 8 Mar 2017 06:10:54 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from ) id 1clcIj-0007Uv-Au; Wed, 08 Mar 2017 15:10:51 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-29.ripe.net) by titi.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1clcIj-00040M-4Z; Wed, 08 Mar 2017 15:10:49 +0100 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_F7F523B6-40E8-4787-92E6-D7502B74340A" From: Tim Bruijnzeels In-Reply-To: Date: Wed, 8 Mar 2017 15:10:48 +0100 Message-Id: References: <148845266459.19507.8615948310870059270.idtracker@ietfa.amsl.com> <21741F58-4A12-4A85-9DFF-75E2C0678469@ripe.net> <1488899749.1393566.903326592.39278005@webmail.messagingengine.com> <59445365-C238-4623-9C56-F640CF607C22@ripe.net> To: Alexey Melnikov X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------ X-RIPE-Spam-Report: Spam Total Points: -6.0 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 HTML_MESSAGE BODY: HTML included in message 1.5 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719291984f74fa7fe31810a5cb78141642f Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, draft-ietf-sidr-delta-protocol@ietf.org Subject: Re: [sidr] Alexey Melnikov's Discuss on draft-ietf-sidr-delta-protocol-07: (with DISCUSS and COMMENT) 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, 08 Mar 2017 14:10:57 -0000 --Apple-Mail=_F7F523B6-40E8-4787-92E6-D7502B74340A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Alexey, Thanks, I am about to send an update to my co-authors so that they can = also review, and upload it this Friday. Tim > On 08 Mar 2017, at 11:01, Alexey Melnikov = wrote: >=20 > Hi Tim, > (Top post) >=20 > I think your latest suggested text is good enough, so polishing it = more is not going to improve the document in a significant way. So = please post a new version with it. >=20 > Thank you, > Alexey >=20 > On 8 Mar 2017, at 09:29, Tim Bruijnzeels > wrote: >=20 >> Hi Alexey >>=20 >>> On 07 Mar 2017, at 16:15, Alexey Melnikov > wrote: >>>=20 >>> Hi Tim, >>>=20 >>> On Tue, Mar 7, 2017, at 01:38 PM, Tim Bruijnzeels wrote: >>>> Hi all, >>>>=20 >>>>> On 02 Mar 2017, at 12:04, Alexey Melnikov > wrote: >>>>>=20 >>>>> Alexey Melnikov has entered the following ballot position for >>>>> draft-ietf-sidr-delta-protocol-07: Discuss >>>>>=20 >>>>> When responding, please keep the subject line intact and reply to = all >>>>> email addresses included in the To and CC lines. (Feel free to cut = this >>>>> introductory paragraph, however.) >>>>>=20 >>>>>=20 >>>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html = >>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>=20 >>>>>=20 >>>>> The document, along with other ballot positions, can be found = here: >>>>> https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ = >>>>>=20 >>>>>=20 >>>>>=20 >>>>> = ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>> I would be happy to ballot Yes on this document, as it is well = written >>>>> and is a useful piece of work. However I have one issue (and a few = minor >>>>> comments) that I would like to DISCUSS before doing so: >>>>>=20 >>>>> In Section 5.3 the document says: >>>>>=20 >>>>> 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) [RFC2818]. >>>>>=20 >>>>> RFC 7525 is referencing RFC 6125 for server hostname validation. >>>>> Unfortunately this is not detailed enough to perform hostname = validation, >>>>> because reference to RFC 6125 requires specifying answers to every >>>>> question in section 3 of RFC 6125. (And there is no generic RFC = that >>>>> specifies how this is done for protocols using HTTP.) One example = of how >>>>> this might look like is in Section 9.2 of >>>>> = >. >>>>> For your convenience the relevant text is pasted below: >>>>>=20 >>>>> Routers MUST also verify the cache's TLS server certificate, = using >>>>> subjectAltName dNSName identities as described in [RFC6125], to >>>>> avoid >>>>> man-in-the-middle attacks. The rules and guidelines defined in >>>>> [RFC6125] apply here, with the following considerations: >>>>>=20 >>>>> Support for DNS-ID identifier type (that is, the dNSName = identity >>>>> in the subjectAltName extension) is REQUIRED in rpki-rtr = server >>>>> and client implementations which use TLS. Certification >>>>> authorities which issue rpki-rtr server certificates MUST = support >>>>> the DNS-ID identifier type, and the DNS-ID identifier type = MUST >>>>> be >>>>> present in rpki-rtr server certificates. >>>>>=20 >>>>> DNS names in rpki-rtr server certificates SHOULD NOT contain = the >>>>> wildcard character "*". >>>>>=20 >>>>> rpki-rtr implementations which use TLS MUST NOT use CN-ID >>>>> identifiers; a CN field may be present in the server >>>>> certificate's >>>>> subject name, but MUST NOT be used for authentication within = the >>>>> rules described in [RFC6125]. >>>>>=20 >>>>> The only thing missing from the above is explicit mentioning that = SRV-ID >>>>> and URI-ID are not used. (I think the same should apply to your >>>>> document.) >>>>=20 >>>> Considering that we also say: >>>>=20 >>>> Relying Party tools SHOULD log any TLS certificate or host name >>>> validation issues thus found, so that an operator can investigate = the >>>> cause. However, such validation issues are often due to >>>> configuration errors, or a lack of a common TLS trust anchor. In >>>> these cases it is better if the Relying Party retrieves the = signed >>>> RPKI data regardless, and performs validation on it. Therefore >>>> Relying Party MUST continue to retrieve the data in case of = errors. >>>> The Relying Party MAY choose to log encountered issues only when >>>> fetching the notification update file, but not when it = subsequently >>>> fetches snapshot or delta files from the same host. Furthermore = the >>>> Relying Party MAY provide a way for operators to accept untrusted >>>> connections for a given host, after the cause has been = identified. >>>>=20 >>>>=20 >>>> And because in practice Relying Party software will use standard = software >>>> libraries to do retrieval and verification, and it may be hard or = even >>>> impossible to configure these libraries to do the verification as >>>> described.. would you agree with the following? Essentially taking = your >>>> suggested lead, but never exceeding "SHOULD" in the "how" of the = TLS >>>> certificate and host name validation that itself is a SHOULD, i.e.: >>>=20 >>> I think it would be clearer to say that *if* validation is done, it = will >>> use the following MUST/MUST NOTs. (And if validation fails, you log = as >>> you recommend elsewhere.) Otherwise it would not be very clear when = it >>> is Ok to violate various SHOULD/SHOULD NOTs. >>=20 >> I see your point regarding clarity, but my main point is that I = believe it would be overkill to have MUSTs. It may not be possible to = enforce this behaviour in standard libraries of the language of choice = for Relying Party implementations (currently Java (RIPE NCC), Python = (rcynic) and C I believe for RIPSTR). And since we have RPKI object = security I don't believe it would be a big issue if for example a = wildcard certificate is used. >>=20 >> I really do not want to have to implement our own https client = library for this. It would require a lot of work and maintenance, and on = the whole it would make our implementation brittle. I want to be able to = use one of the widely used and tested standard libraries for this, even = if they violate a SHOULD. Of course I am willing to see whether we can = tweak behaviour of said libraries, but again this may not possible. >>=20 >> If you agree, would it help if we moved the text around a bit (so = that the security motivation comes first) and add this explanation = explicitly at the end: >>=20 >> 4.3. HTTPS considerations >>=20 >> Note that a Man-in-the-Middle (MITM) cannot produce validly signed >> RPKI data, but can perform withhold or replay attacks targeting an >> Relying Party, and keep the Relying Party from learning about = changes >> in the RPKI. Because of this Relying Parties SHOULD do TLS >> certificate and host name validation when they fetch from an RRDP >> Repository Server. >>=20 >> Relying Party tools SHOULD log any TLS certificate or host name >> validation issues found, so that an operator can investigate the >> cause. However, such validation issues are often due to >> configuration errors, or a lack of a common TLS trust anchor. In >> these cases it is better if the Relying Party retrieves the signed >> RPKI data regardless, and performs validation on it. Therefore >> Relying Party MUST continue to retrieve the data in case of = errors. >> The Relying Party MAY choose to log encountered issues only when >> fetching the notification update file, but not when it = subsequently >> fetches snapshot or delta files from the same host. Furthermore = the >> Relying Party MAY provide a way for operators to accept untrusted >> connections for a given host, after the cause has been identified. >>=20 >> It is RECOMMENDED that Relying Parties and Repository Servers = follow >> the Best Current Practices outlined in [RFC7525] on the use of = HTTP >> over TLS (HTTPS) [RFC7230]. Relying Parties SHOULD do TLS >> certificate and host name validation using subjectAltName dNSName >> identities as described in [RFC6125]. The rules and guidelines >> defined in [RFC6125] apply here, with the following = considerations: >>=20 >> o Relying Parties and Repository Servers SHOULD support the = DNS-ID >> identifier type. The DNS-ID identifier type SHOULD be present = in >> Repository Server certificates. >>=20 >> o DNS names in Repository Server certificates SHOULD NOT contain = the >> wildcard character "*". >>=20 >> o A CN field may be present in Repository Server certificates's >> subject name, but SHOULD NOT be used for authentication within = the >> rules described in [RFC6125]. >>=20 >> o This protocol does not require the use of SRV-IDs. >>=20 >> o This protocol does not require the use of URI-IDs. >>=20 >> Note however that this validation is done on a best effort basis, = and >> serves to highlight potential issues, but RPKI object security = does >> not depend on this. Therefore Relying Parties MAY deviate from = the >> validation steps listed above, in particular in case standard = widely >> used software libraries in the language of the Relying Party = software >> implementation do not support and/or cannot be configured to = function >> this way. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Thanks >> Tim >>=20 >>=20 >>=20 >>>=20 >>>> Note that a Man-in-the-Middle (MITM) cannot produce validly = signed >>>> RPKI data, but can perform withhold or replay attacks targeting = an >>>> Relying Party, and keep the Relying Party from learning about = changes >>>> in the RPKI. Because of this Relying Parties SHOULD do TLS >>>> certificate and host name validation when they fetch from an RRDP >>>> Repository Server, using subjectAltName dNSName identities as >>>> described in [RFC6125]. The rules and guidelines defined in >>>> [RFC6125] apply here, with the following considerations: >>>>=20 >>>> o Relying Parties and Repository Servers SHOULD support the = DNS-ID >>>> identifier type. The DNS-ID identifier type SHOULD be present = in >>>> Repository Server certificates. >>>>=20 >>>> o DNS names in Repository Server certificates SHOULD NOT contain = the >>>> wildcard character "*". >>>>=20 >>>> o A CN field may be present in Repository Server certificates's >>>> subject name, but SHOULD NOT be used for authentication within = the >>>> rules described in [RFC6125]. >>>>=20 >>>> o This protocol does not require the use of SRV-IDs. >>>>=20 >>>> o This protocol does not require the use of URI-IDs. >>>>=20 >>>>>=20 >>>>>=20 >>>>> = ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>> In 3.2: HTTPS reference is out-of-date. >>>>=20 >>>> updated to RFC7230 >>>>=20 >>>>> SHA-256 needs a reference. >>>>=20 >>>> ok, added a normative reference (same as in the publication = protocol >>>> document): >>>>=20 >>>> [SHS] National Institute of Standards and Technology, = "Secure >>>> Hash Standard", March 2012, >>>> >>>> fips-180-4.pdf>. >>=20 --Apple-Mail=_F7F523B6-40E8-4787-92E6-D7502B74340A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Alexey,

Thanks, I am about to send an update to my co-authors so that = they can also review, and upload it this Friday.

Tim

On = 08 Mar 2017, at 11:01, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

Hi Tim,
(Top post)

I think your latest suggested text is good enough, so = polishing it more is not going to improve the document in a significant = way. So please post a new version with it.

Thank you,
Alexey

On 8 Mar 2017, at = 09:29, Tim Bruijnzeels <tim@ripe.net> wrote:

Hi Alexey

On 07 Mar 2017, at 16:15, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

Hi Tim,

On Tue, Mar 7, 2017, at 01:38 PM, Tim = Bruijnzeels wrote:
Hi all,

On 02 Mar 2017, at 12:04, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

Alexey Melnikov has entered the following ballot position = for
draft-ietf-sidr-delta-protocol-07: Discuss

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)


Please = refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor 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-delta-protocol= /



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

I would be happy to ballot Yes on = this document, as it is well written
and is a useful piece = of work. However I have one issue (and a few minor
comments)= that I would like to DISCUSS before doing so:

In Section 5.3 the document says:

 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) [RFC2818].

RFC 7525 is referencing RFC 6125 for server hostname = validation.
Unfortunately this is not detailed enough to = perform hostname validation,
because reference to RFC 6125 = requires specifying answers to every
question in section 3 = of RFC 6125. (And there is no generic RFC that
specifies = how this is done for protocols using HTTP.) One example of how
this might look like is in Section 9.2 of
<https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-rfc68= 10-bis/?include_text=3D1>.
For your convenience the = relevant text is pasted below:

 Routers = MUST also verify the cache's TLS server certificate, using
 subjectAltName dNSName identities as described in = [RFC6125], to
avoid
 man-in-the-middle = attacks.  The rules and guidelines defined in
 [RFC6125] apply here, with the following = considerations:

    Support for DNS-ID identifier type = (that is, the dNSName identity
    in = the subjectAltName extension) is REQUIRED in rpki-rtr server
    and client implementations which use = TLS.  Certification
    authorities= which issue rpki-rtr server certificates MUST support
    the DNS-ID identifier type, and the = DNS-ID identifier type MUST
be
    present in rpki-rtr server = certificates.

    DNS = names in rpki-rtr server certificates SHOULD NOT contain the
    wildcard character "*".

    rpki-rtr = implementations which use TLS MUST NOT use CN-ID
    identifiers; a CN field may be = present in the server
certificate's
    subject name, but MUST NOT be used = for authentication within the
    rules = described in [RFC6125].

The only thing = missing from the above is explicit mentioning that SRV-ID
and URI-ID are not used. (I think the same should apply to = your
document.)

Considering that we also say:

  Relying Party tools SHOULD log any TLS = certificate or host name
  validation issues = thus found, so that an operator can investigate the
  cause.  However, such validation issues are = often due to
  configuration errors, or a lack = of a common TLS trust anchor.  In
  these = cases it is better if the Relying Party retrieves the signed
  RPKI data regardless, and performs validation on = it.  Therefore
  Relying Party MUST = continue to retrieve the data in case of errors.
  The Relying Party MAY choose to log encountered = issues only when
  fetching the notification = update file, but not when it subsequently
  fetches snapshot or delta files from the same = host.  Furthermore the
  Relying Party MAY = provide a way for operators to accept untrusted
  connections for a given host, after the cause has = been identified.


And because = in practice Relying Party software will use standard software
libraries to do retrieval and verification, and it may be = hard or even
impossible to configure these libraries to do = the verification as
described.. would you agree with the = following? Essentially taking your
suggested lead, but = never exceeding "SHOULD" in the "how" of the TLS
certificate= and host name validation that itself is a SHOULD, i.e.:

I think it would be clearer to say that *if* = validation is done, it will
use the following MUST/MUST NOTs. (And if = validation fails, you log as
you recommend elsewhere.) Otherwise it = would not be very clear when it
is Ok to violate various SHOULD/SHOULD = NOTs.

I see your point regarding clarity, but my main point is that = I believe it would be overkill to have MUSTs. It may not be possible to = enforce this behaviour in standard libraries of the language of choice = for Relying Party implementations (currently Java (RIPE NCC), Python = (rcynic) and C I believe for RIPSTR). And since we have RPKI object = security I don't believe it would be a big issue if for example a = wildcard certificate is used.

I really do not want to have to = implement our own https client library for this. It would require a lot = of work and maintenance, and on the whole it would make our = implementation brittle. I want to be able to use one of the widely used = and tested standard libraries for this, even if they violate a SHOULD. = Of course I am willing to see whether we can tweak behaviour of said = libraries, but again this may not possible.

If you agree, would it help if we moved = the text around a bit (so that the security motivation comes first) and = add this explanation explicitly at the end:

4.3.  HTTPS considerations

   Note that a Man-in-the-Middle = (MITM) cannot produce validly signed
   RPKI = data, but can perform withhold or replay attacks targeting an
   Relying Party, and keep the Relying Party from = learning about changes
   in the RPKI. =  Because of this Relying Parties SHOULD do TLS
  =  certificate and host name validation when they fetch from an = RRDP
   Repository Server.

   Relying Party tools SHOULD log any TLS = certificate or host name
   validation issues = found, so that an operator can investigate the
  =  cause.  However, such validation issues are often due to
   configuration errors, or a lack of a common TLS = trust anchor.  In
   these cases it is = better if the Relying Party retrieves the signed
  =  RPKI data regardless, and performs validation on it. =  Therefore
   Relying Party MUST continue = to retrieve the data in case of errors.
   The = Relying Party MAY choose to log encountered issues only when
   fetching the notification update file, but not = when it subsequently
   fetches snapshot or = delta files from the same host.  Furthermore the
 =  Relying Party MAY provide a way for operators to accept = untrusted
   connections for a given host, after = the cause has been identified.

  =  It is RECOMMENDED that Relying Parties and Repository Servers = follow
   the Best Current Practices outlined in = [RFC7525] on the use of HTTP
   over TLS (HTTPS) = [RFC7230].  Relying Parties SHOULD do TLS
  =  certificate and host name validation using subjectAltName = dNSName
   identities as described in [RFC6125]. =  The rules and guidelines
   defined in = [RFC6125] apply here, with the following considerations:
   o  Relying Parties and Repository Servers = SHOULD support the DNS-ID
      identifier = type.  The DNS-ID identifier type SHOULD be present in
      Repository Server certificates.

   o  DNS names in Repository = Server certificates SHOULD NOT contain the
    =   wildcard character "*".

  =  o  A CN field may be present in Repository Server = certificates's
      subject name, but = SHOULD NOT be used for authentication within the
  =     rules described in [RFC6125].

   o  This protocol does not require the use = of SRV-IDs.

   o  This = protocol does not require the use of URI-IDs.

   Note however that this validation is done on a = best effort basis, and
   serves to highlight = potential issues, but RPKI object security does
  =  not depend on this.  Therefore Relying Parties MAY deviate = from the
   validation steps listed above, in = particular in case standard widely
   used = software libraries in the language of the Relying Party software
   implementation do not support and/or cannot be = configured to function
   this way.








Thanks
Tim




  Note that a = Man-in-the-Middle (MITM) cannot produce validly signed
  RPKI data, but can perform withhold or replay = attacks targeting an
  Relying Party, and keep = the Relying Party from learning about changes
  in= the RPKI.  Because of this Relying Parties SHOULD do TLS
  certificate and host name validation when they = fetch from an RRDP
  Repository Server, using = subjectAltName dNSName identities as
  described = in [RFC6125].  The rules and guidelines defined in
  [RFC6125] apply here, with the following = considerations:

  o  Relying = Parties and Repository Servers SHOULD support the DNS-ID
     identifier type. The DNS-ID = identifier type SHOULD be present in
     Repository Server = certificates.

  o  DNS names = in Repository Server certificates SHOULD NOT contain the
     wildcard character "*".

  o  A CN field may be present = in Repository Server certificates's
     subject name, but SHOULD NOT be = used for authentication within the
     rules described in = [RFC6125].

  o  This = protocol does not require the use of SRV-IDs.

  o  This protocol does not require the use of = URI-IDs.



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

In 3.2: HTTPS reference is = out-of-date.

updated to = RFC7230

SHA-256 needs a reference.

ok, added a normative reference (same as in the publication = protocol
document):

  [SHS]      National = Institute of Standards and Technology, "Secure
          &nb= sp;  Hash Standard", March 2012,
          &nb= sp;  <http://csrc.nist.gov/publications/fips/fips180-4/
          &nb= sp;  fips-180-4.pdf>.

= --Apple-Mail=_F7F523B6-40E8-4787-92E6-D7502B74340A-- From nobody Wed Mar 8 07:40:53 2017 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 7B73D129439 for ; Wed, 8 Mar 2017 07:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wbf9JNQ2wGyR for ; Wed, 8 Mar 2017 07:40:51 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B432129430 for ; Wed, 8 Mar 2017 07:40:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=760; q=dns/txt; s=iport; t=1488987651; x=1490197251; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=MysAhH+oooYzPWAq1SUmaTdzx20s5hIABjosL0v7e5o=; b=F1Nh92rfguklXV42UzKuQhfn2GvNuSnyxaZKajiSJLSZG60HiZIq5q8W S14JkIncx5VaVhgqFiGdktrVEagPtQaDQ3VR7q7C452BvRBhXdnhldjuG KQBtBWkMVUgwksbldoNMMq/yByf2Dh0p8vEGRYLVFQzFg4U51k3fFXdpO E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B1AQC6JcBY/4QNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1GBaweDWYoMpwSCDYYiAhqCJT8YAQIBAQEBAQEBayiFFgYjEVU?= =?us-ascii?q?CAQgaAiYCAgIwFRACBAESiX+wOoImin8BAQEBAQEBAQEBAQEBAQEBAQEBAQEdg?= =?us-ascii?q?QuFQ4IFgmqEVIMGLoIxAQSVeoY8AZI3gWOPPZM9AR84gQNWFVABhEIdgWN1iQa?= =?us-ascii?q?BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,264,1486425600"; d="scan'208";a="217760009" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Mar 2017 15:40:35 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v28FeZMH031248 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Mar 2017 15:40:35 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 8 Mar 2017 09:40:34 -0600 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, 8 Mar 2017 09:40:34 -0600 From: "Alvaro Retana (aretana)" To: Sean Turner , sidr list Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-17.txt Thread-Index: AQHSlpeidu8gS7zgtkmW+JUrssxodqGIbCGAgAK8GQA= Date: Wed, 8 Mar 2017 15:40:34 +0000 Message-ID: References: <148881809662.14983.2177764565050758825.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.6] Content-Type: text/plain; charset="utf-8" Content-ID: <21F3796EA617654093BCED3827029010@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-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, 08 Mar 2017 15:40:52 -0000 SGkhDQoNCkkganVzdCBhcHByb3ZlZCENCg0KVGhhbmtzIQ0KDQpBbHZhcm8uDQoNCg0KDQpPbiAz LzYvMTcsIDExOjU0IEFNLCAic2lkciBvbiBiZWhhbGYgb2YgU2VhbiBUdXJuZXIiIDxzaWRyLWJv dW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHNlYW5Ac24zcmQuY29tPiB3cm90ZToNCg0KVGhp cyB2ZXJzaW9uIGFkZHJlc3NlcyB0aGUgSUVTRyBjb21tZW50cyB3ZSBnb3QgZnJvbSBBbGV4ZXkg KGRyaXZlIGhvbWUgdGhlIHBvaW50IHRoYXQgdGhlc2UgYWxncyBhcmUgZGlmZmVyZW50IHRoYW4g dGhlIHJlc3Qgb2YgdGhlIFJQS0kpIGFuZCBTdGVwaGVuIChhZGQgZXhhbXBsZXMpLiAgQXMgeW91 IG1heSBoYXZlIHNlZW4sIE9saXZlciBkaWQgYSBsb3Qgb2Ygd29yayBvbiB0aGUgZXhhbXBsZXMg c28gaGXigJlzIG5vdyBsaXN0ZWQgYXMgYW4gYXV0aG9yLg0KDQpJ4oCZbSBob3BpbmcgdGhpcyBp cyB0aGUgbGFzdCBzdGVwIHByaW9yIHRvIGFwcHJvdmFsLCBidXQgSeKAmWxsIGxlYXZlIHRoYXQg aW4gQWx2YXJvL0NocmlzL1NhbmR54oCZcyBoYW5kcy4NCg0KDQoNCg== From nobody Wed Mar 8 08:36:04 2017 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 8CE8312966B; Wed, 8 Mar 2017 08:36:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <148899096257.20171.17304472960050869597.idtracker@ietfa.amsl.com> Date: Wed, 08 Mar 2017 08:36:02 -0800 Archived-At: Cc: draft-ietf-sidr-bgpsec-algs@ietf.org, sidr@ietf.org, sidr-chairs@ietf.org, The IESG , sandy@tislabs.com, rfc-editor@rfc-editor.org Subject: [sidr] Protocol Action: 'BGPsec Algorithms, Key Formats, & Signature Formats' to Proposed Standard (draft-ietf-sidr-bgpsec-algs-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, 08 Mar 2017 16:36:02 -0000 The IESG has approved the following document: - 'BGPsec Algorithms, Key Formats, & Signature Formats' (draft-ietf-sidr-bgpsec-algs-17.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-bgpsec-algs/ Technical Summary This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key size and signature format used in BGPsec (Border Gateway Protocol Security). This document updates the Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RFC 7935). Working Group Summary This document has had consistent interest from the working group. The document passed wglc and then waited for publication until the BGPsec protocol was mature. Document Quality There is one known implementation of the generation of certificates that use the algorithm and key format defined in this draft. There are two known implementations of BGPsec that use the algorithms defined in this draft. All are open source implementations. Personnel Document Shepherd: Sandra Murphy Responsible Area Director: Alvaro Retana RFC Editor Note This document is part of a group being considered by the IESG that normatively depend on draft-ietf-sidr-bgpsec-protocol; all documents are titled draft-ietf-sidr-bgpsec-*. Please make sure that draft-ietf-sidr-bgpsec-protocol has the lowest RFC number -- no consecutive numbers are needed in this case. From nobody Wed Mar 8 11:26:34 2017 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 13A671294BC; Wed, 8 Mar 2017 11:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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=netorgft1331857.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 5yeXWCO3j-Uz; Wed, 8 Mar 2017 11:26:31 -0800 (PST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) (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 B6CB71293FF; Wed, 8 Mar 2017 11:26:31 -0800 (PST) Received: from pure.maildistiller.com (unknown [10.110.50.29]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id C02A160056; Wed, 8 Mar 2017 19:26:30 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx2-us3.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 2CA028004F; Wed, 8 Mar 2017 19:26:31 +0000 (UTC) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0024.outbound.protection.outlook.com [207.46.163.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx2-us3.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 5CA8E6005D; Wed, 8 Mar 2017 19:26:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7AaTFcXNrmao/75ZYC7UctifdhacNQs5wHaOLniT+3g=; b=brPjcmeb2t6G3AKNHiXHvbXY17H9nAKvdTp7eu5JGy4fe7McZov3dMUjSWvctYr7gHa+MlkqLg7YLQLCTK2C2RCnqt4KgfmEnuoFfjre0pMmu80WQLwAr8GfPaSyhK+wDSNSo8M7uZA1tjBXbR4LW7CfUlgdVYOBh6WfkBXaWg0= Received: from SN1PR18MB0270.namprd18.prod.outlook.com (10.163.58.157) by SN1PR18MB0269.namprd18.prod.outlook.com (10.163.58.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Wed, 8 Mar 2017 19:26:28 +0000 Received: from SN1PR18MB0270.namprd18.prod.outlook.com ([10.163.58.157]) by SN1PR18MB0270.namprd18.prod.outlook.com ([10.163.58.157]) with mapi id 15.01.0947.020; Wed, 8 Mar 2017 19:26:28 +0000 From: Keyur Patel To: "sidrops@ietf.org" Thread-Topic: Call for SIDROPS WG Agenda Items Thread-Index: AQHSmEHhKm9TLxV8kUOYDXI6aM7uZA== Date: Wed, 8 Mar 2017 19:26:27 +0000 Message-ID: <7FA93B0D-8418-4A83-9F40-7AADC112BB52@arrcus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arrcus.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [96.68.143.133] x-ms-office365-filtering-correlation-id: 74745bd0-b675-4b4a-974d-08d466590489 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN1PR18MB0269; x-microsoft-exchange-diagnostics: 1; SN1PR18MB0269; 7:hx4vwXuaKjVsSxJO7jnNdwaWs7wyrBIkngFLRb2RSUTXUEXvQ/GitZoBGoOMZVj1C9mOfUXQSwfZAOA0jBJ4nmssEdLaOgRROTO4M90Qiocj4+RBmfydUFIQQ3ZcW0XwtRH5FsfmexVP3ohbZclYMMNkfDMwlFrhNIUmCBulI6szd7NCTBseotR/VQXecFg/9A47bdWXqoI2uP2xE6cKHRDZdQ4RdnguG9a2B7c//jDtwbMB81OaV6wVWfAU81kkmYvUGrPEc3s2pwEaAuoh6A13wLzpOMsJyfQHdRoSmnRIWnhkgMWQVjlPcC6IgbgNXWSv9UmZwEHNImBz5rI3hQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(2016111802025)(20161123558025)(20161123555025)(20161123562025)(6043046)(6072148); SRVR:SN1PR18MB0269; BCL:0; PCL:0; RULEID:; SRVR:SN1PR18MB0269; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39410400002)(39830400002)(377454003)(6306002)(83716003)(6436002)(6512007)(6916009)(6506006)(54896002)(1730700003)(122556002)(8676002)(77096006)(81166006)(25786008)(6486002)(82746002)(2501003)(189998001)(36756003)(99286003)(8936002)(33656002)(5640700003)(4326008)(66066001)(106116001)(86362001)(3846002)(6116002)(54356999)(53936002)(50986999)(5660300001)(102836003)(450100002)(2906002)(38730400002)(3280700002)(3660700001)(2900100001)(110136004)(7736002)(2351001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR18MB0269; H:SN1PR18MB0270.namprd18.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_7FA93B0D84184A839F407AADC112BB52arrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2017 19:26:27.9393 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR18MB0269 X-MDID: 1489001191-05iVP-NCRZKC Archived-At: Cc: "sidr@ietf.org" Subject: [sidr] Call for SIDROPS WG Agenda Items 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, 08 Mar 2017 19:26:33 -0000 --_000_7FA93B0D84184A839F407AADC112BB52arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgZm9sa3MsDQoNClNJRFJPUFMgd2lsbCBtZWV0IGF0IElFVEYtOTggb24gVHVlc2RheSwgTWFy Y2ggMjh0aCBmcm9tIDI6NTAgcG0gLSA0OjIwIHBtLiBQbGVhc2UgZm9yd2FyZCBhbnkgU0lEUk9Q UyBhZ2VuZGEgaXRlbXMgeW91IG1heSBoYXZlIHRvIENocmlzIGFuZCBtZS4gUGxlYXNlIGFsc28g bWFrZSBzdXJlIHRoYXQgeW91ciBzbGlkZXMgYXJlIGF2YWlsYWJsZSB0byB0aGUgY2hhaXJzIGJ5 IE1vbmRheSBtb3JuaW5nICgzLzI3LzIwMTcpLiBTbGlkZXMgcmVjZWl2ZWQgYWZ0ZXIgd2lsbCBi ZSBsZXNzIGxpa2VseSB0byBiZSBhdmFpbGFibGUgZm9yIHVzZSBkdXJpbmcgdGhlIG1lZXRpbmcu DQoNCldlIGhhdmUgY2NlZCBTSURSIG1haWxpbmcgbGlzdCBhcyB3ZWxsIGNvbnNpZGVyaW5nIHdl IGFyZSBnb2luZyB0byBoYXZlIG91ciBmaXJzdCBTSURST1BTIG1lZXRpbmcuDQoNClJlZ2FyZHMs DQpDaHJpcyBhbmQgS2V5dXINCg0KDQoNCg0K --_000_7FA93B0D84184A839F407AADC112BB52arrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: <88940B6D50B1EB4A82D1993920FC6E7F@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i IzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IaSBmb2xr cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNJRFJPUFMgd2ls bCBtZWV0IGF0IElFVEYtOTggb24gVHVlc2RheSwgTWFyY2ggMjh0aCBmcm9tIDI6NTAgcG0gLSA0 OjIwIHBtLiBQbGVhc2UgZm9yd2FyZCBhbnkgU0lEUk9QUyBhZ2VuZGEgaXRlbXMgeW91IG1heSBo YXZlIHRvIENocmlzIGFuZCBtZS4gUGxlYXNlIGFsc28gbWFrZSBzdXJlIHRoYXQgeW91ciBzbGlk ZXMgYXJlIGF2YWlsYWJsZSB0byB0aGUNCiBjaGFpcnMgYnkgTW9uZGF5IG1vcm5pbmcgKDMvMjcv MjAxNykuIFNsaWRlcyByZWNlaXZlZCBhZnRlciB3aWxsIGJlIGxlc3MgbGlrZWx5IHRvIGJlIGF2 YWlsYWJsZSBmb3IgdXNlIGR1cmluZyB0aGUgbWVldGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPldlIGhhdmUgY2NlZCBTSURSIG1haWxpbmcgbGlzdCBhcyB3 ZWxsIGNvbnNpZGVyaW5nIHdlIGFyZSBnb2luZyB0byBoYXZlIG91ciBmaXJzdCBTSURST1BTIG1l ZXRpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5SZWdhcmRz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5DaHJpcyBhbmQgS2V5dXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_7FA93B0D84184A839F407AADC112BB52arrcuscom_-- From nobody Thu Mar 9 10:45:07 2017 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 BCC0C1294D0; Thu, 9 Mar 2017 10:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70ZLfNd1oaA9; Thu, 9 Mar 2017 10:45:00 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6962F1270B4; Thu, 9 Mar 2017 10:45:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34598; q=dns/txt; s=iport; t=1489085100; x=1490294700; h=from:to:cc:subject:date:message-id:mime-version; bh=f4TgAUddJpqsMiJKzt9WPEQGqz4RdHDlDatS9zfgIc0=; b=kXWAyvQrfcVl6IFVm+3UPF2l74gakPxc0mkQS7UeMxwZYmZCOBrTgog4 bjm6GwoIz09kJWDOi49SJDoxDzEsX4Rif63Usgc5TB9CpYZVCVszfn/AW /Je4U8K4jdndEPvKyaLXPoCoTIPqR2sLquA91zuBdqkpg0FVuQTI/yX8f c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqAQDlocFY/5JdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5jYYERg1mKDKcHgg6GIhyCFz8YAQIBAQEBAQEBax0LhT8KTBI?= =?us-ascii?q?BBjoKAgQwJwQOGYlsk0SdW4ImK4o7AQEBAQEBAQEBAQEBAQEBAQEBAQEBHYZOg?= =?us-ascii?q?gWHVYJvLoIxBYkTGId4hFeGPwGSN4F7hSOKAohEinoBHziBA1YVPxEBhEIdgWO?= =?us-ascii?q?IZSuBA4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.36,137,1486425600"; d="scan'208,217";a="395900777" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Mar 2017 18:44:59 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v29IixFg015603 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Mar 2017 18:44:59 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 9 Mar 2017 12:44:58 -0600 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; Thu, 9 Mar 2017 12:44:58 -0600 From: "Alvaro Retana (aretana)" To: "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" Thread-Topic: AD Review of draft-ietf-sidr-rpki-validation-reconsidered-07 Thread-Index: AQHSmQVAKIoRRn/RNUKU0uFv8zRBdw== Date: Thu, 9 Mar 2017 18:44:58 +0000 Message-ID: <5821A5CF-EFF8-4CE3-9AA4-CFDB9C903D63@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.6] Content-Type: multipart/alternative; boundary="_000_5821A5CFEFF84CE39AA4CFDB9C903D63ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Chris Morrow , "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-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: Thu, 09 Mar 2017 18:45:03 -0000 --_000_5821A5CFEFF84CE39AA4CFDB9C903D63ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhdXRob3JzOg0KDQpJIGp1c3QgZmluaXNoZWQgcmVhZGluZyB0aGlzIGRvY3VtZW50LiAg TXkgcmV2aWV3IGlzIHByZWRpY2F0ZWQgb24gdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUgaW50ZW50 IG9mIHRoZSBXRyBpcyB0byBkZWZpbmUgYW4gYWRkaXRpb25hbCB2YWxpZGF0aW9uIHByb2Nlc3Ms IGFuZCBub3QgYW1lbmQvY2hhbmdlL3VwZGF0ZS9kZXByZWNhdGUgdGhlIGV4aXN0aW5nIG9uZeKA pnlldCwgd2hpY2ggaXMgd2h5IHRoZXJlIGFyZSBub3Qgb25seSBwcm9jZXNzIGNoYW5nZXMgc3Bl Y2lmaWVkLCBidXQgYWxzbyBuZXcgT0lEcy4NCg0KQXMgd3JpdHRlbiwgd2l0aCBVcGRhdGVzIGFu ZCB0ZXh0IOKAnHRvIGJlIHVzZWQgaW4gcGxhY2Ugb2bigJ0gZXhpc3Rpbmcgc3BlY2lmaWNhdGlv bnMsIHRoZSBkb2N1bWVudCBhY2hpZXZlcyB0aGUgZGVwcmVjYXRpb24gb2YgdGhlIGN1cnJlbnQg KG9sZCkgbWVjaGFuaXNtOiBzaW1wbHkgYmVjYXVzZSBwcm9jZWR1cmFsbHkgeW91IGFyZSByZXBs YWNpbmcgdGhlIGV4aXN0aW5nL29sZCB0ZXh0IHdpdGggdGhlIG5ldyBvbmXigKZhbmQgdGhlIG9s ZCBvbmUgd291bGQgdGhlbiBub3QgYmUgYW55bW9yZS4gIFRoZSByZXN1bHQgdGhlbiBpcyBub3Qg Y29oZXJlbnQgd2l0aCB0aGUgYXNzdW1wdGlvbiBhYm92ZSwgYW5kIHdlIHdpbGwgbmVlZCB0byBy ZXdyaXRlIChhdCBsZWFzdCBmcm9tIGFuIGludGVudCBwb2ludCBvZiB2aWV3KSB0aGUgZG9jdW1l bnQgYmVmb3JlIHByb2dyZXNzaW5nLg0KDQpJIHRoaW5rIHRoYXQgdGhlIGVhc2llc3Qgd2F5IGZv cndhcmQgd291bGQgYmUgZm9yIHRoaXMgZG9jdW1lbnQgdG8gc2F5IHNvbWV0aGluZyBsaWtlOiDi gJxhIG5ldyB2YWxpZGF0aW9uIG1lY2hhbmlzbSBpcyBzcGVjaWZpZWQsIHdoaWNoIHVzZXMgdGhl c2UgbmV3IE9JRHMg4oCTIHRoZSBzcGVjaWZpY2F0aW9ucyBkZWZpbmVkIGluIFJGQ0EsIFJGQ0Is IGV0Yy4uIGFwcGx5LCBleGNlcHQgZm9yIHRoZSBmb2xsb3dpbmcgZXhjZXB0aW9ucy9jaGFuZ2Vz LuKAnSAgWW91IHNob3VsZCB0aGVuIGJlIGFibGUgdG8gdXNlIG1vc3Qgb2YgdGhlIHN1YnN0YW50 aXZlIHRleHQgYWxyZWFkeSB3cml0dGVuLg0KDQpQbGVhc2Ugc2VlIGJlbG93IGZvciBzcGVjaWZp YyBjb21tZW50cyDigJMgaW5jbHVkaW5nIG1vcmUgb24gd2h5IHRoaXMgZG9jdW1lbnQgc2hvdWxk IG5vdCBVcGRhdGUgdGhlIGV4aXN0aW5nIFJGQ3MuDQoNClRoYW5rcyENCg0KQWx2YXJvLg0KDQoN Cg0KTWFqb3I6DQoNCk0xLiBTZWN0aW9uIDQuMi4xLiAoQ2hhbmdlcyB0byBSRkM2NDg0KS4gIFRo aXMgZG9jdW1lbnQgcmVxdWVzdHMgYW4gYXNzaWdubWVudCBvZiBhIG5ldyBPSUQgKGlkLWNwLWlw QWRkci1hc051bWJlci12Mik7IGJvdGggdGhlIHJlZmVyZW5jZSBhbmQgdGhlIHBvbGljeSB0byBi ZSBmb2xsb3dlZCBhcmUgY29udGFpbmVkIGhlcmUsIGFuZCBub3QgaW4gUkZDNjQ4NC4gIElPVywg dGhpcyBkb2N1bWVudCBzaG91bGRu4oCZdCBVcGRhdGUgUkZDNjQ4NC4gIEluc3RlYWQsIGl0IHNo b3VsZCByZXF1ZXN0IHRoZSBuZXcgT0lEIGFuZCBzaW1wbHkgcmVmZXJlbmNlIFJGQzY0ODQgd2hl biBwb2ludGluZyBiYWNrIHRvIGlkLWNwLWlwQWRkci1hc051bWJlci4NCg0KDQpNMi4gU2VjdGlv biA0LjIuMi4gKENoYW5nZXMgdG8gUkZDMzc3OSkuICBTYW1lIGNvbW1lbnQ6IHRoaXMgZG9jdW1l bnQgcmVxdWVzdHMgdGhlIGFzc2lnbm1lbnQgb2YgbmV3IE9JRHPigKYuICBOb3RlIHRoYXQgaWYg dGhlIGNoYW5nZXMgaW4gU2VjdGlvbiA0LjIuMi4xLiAoT0lEIGZvciBpZC1wZS1pcEFkZHJCbG9j a3MtdjIpIGFuZCBTZWN0aW9uIDQuMi4yLjMuIChPSUQgZm9yIGlkLXBlLWF1dG9ub21vdXNTeXNJ ZHMtdjIpIHdlcmUgdG8gYmUgdXNlZCBpbiBwbGFjZSBvZiB0aGUgdGV4dCBpbiBSRkMzNzc5LCB0 aGVuIGlkLXBlLWlwQWRkckJsb2NrcyBhbmQgaWQtcGUtYXV0b25vbW91c1N5c0lkcyB3b3VsZCBl bmQgdXAgYmVpbmcgZGVwcmVjYXRlZC4NCg0KTTIuMS4gW21pbm9yXSBUaGUgc3ludGF4IGZvciBp ZC1wZS1pcEFkZHJCbG9ja3MtdjIgYW5kIGlkLXBlLWF1dG9ub21vdXNTeXNJZHMtdjIgKDQuMi4y LjIgYW5kIDQuMi4yLjQpIHVzZSB0aGUg4oCcdjHigJ0gbmFtZXMuDQoNCk0yLjIuIEZvciBTZWN0 aW9ucyA0LjIuMi41IGFuZCA0LjIuMi42LCBJIHRoaW5rIHRoYXQgd2hhdCB5b3Ugd2FudCB0byBz YXkgaXMgKHNvbWV0aGluZyBsaWtlKTog4oCcd2hlbiB0aGUgT0lEcyBkZWZpbmVkIGluIHRoaXMg ZG9jdW1lbnQgYXJlIHVzZWQsIHRoZSBwcm9jZWR1cmVzIGluIFJGQzM3NzkgYXJlIGZvbGxvd2Vk LCBleGNlcHQgZm9yIHRoZSBjZXJ0aWZpY2F0ZSBwYXRoIHZhbGlkYXRpb24gKHNlY3Rpb24gMi4z KSwgd2hpY2ggaXMgc3BlY2lmaWVkIGluIFNlY3Rpb24gNC4yLjQuNCBvZiB0aGlzIGRvY3VtZW50 LCBhbmTigKbigJ0gIEFnYWluLCBpZiB0aGUgdGV4dCB3YXMgdG8gcmVwbGFjZSB3aGF0IGlzIGN1 cnJlbnRseSBpbiBSRkMzNzc5LCB0aGVuIHRob3NlIHByb2NlZHVyZXMgd291bGQgYmUgZGVwcmVj YXRlZC4NCg0KTTIuMy4gU2FtZSBjb21tZW50IGZvciBTZWN0aW9uIDQuMi4yLjc6IGFtZW5kaW5n IHRoZSBzcGVjaWZpY2F0aW9uIGluIFJGQzM3NzkgcmVzdWx0cyBpbiBsb29zaW5nIHdoYXQgaXMg ZGVmaW5lZCB0aGVyZS4NCg0KDQpNMy4gU2VjdGlvbiA0LjIuNC4gKENoYW5nZXMgdG8gUkZDNjQ4 NykuICBTYW1lIGNvbW1lbnRzIGFzIGFib3ZlOiByZXBsYWNpbmcgdGhlIHRleHQgKHdoaWNoIGlz IHdoYXQgYW4gVXBkYXRlIGRvZXMpLCB3b3VsZCByZXN1bHQgaW4gdGhlIG1lY2hhbmlzbSBzcGVj aWZpZWQgaW4gUkZDNjQ4NyB0byBiZSB0aGUgc2FtZSBhcyB3aGF0IGlzIHNwZWNpZmllZCBpbiB0 aGlzIGRvY3VtZW504oCmd2hpY2ggbWVhbnMgdGhhdCB0aGUgb3B0aW9uIGluIHRoZSBmaXJzdCBw YXJhZ3JhcGggKOKAnOKApk1VU1QgaXNzdWUgY2VydGlmaWNhdGVzIGVpdGhlciBhcyBzcGVjaWZp ZWQgaW4gW1JGQzY0ODddIG9yIHdpdGggYWxsIHRoZSBhbWVuZG1lbnRzIHNwZWNpZmllZCBpbiB0 aGUgZm9sbG93aW5nIHNlY3Rpb25zLikgd291bGQgcmVzdWx0IGluIHRoZSBzYW1lIHRoaW5nLiAg QXMgd2l0aCBTZWN0aW9uIDQuMi4yIChhYm92ZSksIEkgdGhpbmsgeW91IHJlYWxseSBzaG91bGQg c3BlY2lmeSB3aGF0IHRoZSBleGNlcHRpb25zIGFyZSBmb3IgdGhlIGV4dGVuc2lvbnMgZGVmaW5l ZCBpbiB0aGlzIGRvY3VtZW50IChhbmQgbm90IFVwZGF0ZSBSRkM2NDg3KS4NCg0KDQpNNC4gU2Vj dGlvbiA0LjIuNC40LiAoQW1lbmRlZCBSZXNvdXJjZSBDZXJ0aWZpY2F0ZSBQYXRoIFZhbGlkYXRp b24pLg0KDQpNNC4xLiBbQ29tbWVudCBhYm91dCBSRkM2NDg3XSBUaGlzIGRvY3VtZW50IGNvcnJl Y3RseSBtZW50aW9ucyB0aGUgTm90QmVmb3JlL05vdEFmdGVyIHZhbHVlcyAod2hpY2ggc2hvdWxk IHJlYWxseSBiZSBub3RCZWZvcmUvbm90QWZ0ZXIpLCBpbnN0ZWFkIG9mIEZyb20vVG8gKGluIFJG QzY0ODcpLiAgSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGlzIGlzIGFuIGVycm9yIGluIHRoZSBvcmln aW5hbCB0ZXh0LiAgQ2FuIHlvdSBwbGVhc2UgZmlsZSBhbiBFcnJhdGEgYWdhaW5zdCBSRkM2NDg3 Pw0KDQpNNC4yLiBzL0NlcnRpZmljYXRlIHggY29udGFpbnMgYWxsIHRoZSBleHRlbnNpb25zIHRo YXQgTVVTVCBiZSBwcmVzZW50L0NlcnRpZmljYXRlIHggY29udGFpbnMgYWxsIHRoZSByZXF1aXJl ZCBleHRlbnNpb25zICAgIFRoZSDigJxNVVNU4oCdIGlzIG5vdCBub3JtYXRpdmUgaW4gdGhpcyBj b250ZXh0Lg0KDQpNNC4zLiBbbWlub3JdIHMvTVVTVCBiZSBzYXRpc2Z5IHRoZSBjb25zdHJhaW50 cy9NVVNUIHNhdGlzZnkgdGhlIGNvbnN0cmFpbnRzDQoNCk00LjQuIOKAnElmIElQIEFkZHJlc3Mg RGVsZWdhdGlvbiBleHRlbnNpb24gaXMgcHJlc2VudCwgaXQgaXMgcmVwbGFjZWQgd2l0aCB0aGUg aW50ZXJzZWN0aW9uIG9mIHRoZSB2YWx1ZXMgZnJvbSB0aGF0IGV4dGVuc2lvbiBhbmQgdGhlIGN1 cnJlbnQgdmFsdWUgb2YgdGhlIFZSUy1JUC7igJ0gIFdoYXQgaXMgcmVwbGFjZWQsIHRoZSBJUCBB ZGRyZXNzIERlbGVnYXRpb24gZXh0ZW5zaW9uIG9yIHRoZSBWUlMtSVA/ICBJZiB0aGUgZXh0ZW5z aW9uLCB3aGF0IGRvZXMgaXQgbWVhbiB0byByZXBsYWNlIHRoZSBleHRlbnNpb24gaW4gdGhlIGNl cnRpZmljYXRlPyAgIE5vdGUgdGhhdCB0aGUgdGV4dCBhYm91dCB0aGUgQVMgSWRlbnRpZmllciBE ZWxlZ2F0aW9uIGV4dGVuc2lvbiBpcyBhcyBjb25mdXNpbmcuDQoNCk00LjUuIOKAnOKApnRoZXNl IHZhbHVlcyBNQVkgYmUgc3RvcmVkIGFsb25nIHdpdGggdGhlIGNlcnRpZmljYXRlLCB0byBmYWNp bGl0YXRlIGluY3JlbWVudGFsIHZhbGlkYXRpb27igKbigJ0gIFRoaXMgZG9jdW1lbnQgKGFuZCBS RkM2NDg3KSBkb27igJl0IHNheSBhbnl0aGluZyBhYm91dCB3aGVyZSB0byBzdG9yZSBhbnl0aGlu ZyDigJMgSSBkb27igJl0IHRoaW5rIHdlIG5lZWQgdGhhdCBub3JtYXRpdmUg4oCcTUFZ4oCdLiAg IHMvTUFZL21heQ0KDQpNNC42LiBUaGlzIHRleHQgaXMgbm90IG5lZWRlZDog4oCcSWYgY2VydGlm aWNhdGUgeCB1c2VzIHRoZSBvcmlnaW5hbCB2ZXJzaW9uIG9mIFtSRkM2NDg3XSwgdGhlbiBjZXJ0 aWZpY2F0ZSB4IE1VU1QgYmUgcmVqZWN0ZWQu4oCdDQoNCk01LiBTZWN0aW9uIDQuMi41LiAoQ2hh bmdlcyB0byBSRkM2NDgyKS4gIFNhbWUgY29tbWVudCBhYm91dCBub3QgbmVlZGluZyBhbiBVcGRh dGUvcmVwbGFjaW5nIHRoZSB0ZXh0L+KApg0KDQoNCk02LiBTZWN0aW9uIDUuIChEZXBsb3ltZW50 IENvbnNpZGVyYXRpb25zKS4gIFRoZSB0aW1lbGluZSBpbiBUYWJsZSAxIHNob3VsZG7igJl0IGFw cGVhciBpbiB0aGlzIHNwZWNpZmljYXRpb24uICBNaWdyYXRpb24gaXMgYW4gb3BlcmF0aW9uYWwg aXNzdWUgdGhhdCB0aGUgY29tbXVuaXR5IHNob3VsZCBjb29yZGluYXRlIHNlcGFyYXRlbHkgKGFu ZCBub3QgYnkgc3BlY2lmeWluZyBhIG5vcm1hdGl2ZSB0aW1lbGluZSBpbiBhbiBSRkMpLiAgV2hh dCBzaG91bGQgYmUgaW5jbHVkZWQgaGVyZSBhcmUgYW55IG90aGVyIG1pZ3JhdGlvbiBjb25zaWRl cmF0aW9ucyB0aGF0IHNob3VsZCBiZSBvYnNlcnZlZCB3aGVuIG1ha2luZyB0aGUgdHJhbnNpdGlv biDigJMgaWYgdGhlcmXigJlzIGFueXRoaW5nIGJleW9uZCB3aGF0IHlvdSBhbHJlYWR5IHdyb3Rl Lg0KDQoNCk03LiBTZWN0aW9uIDYuIChTZWN1cml0eSBDb25zaWRlcmF0aW9ucykuIFBsZWFzZSBw b2ludCB0byB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW4gUkZDMzc3OSwgUkZDNjQ4Miwg UkZDNjQ4NCBhbmQgUkZDNjQ4NyBhcyBhcHBseWluZyBoZXJlIHRvby4gIEl0IG1pZ2h0IGJlIGJl bmVmaWNpYWwgdG8gaW5jbHVkZSBhIHNob3J0IGRpc2N1c3Npb24gb2Ygd2h5IG5vdCBpbW1lZGlh dGVseSByZWplY3RpbmcgdGhlIG92ZXItY2xhaW1pbmcgY2VydGlmaWNhdGVzIGlzIG5vdCBhIHNl Y3VyaXR5IGlzc3VlDQoNCg0KTTguIElBTkEgQ29uc2lkZXJhdGlvbnMuICAgVEJENC9UQkQ1IGFy ZSBub3QgZm9yIElQQWRkckFuZEFTQ2VydEV4dG4tKiwgYnV0IGZvciB0aGUgbmV3IGlkLW1vZC1p cC1hZGRyLWFuZC1hcy1pZGVudC0qLg0KDQpNOS4gUmVmZXJlbmNlcw0KLSBQbGVhc2UgYWRkIGEg cmVmZXJlbmNlIHRvIFJGQzIxMTkgYW5kIHRoZSBjb3JyZXNwb25kaW5nIGJvaWxlcnBsYXRlLg0K LSBJIGRvbuKAmXQgdGhpbmsgdGhhdCB0aGUgcmVmZXJlbmNlIHRvIFJGQzYyNjggbmVlZHMgdG8g bWUgTm9ybWF0aXZlLg0KLSBXZSBkb27igJl0IG5lZWQgcmVmZXJlbmNlcyB0byBSRkMzODQ5LCBS RkM1Mzk4IG9yIFJGQzU3MzcuDQotIFJGQzMyODAgd2FzIE9ic29sZXRlZCBieSBSRkM1MjgwDQoN Cg0KDQpNaW5vcjoNCg0KUDEuICBUaGUgZXhhbXBsZSBpbiBTZWN0aW9uIDMgaXMgbWVhbnQgdG8g YmUgYSBjb250aW51YXRpb24gZnJvbSB0aGUgZXhhbXBsZSBpbiBTZWN0aW9uIDIgKOKAnENlcnRp ZmljYXRlIDIgZnJvbSB0aGUgcHJldmlvdXMgZXhhbXBsZSB3YXMgcmUtaXNzdWVkIGJ5IFRBIHRv IENBMSBhbmQgdGhlIHByZWZpeCAxOTguNTEuMTAwLjAvMjQgd2FzIHJlbW92ZWQuICBIb3dldmVy LCBDQTEgZmFpbGVkIHRvIHJlLWlzc3VlIGEgbmV3IENlcnRpZmljYXRlIDMgdG8gQ0EyLuKAnSk7 IGJ1dCBDZXJ0aWZpY2F0ZSAzIGlzIG5vdCB0aGUgc2FtZSBhcyB0aGUgb25lIHNob3duIGluIFNl Y3Rpb24gMi4gIEkgdGhpbmsgdGhlIGV4YW1wbGUgc3RpbGwgZ2V0cyB0aGUgb3Zlci1jbGFpbWlu ZyBwb2ludCBhY3Jvc3MsIGJ1dCBpdCBpcyDigJx3cm9uZ+KAnSBpbiB0aGF0IGJvdGggQ2VydGlm aWNhdGUgMiBhbmQgQ2VydGlmaWNhdGUgMyAobm90IGp1c3QgQ2VydGlmaWNhdGUgMikgd291bGQg aGF2ZSB0byBjaGFuZ2UgZm9yIHRoZSBwcm9ibGVtIHRvIGhhcHBlbi4NCg0KUDIsIEFsc28gaW4g dGhlIGV4YW1wbGUgaW4gU2VjdGlvbiAzLiAgSXQgbWlnaHQgYmUgYmVuZWZpY2lhbCBmb3IgdGhl IHJlYWRlciBpZiB0aGUgRUUgY2VydGlmaWNhdGUgd2FzIGFsc28gbWFya2VkIGFzIGludmFsaWQ7 IHRoZSB0ZXh0IHNheXMgc28sIGJ1dCB0aGUgbGlzdCBvZiBjZXJ0aWZpY2F0ZXMgZG9lc27igJl0 Lg0KDQpQMy4gSW4gc2V2ZXJhbCBwbGFjZXMg4oCcW3RoaXMgZG9jdW1lbnRd4oCdIGlzIHVzZWQg 4oCTIGlmIHRoZSBpbnRlbnQgaXMgdG8gcmVmZXIgdG8gYSBzcGVjaWZpYyBTZWN0aW9uLCBwbGVh c2UgaW5kaWNhdGUgd2hpY2guICBJZiBub3QsIHRoZW4geW91IHNob3VsZCBnZXQgcmlkIG9mIHRo ZSBicmFja2V0cyAoW10pLg0KDQpQNC4gSW4gNC4zOiDigJxST0ExIGlzIGNvbnNpZGVyZWQgdmFs aWQgYmVjYXVzZSB0aGUgcHJlZml4IG1hdGNoZXMgdGhlIFZlcmlmaWVkIFJlc291cmNlIFNldCBv biB0aGUgZW1iZWRkZWQgRUUgY2VydGlmaWNhdGUsIGFzIHJlcXVpcmVkIGJ5IFJGQyA2NDgyLuKA nSAgVGhlIFZSUyBpcyBpbnRyb2R1Y2VkIGluIHRoaXMgZG9jdW1lbnQsIG5vdCBSRkM2NDgyLg0K DQoNCg0KTml0czoNCg0KTjEuIOKAnFRoaXMgZG9jdW1lbnQgcHJvcG9zZXPigKbigJ0gYW5kIOKA nFRoZSBjaGFuZ2VzIHByb3Bvc2VkIGhlcmXigKbigJ0uICBXZeKAmXJlIHBhc3QgdGhlIHByb3Bv c2FsIHBoYXNlOiDigJxUaGlzIGRvY3VtZW50IHNwZWNpZmllc+KApuKAnQ0KDQpOMi4gcy8gbWFp bnRhaW5pbmcgVmVyaWZpZWQgUmVzb3VyY2UgU2V0LyBtYWludGFpbmluZyBhIFZlcmlmaWVkIFJl c291cmNlIFNldA0KDQpOMy4gcy8gdGhlIGxvc3Mgb2Ygb24gSVAgYWRkcmVzcyBwcmVmaXgvIHRo ZSBsb3NzIG9mIG9uZSBJUCBhZGRyZXNzIHByZWZpeA0KDQpONC4gcy8gdGhlIDE5ODggQVNOLjEg bW9kdWxlcyBmb3Igd2hpY2ggd2UgcHJvdmlkZWQgYW4gdXBkYXRlIGluIFNlY3Rpb24gNC4yLjIu NyByZW1haW4gdGhlIG5vcm1hdGl2ZSB2ZXJzaW9uLyB0aGUgMTk4OCBBU04uMSBtb2R1bGVzIGlu IFNlY3Rpb24gNC4yLjIuNyByZW1haW4gdGhlIG5vcm1hdGl2ZSB2ZXJzaW9uDQoNCk41LiBzLyBG dXJ0aGVybW9yZSB3ZSB3aXNoIHRvIG5vdGUgdGhhdCBvcGVyYXRvcnMgTUFZIGlzc3VlIHNlcGFy YXRlIEJHUHNlYyBSb3V0ZXIgQ2VydGlmaWNhdGVzIGZvciBkaWZmZXJlbnQgQVNOcy8gT3BlcmF0 b3JzIE1BWSBpc3N1ZSBzZXBhcmF0ZSBCR1BzZWMgUm91dGVyIENlcnRpZmljYXRlcyBmb3IgZGlm ZmVyZW50IEFTTnMNCg== --_000_5821A5CFEFF84CE39AA4CFDB9C903D63ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <7C8445DC1750954AA273C7FE585D4463@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9u dCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRo IjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDsNCglmb250LXdlaWdo dDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNv bG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFs O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHls ZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI3Ii8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIi8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2Nv bG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+RGVhciBhdXRob3JzOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+SSBqdXN0IGZpbmlzaGVkIHJlYWRpbmcgdGhpcyBkb2N1 bWVudC4mbmJzcDsgTXkgcmV2aWV3IGlzIHByZWRpY2F0ZWQgb24gdGhlIGFzc3VtcHRpb24gdGhh dCB0aGUgaW50ZW50IG9mIHRoZSBXRyBpcyB0byBkZWZpbmUgYW4gYWRkaXRpb25hbCB2YWxpZGF0 aW9uIHByb2Nlc3MsIGFuZCBub3QgYW1lbmQvY2hhbmdlL3VwZGF0ZS9kZXByZWNhdGUgdGhlIGV4 aXN0aW5nDQogb25l4oCmeWV0LCB3aGljaCBpcyB3aHkgdGhlcmUgYXJlIG5vdCBvbmx5IHByb2Nl c3MgY2hhbmdlcyBzcGVjaWZpZWQsIGJ1dCBhbHNvIG5ldyBPSURzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QXMgd3JpdHRlbiwgd2l0aCBVcGRhdGVzIGFuZCB0 ZXh0IOKAnHRvIGJlIHVzZWQgaW4gcGxhY2Ugb2bigJ0gZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbnMs IHRoZSBkb2N1bWVudCBhY2hpZXZlcyB0aGUgZGVwcmVjYXRpb24gb2YgdGhlIGN1cnJlbnQgKG9s ZCkgbWVjaGFuaXNtOiBzaW1wbHkgYmVjYXVzZSBwcm9jZWR1cmFsbHkgeW91IGFyZSByZXBsYWNp bmcgdGhlIGV4aXN0aW5nL29sZA0KIHRleHQgd2l0aCB0aGUgbmV3IG9uZeKApmFuZCB0aGUgb2xk IG9uZSB3b3VsZCB0aGVuIG5vdCBiZSBhbnltb3JlLiZuYnNwOyBUaGUgcmVzdWx0IHRoZW4gaXMg bm90IGNvaGVyZW50IHdpdGggdGhlIGFzc3VtcHRpb24gYWJvdmUsIGFuZCB3ZSB3aWxsIG5lZWQg dG8gcmV3cml0ZSAoYXQgbGVhc3QgZnJvbSBhbiBpbnRlbnQgcG9pbnQgb2YgdmlldykgdGhlIGRv Y3VtZW50IGJlZm9yZSBwcm9ncmVzc2luZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPkkgdGhpbmsgdGhhdCB0aGUgZWFzaWVzdCB3YXkgZm9yd2FyZCB3b3VsZCBi ZSBmb3IgdGhpcyBkb2N1bWVudCB0byBzYXkgc29tZXRoaW5nIGxpa2U6IOKAnGEgbmV3IHZhbGlk YXRpb24gbWVjaGFuaXNtIGlzIHNwZWNpZmllZCwgd2hpY2ggdXNlcyB0aGVzZSBuZXcgT0lEcyDi gJMgdGhlIHNwZWNpZmljYXRpb25zIGRlZmluZWQgaW4gUkZDQSwgUkZDQiwgZXRjLi4NCiBhcHBs eSwgZXhjZXB0IGZvciB0aGUgZm9sbG93aW5nIGV4Y2VwdGlvbnMvY2hhbmdlcy7igJ0mbmJzcDsg WW91IHNob3VsZCB0aGVuIGJlIGFibGUgdG8gdXNlIG1vc3Qgb2YgdGhlIHN1YnN0YW50aXZlIHRl eHQgYWxyZWFkeSB3cml0dGVuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+UGxlYXNlIHNlZSBiZWxvdyBmb3Igc3BlY2lmaWMgY29tbWVudHMg4oCTIGluY2x1ZGlu ZyBtb3JlIG9uIHdoeSB0aGlzIGRvY3VtZW50IHNob3VsZCBub3QgVXBkYXRlIHRoZSBleGlzdGlu ZyBSRkNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhhbmtz ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QWx2YXJvLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NYWpvcjo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk0xLiBTZWN0aW9uIDQuMi4xLiAoQ2hhbmdlcyB0byBS RkM2NDg0KS4mbmJzcDsgVGhpcyBkb2N1bWVudCByZXF1ZXN0cyBhbiBhc3NpZ25tZW50IG9mIGEg bmV3IE9JRCAoaWQtY3AtaXBBZGRyLWFzTnVtYmVyLXYyKTsgYm90aCB0aGUgcmVmZXJlbmNlIGFu ZCB0aGUgcG9saWN5IHRvIGJlIGZvbGxvd2VkIGFyZSBjb250YWluZWQgaGVyZSwgYW5kIG5vdCBp biBSRkM2NDg0LiZuYnNwOw0KIElPVywgdGhpcyBkb2N1bWVudCBzaG91bGRu4oCZdCBVcGRhdGUg UkZDNjQ4NC4gJm5ic3A7SW5zdGVhZCwgaXQgc2hvdWxkIHJlcXVlc3QgdGhlIG5ldyBPSUQgYW5k IHNpbXBseSByZWZlcmVuY2UgUkZDNjQ4NCB3aGVuIHBvaW50aW5nIGJhY2sgdG8gaWQtY3AtaXBB ZGRyLWFzTnVtYmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk0yLiBTZWN0aW9uIDQuMi4yLiAoQ2hhbmdlcyB0byBS RkMzNzc5KS4mbmJzcDsgU2FtZSBjb21tZW50OiB0aGlzIGRvY3VtZW50IHJlcXVlc3RzIHRoZSBh c3NpZ25tZW50IG9mIG5ldyBPSURz4oCmLiZuYnNwOyBOb3RlIHRoYXQgaWYgdGhlIGNoYW5nZXMg aW4gU2VjdGlvbiA0LjIuMi4xLiAoT0lEIGZvciBpZC1wZS1pcEFkZHJCbG9ja3MtdjIpIGFuZCBT ZWN0aW9uIDQuMi4yLjMuDQogKE9JRCBmb3IgaWQtcGUtYXV0b25vbW91c1N5c0lkcy12Mikgd2Vy ZSB0byBiZSB1c2VkIGluIHBsYWNlIG9mIHRoZSB0ZXh0IGluIFJGQzM3NzksIHRoZW4gaWQtcGUt aXBBZGRyQmxvY2tzIGFuZCBpZC1wZS1hdXRvbm9tb3VzU3lzSWRzIHdvdWxkIGVuZCB1cCBiZWlu ZyBkZXByZWNhdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ TTIuMS4gW21pbm9yXSBUaGUgc3ludGF4IGZvciBpZC1wZS1pcEFkZHJCbG9ja3MtdjIgYW5kIGlk LXBlLWF1dG9ub21vdXNTeXNJZHMtdjIgKDQuMi4yLjIgYW5kIDQuMi4yLjQpIHVzZSB0aGUg4oCc djHigJ0gbmFtZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5N Mi4yLiBGb3IgU2VjdGlvbnMgNC4yLjIuNSBhbmQgNC4yLjIuNiwgSSB0aGluayB0aGF0IHdoYXQg eW91IHdhbnQgdG8gc2F5IGlzIChzb21ldGhpbmcgbGlrZSk6IOKAnHdoZW4gdGhlIE9JRHMgZGVm aW5lZCBpbiB0aGlzIGRvY3VtZW50IGFyZSB1c2VkLCB0aGUgcHJvY2VkdXJlcyBpbiBSRkMzNzc5 IGFyZSBmb2xsb3dlZCwgZXhjZXB0IGZvciB0aGUgY2VydGlmaWNhdGUNCiBwYXRoIHZhbGlkYXRp b24gKHNlY3Rpb24gMi4zKSwgd2hpY2ggaXMgc3BlY2lmaWVkIGluIFNlY3Rpb24gNC4yLjQuNCBv ZiB0aGlzIGRvY3VtZW50LCBhbmTigKbigJ0mbmJzcDsgQWdhaW4sIGlmIHRoZSB0ZXh0IHdhcyB0 byByZXBsYWNlIHdoYXQgaXMgY3VycmVudGx5IGluIFJGQzM3NzksIHRoZW4gdGhvc2UgcHJvY2Vk dXJlcyB3b3VsZCBiZSBkZXByZWNhdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+TTIuMy4gU2FtZSBjb21tZW50IGZvciBTZWN0aW9uIDQuMi4yLjc6IGFtZW5k aW5nIHRoZSBzcGVjaWZpY2F0aW9uIGluIFJGQzM3NzkgcmVzdWx0cyBpbiBsb29zaW5nIHdoYXQg aXMgZGVmaW5lZCB0aGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NMy4gU2VjdGlvbiA0LjIuNC4gKENoYW5nZXMg dG8gUkZDNjQ4NykuJm5ic3A7IFNhbWUgY29tbWVudHMgYXMgYWJvdmU6IHJlcGxhY2luZyB0aGUg dGV4dCAod2hpY2ggaXMgd2hhdCBhbiBVcGRhdGUgZG9lcyksIHdvdWxkIHJlc3VsdCBpbiB0aGUg bWVjaGFuaXNtIHNwZWNpZmllZCBpbiBSRkM2NDg3IHRvIGJlIHRoZSBzYW1lIGFzIHdoYXQgaXMg c3BlY2lmaWVkIGluDQogdGhpcyBkb2N1bWVudOKApndoaWNoIG1lYW5zIHRoYXQgdGhlIG9wdGlv biBpbiB0aGUgZmlyc3QgcGFyYWdyYXBoICjigJzigKZNVVNUIGlzc3VlIGNlcnRpZmljYXRlcyBl aXRoZXIgYXMgc3BlY2lmaWVkIGluIFtSRkM2NDg3XSBvciB3aXRoIGFsbCB0aGUgYW1lbmRtZW50 cyBzcGVjaWZpZWQgaW4gdGhlIGZvbGxvd2luZyBzZWN0aW9ucy4pIHdvdWxkIHJlc3VsdCBpbiB0 aGUgc2FtZSB0aGluZy4mbmJzcDsgQXMgd2l0aCBTZWN0aW9uIDQuMi4yIChhYm92ZSksIEkNCiB0 aGluayB5b3UgcmVhbGx5IHNob3VsZCBzcGVjaWZ5IHdoYXQgdGhlIGV4Y2VwdGlvbnMgYXJlIGZv ciB0aGUgZXh0ZW5zaW9ucyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgKGFuZCBub3QgVXBkYXRl IFJGQzY0ODcpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk00LiBTZWN0aW9uIDQuMi40LjQuIChBbWVuZGVkIFJlc291 cmNlIENlcnRpZmljYXRlIFBhdGggVmFsaWRhdGlvbikuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5NNC4xLiBbQ29tbWVudCBhYm91dCBSRkM2NDg3XSBUaGlzIGRv Y3VtZW50IGNvcnJlY3RseSBtZW50aW9ucyB0aGUgTm90QmVmb3JlL05vdEFmdGVyIHZhbHVlcyAo d2hpY2ggc2hvdWxkIHJlYWxseSBiZSBub3RCZWZvcmUvbm90QWZ0ZXIpLCBpbnN0ZWFkIG9mIEZy b20vVG8gKGluIFJGQzY0ODcpLiZuYnNwOyBJdCBzZWVtcyB0byBtZSB0aGF0IHRoaXMgaXMgYW4g ZXJyb3INCiBpbiB0aGUgb3JpZ2luYWwgdGV4dC4mbmJzcDsgQ2FuIHlvdSBwbGVhc2UgZmlsZSBh biBFcnJhdGEgYWdhaW5zdCBSRkM2NDg3PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+TTQuMi4gcy9DZXJ0aWZpY2F0ZSB4IGNvbnRhaW5zIGFsbCB0aGUgZXh0ZW5z aW9ucyB0aGF0IE1VU1QgYmUgcHJlc2VudC9DZXJ0aWZpY2F0ZSB4IGNvbnRhaW5zIGFsbCB0aGUg cmVxdWlyZWQgZXh0ZW5zaW9ucyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUg4oCcTVVTVOKAnSBpcyBu b3Qgbm9ybWF0aXZlIGluIHRoaXMgY29udGV4dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPk00LjMuIFttaW5vcl0gcy9NVVNUIGJlIHNhdGlzZnkgdGhlIGNvbnN0 cmFpbnRzL01VU1Qgc2F0aXNmeSB0aGUgY29uc3RyYWludHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk00LjQuIOKAnElmIElQIEFkZHJlc3MgRGVsZWdhdGlvbiBl eHRlbnNpb24gaXMgcHJlc2VudCwgaXQgaXMgcmVwbGFjZWQgd2l0aCB0aGUgaW50ZXJzZWN0aW9u IG9mIHRoZSB2YWx1ZXMgZnJvbSB0aGF0IGV4dGVuc2lvbiBhbmQgdGhlIGN1cnJlbnQgdmFsdWUg b2YgdGhlIFZSUy1JUC7igJ0mbmJzcDsgV2hhdCBpcyByZXBsYWNlZCwgdGhlIElQIEFkZHJlc3Mg RGVsZWdhdGlvbg0KIGV4dGVuc2lvbiBvciB0aGUgVlJTLUlQPyZuYnNwOyBJZiB0aGUgZXh0ZW5z aW9uLCB3aGF0IGRvZXMgaXQgbWVhbiB0byByZXBsYWNlIHRoZSBleHRlbnNpb24gaW4gdGhlIGNl cnRpZmljYXRlPyZuYnNwOyZuYnNwOyBOb3RlIHRoYXQgdGhlIHRleHQgYWJvdXQgdGhlIEFTIElk ZW50aWZpZXIgRGVsZWdhdGlvbiBleHRlbnNpb24gaXMgYXMgY29uZnVzaW5nLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TTQuNS4g4oCc4oCmdGhlc2UgdmFsdWVz IE1BWSBiZSBzdG9yZWQgYWxvbmcgd2l0aCB0aGUgY2VydGlmaWNhdGUsIHRvIGZhY2lsaXRhdGUg aW5jcmVtZW50YWwgdmFsaWRhdGlvbuKApuKAnSZuYnNwOyBUaGlzIGRvY3VtZW50IChhbmQgUkZD NjQ4NykgZG9u4oCZdCBzYXkgYW55dGhpbmcgYWJvdXQgd2hlcmUgdG8gc3RvcmUgYW55dGhpbmcg 4oCTIEkgZG9u4oCZdCB0aGluayB3ZSBuZWVkIHRoYXQNCiBub3JtYXRpdmUg4oCcTUFZ4oCdLiZu YnNwOyZuYnNwOyBzL01BWS9tYXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPk00LjYuIFRoaXMgdGV4dCBpcyBub3QgbmVlZGVkOiDigJxJZiBjZXJ0aWZpY2F0ZSB4 IHVzZXMgdGhlIG9yaWdpbmFsIHZlcnNpb24gb2YgW1JGQzY0ODddLCB0aGVuIGNlcnRpZmljYXRl IHggTVVTVCBiZSByZWplY3RlZC7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NNS4gU2VjdGlvbiA0LjIuNS4gKENoYW5nZXMg dG8gUkZDNjQ4MikuJm5ic3A7IFNhbWUgY29tbWVudCBhYm91dCBub3QgbmVlZGluZyBhbiBVcGRh dGUvcmVwbGFjaW5nIHRoZSB0ZXh0L+KApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk02LiBTZWN0aW9uIDUuIChEZXBs b3ltZW50IENvbnNpZGVyYXRpb25zKS4mbmJzcDsgVGhlIHRpbWVsaW5lIGluIFRhYmxlIDEgc2hv dWxkbuKAmXQgYXBwZWFyIGluIHRoaXMgc3BlY2lmaWNhdGlvbi4mbmJzcDsgTWlncmF0aW9uIGlz IGFuIG9wZXJhdGlvbmFsIGlzc3VlIHRoYXQgdGhlIGNvbW11bml0eSBzaG91bGQgY29vcmRpbmF0 ZSBzZXBhcmF0ZWx5IChhbmQgbm90IGJ5IHNwZWNpZnlpbmcNCiBhIG5vcm1hdGl2ZSB0aW1lbGlu ZSBpbiBhbiBSRkMpLiZuYnNwOyBXaGF0IHNob3VsZCBiZSBpbmNsdWRlZCBoZXJlIGFyZSBhbnkg b3RoZXIgbWlncmF0aW9uIGNvbnNpZGVyYXRpb25zIHRoYXQgc2hvdWxkIGJlIG9ic2VydmVkIHdo ZW4gbWFraW5nIHRoZSB0cmFuc2l0aW9uIOKAkyBpZiB0aGVyZeKAmXMgYW55dGhpbmcgYmV5b25k IHdoYXQgeW91IGFscmVhZHkgd3JvdGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TTcuIFNlY3Rpb24gNi4gKFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zKS4gUGxlYXNlIHBvaW50IHRvIHRoZSBzZWN1cml0eSBjb25zaWRl cmF0aW9ucyBpbiBSRkMzNzc5LCBSRkM2NDgyLCBSRkM2NDg0IGFuZCBSRkM2NDg3IGFzIGFwcGx5 aW5nIGhlcmUgdG9vLiZuYnNwOyBJdCBtaWdodCBiZSBiZW5lZmljaWFsIHRvIGluY2x1ZGUgYSBz aG9ydCBkaXNjdXNzaW9uIG9mDQogd2h5IG5vdCBpbW1lZGlhdGVseSByZWplY3RpbmcgdGhlIG92 ZXItY2xhaW1pbmcgY2VydGlmaWNhdGVzIGlzIG5vdCBhIHNlY3VyaXR5IGlzc3VlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+TTguIElBTkEgQ29uc2lkZXJhdGlvbnMuJm5ic3A7Jm5ic3A7IFRCRDQvVEJENSBhcmUgbm90 IGZvciBJUEFkZHJBbmRBU0NlcnRFeHRuLSosIGJ1dCBmb3IgdGhlIG5ldyBpZC1tb2QtaXAtYWRk ci1hbmQtYXMtaWRlbnQtKi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPk05LiBSZWZlcmVuY2VzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi0gUGxlYXNlIGFkZCBhIHJlZmVy ZW5jZSB0byBSRkMyMTE5IGFuZCB0aGUgY29ycmVzcG9uZGluZyBib2lsZXJwbGF0ZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+LSBJIGRvbuKAmXQgdGhpbmsgdGhhdCB0aGUgcmVmZXJlbmNlIHRvIFJGQzYy NjggbmVlZHMgdG8gbWUgTm9ybWF0aXZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4tIFdlIGRvbuKAmXQg bmVlZCByZWZlcmVuY2VzIHRvIFJGQzM4NDksIFJGQzUzOTggb3IgUkZDNTczNy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+LSBSRkMzMjgwIHdhcyBPYnNvbGV0ZWQgYnkgUkZDNTI4MDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NaW5vcjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPlAxLiZuYnNwOyBUaGUgZXhhbXBsZSBpbiBTZWN0aW9uIDMgaXMgbWVh bnQgdG8gYmUgYSBjb250aW51YXRpb24gZnJvbSB0aGUgZXhhbXBsZSBpbiBTZWN0aW9uIDIgKOKA nENlcnRpZmljYXRlIDIgZnJvbSB0aGUgcHJldmlvdXMgZXhhbXBsZSB3YXMgcmUtaXNzdWVkIGJ5 IFRBIHRvIENBMSBhbmQgdGhlIHByZWZpeCAxOTguNTEuMTAwLjAvMjQgd2FzIHJlbW92ZWQuJm5i c3A7IEhvd2V2ZXIsDQogQ0ExIGZhaWxlZCB0byByZS1pc3N1ZSBhIG5ldyBDZXJ0aWZpY2F0ZSAz IHRvIENBMi7igJ0pOyBidXQgQ2VydGlmaWNhdGUgMyBpcyBub3QgdGhlIHNhbWUgYXMgdGhlIG9u ZSBzaG93biBpbiBTZWN0aW9uIDIuJm5ic3A7IEkgdGhpbmsgdGhlIGV4YW1wbGUgc3RpbGwgZ2V0 cyB0aGUgb3Zlci1jbGFpbWluZyBwb2ludCBhY3Jvc3MsIGJ1dCBpdCBpcyDigJx3cm9uZ+KAnSBp biB0aGF0IGJvdGggQ2VydGlmaWNhdGUgMiBhbmQgQ2VydGlmaWNhdGUgMyAobm90IGp1c3QNCiBD ZXJ0aWZpY2F0ZSAyKSB3b3VsZCBoYXZlIHRvIGNoYW5nZSBmb3IgdGhlIHByb2JsZW0gdG8gaGFw cGVuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UDIsIEFsc28g aW4gdGhlIGV4YW1wbGUgaW4gU2VjdGlvbiAzLiZuYnNwOyBJdCBtaWdodCBiZSBiZW5lZmljaWFs IGZvciB0aGUgcmVhZGVyIGlmIHRoZSBFRSBjZXJ0aWZpY2F0ZSB3YXMgYWxzbyBtYXJrZWQgYXMg aW52YWxpZDsgdGhlIHRleHQgc2F5cyBzbywgYnV0IHRoZSBsaXN0IG9mIGNlcnRpZmljYXRlcyBk b2VzbuKAmXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QMy4g SW4gc2V2ZXJhbCBwbGFjZXMg4oCcW3RoaXMgZG9jdW1lbnRd4oCdIGlzIHVzZWQg4oCTIGlmIHRo ZSBpbnRlbnQgaXMgdG8gcmVmZXIgdG8gYSBzcGVjaWZpYyBTZWN0aW9uLCBwbGVhc2UgaW5kaWNh dGUgd2hpY2guJm5ic3A7IElmIG5vdCwgdGhlbiB5b3Ugc2hvdWxkIGdldCByaWQgb2YgdGhlIGJy YWNrZXRzIChbXSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Q NC4gSW4gNC4zOiDigJxST0ExIGlzIGNvbnNpZGVyZWQgdmFsaWQgYmVjYXVzZSB0aGUgcHJlZml4 IG1hdGNoZXMgdGhlIFZlcmlmaWVkIFJlc291cmNlIFNldCBvbiB0aGUgZW1iZWRkZWQgRUUgY2Vy dGlmaWNhdGUsIGFzIHJlcXVpcmVkIGJ5IFJGQyA2NDgyLuKAnSZuYnNwOyBUaGUgVlJTIGlzIGlu dHJvZHVjZWQgaW4gdGhpcyBkb2N1bWVudCwgbm90IFJGQzY0ODIuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPk5pdHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5OMS4g4oCcVGhpcyBkb2N1bWVudCBwcm9wb3Nlc+KApuKAnSBhbmQg4oCcVGhl IGNoYW5nZXMgcHJvcG9zZWQgaGVyZeKApuKAnS4mbmJzcDsgV2XigJlyZSBwYXN0IHRoZSBwcm9w b3NhbCBwaGFzZTog4oCcVGhpcyBkb2N1bWVudCBzcGVjaWZpZXPigKbigJ08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk4yLiBzLzwvc3Bhbj4gPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPg0KbWFpbnRhaW5pbmcgVmVyaWZpZWQgUmVzb3VyY2UgU2V0Lzwv c3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPm1haW50YWluaW5nIGEgVmVyaWZp ZWQgUmVzb3VyY2UgU2V0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5OMy4gcy88L3NwYW4+IDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4NCnRoZSBsb3Nz IG9mIG9uIElQIGFkZHJlc3MgcHJlZml4Lzwvc3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPnRoZSBsb3NzIG9mIG9uZSBJUCBhZGRyZXNzIHByZWZpeDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TjQuIHMvPC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+DQp0aGUgMTk4OCBBU04uMSBtb2R1bGVzIGZvciB3aGljaCB3ZSBwcm92 aWRlZCBhbiB1cGRhdGUgaW4gU2VjdGlvbiA0LjIuMi43IHJlbWFpbiB0aGUgbm9ybWF0aXZlIHZl cnNpb24vPC9zcGFuPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPnRoZSAxOTg4IEFT Ti4xIG1vZHVsZXMgaW4gU2VjdGlvbiA0LjIuMi43IHJlbWFpbiB0aGUgbm9ybWF0aXZlIHZlcnNp b248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk41LiBzLzwvc3Bh bj4gPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPg0KRnVydGhlcm1vcmUgd2Ugd2lzaCB0 byBub3RlIHRoYXQgb3BlcmF0b3JzIE1BWSBpc3N1ZSBzZXBhcmF0ZSBCR1BzZWMgUm91dGVyIENl cnRpZmljYXRlcyBmb3IgZGlmZmVyZW50IEFTTnMvPC9zcGFuPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPk9wZXJhdG9ycyBNQVkgaXNzdWUgc2VwYXJhdGUgQkdQc2VjIFJvdXRlciBD ZXJ0aWZpY2F0ZXMgZm9yIGRpZmZlcmVudCBBU05zPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5821A5CFEFF84CE39AA4CFDB9C903D63ciscocom_-- From nobody Sat Mar 11 12:54:01 2017 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 519341295BF; Sat, 11 Mar 2017 12:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vM7vTCVoToFc; Sat, 11 Mar 2017 12:53:58 -0800 (PST) Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29D1B129415; Sat, 11 Mar 2017 12:53:58 -0800 (PST) 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 khatovar.hactrn.net (Postfix) with ESMTPS id EBC90139A2; Sat, 11 Mar 2017 20:53:56 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 9E01F5A9836; Sat, 11 Mar 2017 15:53:56 -0500 (EST) Date: Sat, 11 Mar 2017 15:53:56 -0500 From: Rob Austein To: Tim Bruijnzeels In-Reply-To: References: <148721059915.31454.12790381111112907537.idtracker@ietfa.amsl.com> <47B3699A-B344-4BA5-A131-309A6DF04FBD@ripe.net> <3A008C78-B846-4F8F-A813-C54C276FAEFD@cisco.com> <9DC16A6F-84C6-4E59-9086-3C4EB1A0C05E@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: <20170311205356.9E01F5A9836@minas-ithil.hactrn.net> Archived-At: Cc: "sidr@ietf.org" , "sidr-chairs@ietf.org" , "morrowc@ops-netman.net" , The IESG , "sandy@tislabs.com" , "draft-ietf-sidr-delta-protocol@ietf.org" Subject: Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT) 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, 11 Mar 2017 20:53:59 -0000 [Late response] At Tue, 28 Feb 2017 15:25:49 +0100, Tim Bruijnzeels wrote: > > On 27 Feb 2017, at 10:24, Oleg Muravskiy wrote: ... > > In order to allow RRDP in TAL, I think we have to keep the update > > to RFC7730 in draft-ietf-sidr-delta-protocol, namely this part of > > the draft: > > While I share my co-author's enthusiasm to update the TAL document, > I propose to do this as a separate effort so that the delta protocol > doesn't depend on this. It's not needed by the protocol after all, > but would help scale access to Trust Anchor certificates. > > Also when we go here I believe we will have to allow HTTPS > specifically as an alternative scheme. And we may have discussions > whether it should be allowed in addition or even instead of rsync > (which I believe may be a lot simpler than phasing out rsync > everywhere else). FWIW, I agree with Tim. See RFC 1925 (5) :) From nobody Sat Mar 11 13:53:23 2017 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 B68DD12944C; Sat, 11 Mar 2017 13:53:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148926919772.2868.18334824717040921717@ietfa.amsl.com> Date: Sat, 11 Mar 2017 13:53:17 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-publication-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: Sat, 11 Mar 2017 21:53:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : A Publication Protocol for the Resource Public Key Infrastructure (RPKI) Authors : Samuel Weiler Anuja Sonalker Rob Austein Filename : draft-ietf-sidr-publication-12.txt Pages : 20 Date : 2017-03-11 Abstract: This document defines a protocol for publishing Resource Public Key Infrastructure (RPKI) objects. Even though the RPKI will have many participants issuing certificates and creating other objects, it is operationally useful to consolidate the publication of those objects. Even in cases where a certificate issuer runs their own publication repository, it can be useful to run the certificate engine itself on a different machine from the publication repository. This document defines a protocol which addresses these needs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-publication/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-publication-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-publication-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 Sat Mar 11 14:11:25 2017 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 31B8512949F; Sat, 11 Mar 2017 14:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGDyvI6MY7yg; Sat, 11 Mar 2017 14:11:22 -0800 (PST) Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A1891294A8; Sat, 11 Mar 2017 14:11:22 -0800 (PST) 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 khatovar.hactrn.net (Postfix) with ESMTPS id A7A041398E; Sat, 11 Mar 2017 22:11:19 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 826945AC986; Sat, 11 Mar 2017 17:11:18 -0500 (EST) Date: Sat, 11 Mar 2017 17:11:18 -0500 From: Rob Austein To: Alexey Melnikov In-Reply-To: <148812023477.2888.8486186818190857881.idtracker@ietfa.amsl.com> References: <148812023477.2888.8486186818190857881.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170311221118.826945AC986@minas-ithil.hactrn.net> Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, draft-ietf-sidr-publication@ietf.org Subject: Re: [sidr] Alexey Melnikov's No Objection on draft-ietf-sidr-publication-11: (with COMMENT) 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, 11 Mar 2017 22:11:23 -0000 At Sun, 26 Feb 2017 06:43:54 -0800, Alexey Melnikov wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I still think lack of details about versionning and what requires (or > not) to bump the version number is a mistake. I added a sentence stating that incompatible changes to syntax or semantics require a new version number, which seems kind of obvious. Beyond that, it's pretty much impossible to say whether a change is compatible without knowing the details of a particular proposed change, so I see little to be gained in hypothetical discussion. If you need something more than this, please send text or point to an example of what you want (and, with respect, a hint at what it's intended to accomplish), because at this point I do not have a clue. > RFC 2616 (HTTP) got obsoleted, please reference the latest version. Oops, sorry. Done. > In 2.5: is the list of error reasons extensible? If yes, should you have > an IANA registry for them? No current plan to extend the set of error reasons. > In Section 5 you should reference this document (and not just section > numbers), as IANA registrations cut & pasted to IANA website as separate > files. I assume you meant section 4, since I don't think IANA publishes Security Considerations. Draft -11 had already added [[RFCxxxx]] to the media type template in the IANA Considerations section, per your earlier instructions, and there are no section numbers in the media type template. Am I missing something here? Given the impending dreadline, I posted -12. If this is close enough, cool, otherwise tell me what to do and we'll fix it. From nobody Sat Mar 11 14:25:29 2017 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 0F626129413; Sat, 11 Mar 2017 14:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUjrflwB9sZ7; Sat, 11 Mar 2017 14:25:27 -0800 (PST) Received: from khatovar.hactrn.net (khatovar.hactrn.net [IPv6:2001:418:8006::30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D10A1294A8; Sat, 11 Mar 2017 14:25:27 -0800 (PST) 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 khatovar.hactrn.net (Postfix) with ESMTPS id 8BB8C1398E; Sat, 11 Mar 2017 22:25:26 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 324125ACF21; Sat, 11 Mar 2017 17:25:27 -0500 (EST) Date: Sat, 11 Mar 2017 17:25:27 -0500 From: Rob Austein To: "Alvaro Retana (aretana)" In-Reply-To: <5821A5CF-EFF8-4CE3-9AA4-CFDB9C903D63@cisco.com> References: <5821A5CF-EFF8-4CE3-9AA4-CFDB9C903D63@cisco.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20170311222527.324125ACF21@minas-ithil.hactrn.net> Archived-At: Cc: Chris Morrow , "sidr-chairs@ietf.org" , "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-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: Sat, 11 Mar 2017 22:25:28 -0000 At Thu, 9 Mar 2017 18:44:58 +0000, Alvaro Retana (aretana) wrote: >=20 > I just finished reading this document. My review is predicated on > the assumption that the intent of the WG is to define an additional > validation process, and not amend/change/update/deprecate the > existing one?yet, which is why there are not only process changes > specified, but also new OIDs. Alvaro, I will let the WG chairs and authors speak to intent regarding the existing validation process. Speaking as an implementer, I requested, nay, demanded the new OIDs, for a very simple technical reason: from an implementation standpoint, the new validation rule is very different from the old one. More precisely, it is very close to the same set of checks as the old rule, but in a very different place in the code. Given the overall structure of X.509v3's critical extension mechanism, new OIDs were by far the simplest means of signalling which rule an RP should use. So the decision to use new OIDs is orthogonal to the deprecation discussion: we need the new OIDs in any case for technical reasons. From nobody Sun Mar 12 11:28:57 2017 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 72DAF129416; Sun, 12 Mar 2017 11:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kce6C14YoU09; Sun, 12 Mar 2017 11:28:54 -0700 (PDT) Received: from relay.kvm02.ops-netman.net (relay.kvm02.ops-netman.net [IPv6:2606:700:e:550:5c82:28ff:fe25:4960]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A1B3129406; Sun, 12 Mar 2017 11:28:53 -0700 (PDT) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id 0A80C3FCF7; Sun, 12 Mar 2017 18:28:52 +0000 (UTC) Received: from morrowc.roam.corp.google.com.ops-netman.net (static-96-241-182-39.washdc.fios.verizon.net [96.241.182.39]) (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 D869A5AC3A1A; Sun, 12 Mar 2017 18:28:51 +0000 (UTC) Date: Sun, 12 Mar 2017 14:28:51 -0400 Message-ID: From: Chris Morrow To: Rob Austein In-Reply-To: <20170311222527.324125ACF21@minas-ithil.hactrn.net> References: <5821A5CF-EFF8-4CE3-9AA4-CFDB9C903D63@cisco.com> <20170311222527.324125ACF21@minas-ithil.hactrn.net> 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: Cc: Chris Morrow , "sidr-chairs@ietf.org" , "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-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: Sun, 12 Mar 2017 18:28:55 -0000 At Sat, 11 Mar 2017 17:25:27 -0500, Rob Austein wrote: > > At Thu, 9 Mar 2017 18:44:58 +0000, Alvaro Retana (aretana) wrote: > > > > I just finished reading this document. My review is predicated on > > the assumption that the intent of the WG is to define an additional > > validation process, and not amend/change/update/deprecate the > > existing one?yet, which is why there are not only process changes > > specified, but also new OIDs. > > Alvaro, > > I will let the WG chairs and authors speak to intent regarding the > existing validation process. > I think the intent of the WG is still to add the new validation process, then deprecate the original once all users are on code which supports the 'new' way. -chris From nobody Sun Mar 12 23:27:00 2017 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 D2ADF128B37 for ; Sun, 12 Mar 2017 23:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpO0vwfPBD0X for ; Sun, 12 Mar 2017 23:26:57 -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 791091293F8 for ; Sun, 12 Mar 2017 23:26:57 -0700 (PDT) X-TM-DID: ab0815a845e3820d094f20516e42172c Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Declan Ma In-Reply-To: Date: Mon, 13 Mar 2017 14:16:59 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6359B4B1-478D-4017-B259-7B60BA55FF39@zdns.cn> References: <5821A5CF-EFF8-4CE3-9AA4-CFDB9C903D63@cisco.com> <20170311222527.324125ACF21@minas-ithil.hactrn.net> To: Chris Morrow X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "sidr@ietf.org" , "sidr-chairs@ietf.org" , Rob Austein , "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-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: Mon, 13 Mar 2017 06:26:59 -0000 Speaking as the representative of RPSTIR team, We are working on RPSTIR update in order to make it use the new = algorithm to do INR validation.=20 Before RP performs the new validation process, it needs to get the INRs = from certificates. And we found a bug of OPENSSL library when using = OPENSSL to get resource sets from certificates, so we wrote our own code = to do so. =20 It seems to me that the only concern on OID is about using OPENSSL to = get resource sets for further validation process. If the WG has decided = to deprecate the original by using the Validation Reconsidered, why = bother to bring a new OID ? Declan(Di) Ma ZDNS=20 > =D4=DA 2017=C4=EA3=D4=C213=C8=D5=A3=AC02:28=A3=ACChris Morrow = =D0=B4=B5=C0=A3=BA >=20 > At Sat, 11 Mar 2017 17:25:27 -0500, > Rob Austein wrote: >>=20 >> At Thu, 9 Mar 2017 18:44:58 +0000, Alvaro Retana (aretana) wrote: >>>=20 >>> I just finished reading this document. My review is predicated on >>> the assumption that the intent of the WG is to define an additional >>> validation process, and not amend/change/update/deprecate the >>> existing one?yet, which is why there are not only process changes >>> specified, but also new OIDs. >>=20 >> Alvaro, >>=20 >> I will let the WG chairs and authors speak to intent regarding the >> existing validation process. >>=20 >=20 > I think the intent of the WG is still to add the new validation > process, then deprecate the original once all users are on code which > supports the 'new' way. >=20 > -chris >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Mon Mar 13 02:56:06 2017 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 6E533129400; Mon, 13 Mar 2017 02:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvg8CcTeVkYI; Mon, 13 Mar 2017 02:56:03 -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 DC181128AB0; Mon, 13 Mar 2017 02:56:02 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from ) id 1cnMhp-0000Y6-6B; Mon, 13 Mar 2017 10:55:58 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-195.ripe.net) by nene.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1cnMho-0007Eu-Tl; Mon, 13 Mar 2017 10:55:57 +0100 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Tim Bruijnzeels In-Reply-To: <6359B4B1-478D-4017-B259-7B60BA55FF39@zdns.cn> Date: Mon, 13 Mar 2017 10:55:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <68C71545-48E4-40B8-91AC-88DE44C4125D@ripe.net> References: <5821A5CF-EFF8-4CE3-9AA4-CFDB9C903D63@cisco.com> <20170311222527.324125ACF21@minas-ithil.hactrn.net> <6359B4B1-478D-4017-B259-7B60BA55FF39@zdns.cn> 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: -6.0 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP 1.5 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719d65889401546bb28a809f3eb9df848ea Archived-At: Cc: Chris Morrow , "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" , "sidr-chairs@ietf.org" , Rob Austein , "sidr@ietf.org" Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-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: Mon, 13 Mar 2017 09:56:04 -0000 Hi, So, to me it seems that having new OIDs makes perfect sense as long as = there is a choice of two validation algorithms. Then having an explicit = flag set by CAs tells RPs decide which way to go. Because of this I also = do not see an immediate need to have a time line for all CAs to use the = new protocol for all its products. It's all explicit. Now, if the ambition is to have reconsidered as the only algorithm for = doing RPKI validation, then I think that the RPKI Certificate Policy OID = is enough (section 4.8.9 of RCF4587 - which delegates to section 1.2 of = RFC6484). I realise that RFC3779 section 2.3 has text on path validation = as well, but I think could can recognise that a different algorithm = should apply in the context of *RPKI* validation. If I understand Rob's concerns though he feels that this will cause = issues, and that therefore the RFC3779 OID cannot be used. Rob, is this = correct? Why can't RP/OpenSSL code just make the switch based on the CA = certificate profile? Cheers Tim > On 13 Mar 2017, at 07:16, Declan Ma wrote: >=20 > Speaking as the representative of RPSTIR team, >=20 > We are working on RPSTIR update in order to make it use the new = algorithm to do INR validation.=20 >=20 > Before RP performs the new validation process, it needs to get the = INRs from certificates. And we found a bug of OPENSSL library when = using OPENSSL to get resource sets from certificates, so we wrote our = own code to do so. =20 >=20 > It seems to me that the only concern on OID is about using OPENSSL to = get resource sets for further validation process. If the WG has decided = to deprecate the original by using the Validation Reconsidered, why = bother to bring a new OID ? >=20 > Declan(Di) Ma >=20 > ZDNS=20 >=20 >> =E5=9C=A8 2017=E5=B9=B43=E6=9C=8813=E6=97=A5=EF=BC=8C02:28=EF=BC=8CChri= s Morrow =E5=86=99=E9=81=93=EF=BC=9A >>=20 >> At Sat, 11 Mar 2017 17:25:27 -0500, >> Rob Austein wrote: >>>=20 >>> At Thu, 9 Mar 2017 18:44:58 +0000, Alvaro Retana (aretana) wrote: >>>>=20 >>>> I just finished reading this document. My review is predicated on >>>> the assumption that the intent of the WG is to define an additional >>>> validation process, and not amend/change/update/deprecate the >>>> existing one?yet, which is why there are not only process changes >>>> specified, but also new OIDs. >>>=20 >>> Alvaro, >>>=20 >>> I will let the WG chairs and authors speak to intent regarding the >>> existing validation process. >>>=20 >>=20 >> I think the intent of the WG is still to add the new validation >> process, then deprecate the original once all users are on code which >> supports the 'new' way. >>=20 >> -chris >>=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 Mon Mar 13 05:47:20 2017 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 1B3F31295DA; Mon, 13 Mar 2017 05:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLaB5_KRTufv; Mon, 13 Mar 2017 05:47:12 -0700 (PDT) Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C37371295D3; Mon, 13 Mar 2017 05:47:12 -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 khatovar.hactrn.net (Postfix) with ESMTPS id 53C22139A2; Mon, 13 Mar 2017 12:47:11 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 9BED75DCCA4; Mon, 13 Mar 2017 08:47:11 -0400 (EDT) Date: Mon, 13 Mar 2017 08:47:11 -0400 From: Rob Austein To: Declan Ma In-Reply-To: <6359B4B1-478D-4017-B259-7B60BA55FF39@zdns.cn> References: <5821A5CF-EFF8-4CE3-9AA4-CFDB9C903D63@cisco.com> <20170311222527.324125ACF21@minas-ithil.hactrn.net> <6359B4B1-478D-4017-B259-7B60BA55FF39@zdns.cn> 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: <20170313124711.9BED75DCCA4@minas-ithil.hactrn.net> Archived-At: Cc: Chris Morrow , "sidr-chairs@ietf.org" , "sidr@ietf.org" , Rob Austein , "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-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: Mon, 13 Mar 2017 12:47:15 -0000 At Mon, 13 Mar 2017 14:16:59 +0800, Declan Ma wrote: ... > It seems to me that the only concern on OID is about using OPENSSL > to get resource sets for further validation process. If the WG has > decided to deprecate the original by using the Validation > Reconsidered, why bother to bring a new OID ? Because library code which thinks it understands RFC 3779 has been shipping for a decade now, and the WG has no magic wand which can make that library code go away. It is very poor form to retroactively change the semantics of something that has already shipped, at least when there is an easy way to avoid the problem, as there is here. From nobody Mon Mar 13 06:11:59 2017 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 A6B6C1295F0; Mon, 13 Mar 2017 06:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2cOO2DySyPx; Mon, 13 Mar 2017 06:11:56 -0700 (PDT) Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A636F12940B; Mon, 13 Mar 2017 06:11:56 -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 khatovar.hactrn.net (Postfix) with ESMTPS id 08BF71398E; Mon, 13 Mar 2017 13:11:56 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id D22115DCF34; Mon, 13 Mar 2017 09:11:55 -0400 (EDT) Date: Mon, 13 Mar 2017 09:11:55 -0400 From: Rob Austein To: Tim Bruijnzeels In-Reply-To: <68C71545-48E4-40B8-91AC-88DE44C4125D@ripe.net> References: <5821A5CF-EFF8-4CE3-9AA4-CFDB9C903D63@cisco.com> <20170311222527.324125ACF21@minas-ithil.hactrn.net> <6359B4B1-478D-4017-B259-7B60BA55FF39@zdns.cn> <68C71545-48E4-40B8-91AC-88DE44C4125D@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: <20170313131155.D22115DCF34@minas-ithil.hactrn.net> Archived-At: Cc: Rob Austein , Chris Morrow , "sidr-chairs@ietf.org" , "sidr@ietf.org" , "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-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: Mon, 13 Mar 2017 13:11:57 -0000 At Mon, 13 Mar 2017 10:55:56 +0100, Tim Bruijnzeels wrote: > > So, to me it seems that having new OIDs makes perfect sense as long > as there is a choice of two validation algorithms. Then having an > explicit flag set by CAs tells RPs decide which way to go. Because > of this I also do not see an immediate need to have a time line for > all CAs to use the new protocol for all its products. It's all > explicit. > > Now, if the ambition is to have reconsidered as the only algorithm > for doing RPKI validation, then I think that the RPKI Certificate > Policy OID is enough (section 4.8.9 of RCF4587 - which delegates to > section 1.2 of RFC6484). I realise that RFC3779 section 2.3 has text > on path validation as well, but I think could can recognise that a > different algorithm should apply in the context of *RPKI* > validation. > > If I understand Rob's concerns though he feels that this will cause > issues, and that therefore the RFC3779 OID cannot be used. Rob, is > this correct? Why can't RP/OpenSSL code just make the switch based > on the CA certificate profile? The problem is that there are one or two things out there besides RPKI which use X.509, and it would be nice to avoid breaking them. The OIDs which MUST be changed are the ones labeling the extensions themselves. The semantics of X.509v3 critical extensions says, basically, "If you don't understand the meaning of this extension, you MUST consider this certificate invalid". Changing the meaning of the extensions while retaining the existing OIDs would break this: there is code out there which thinks it does understand the RFC 3779 extensions, but which would now be incorrect, because the RFC 3779 OIDs would now be used to label things that are not RFC 3779 extensions. Granted, the probability that some random X.509 CA is going to include RFC 3779 extensions in certificates for any purpose other than RPKI is fairly low, but it would be nice to avoid creating a situation in which users of such certificates got inconsistent results depending on which version of a stock library they happened to use. If this were OpenSSL doing something stupid I wouldn't care so much, but this was OpenSSL implementing an IETF proposed standard to the best of the author's ability, and you're talking about retroactively breaking that for gratuitous reasons. This is irresponsible. Don't do it. I don't understand why we're wasting time debating this (again). OIDs are cheap, and (I thought) this was a done deal. Can we please just admit that we're talking about new extensions with new semantics which borrow syntax from the existing extensions, label them accordingly, and move on? From nobody Mon Mar 13 07:16:05 2017 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 98DB5129687; Mon, 13 Mar 2017 07:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SatFj9lioNlK; Mon, 13 Mar 2017 07:16:02 -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 33465129642; Mon, 13 Mar 2017 07:16:01 -0700 (PDT) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id DFF5F3FE97; Mon, 13 Mar 2017 14:15:59 +0000 (UTC) Received: from donkey.her.corp.google.com.ops-netman.net (unknown [104.132.12.94]) (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 9C8D45C95879; Mon, 13 Mar 2017 14:15:59 +0000 (UTC) Date: Mon, 13 Mar 2017 10:15:58 -0400 Message-ID: From: Chris Morrow To: Rob Austein In-Reply-To: <20170313124711.9BED75DCCA4@minas-ithil.hactrn.net> References: <5821A5CF-EFF8-4CE3-9AA4-CFDB9C903D63@cisco.com> <20170311222527.324125ACF21@minas-ithil.hactrn.net> <6359B4B1-478D-4017-B259-7B60BA55FF39@zdns.cn> <20170313124711.9BED75DCCA4@minas-ithil.hactrn.net> 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: Cc: Chris Morrow , "sidr@ietf.org" , "sidr-chairs@ietf.org" , "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-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: Mon, 13 Mar 2017 14:16:03 -0000 At Mon, 13 Mar 2017 08:47:11 -0400, Rob Austein wrote: > > At Mon, 13 Mar 2017 14:16:59 +0800, Declan Ma wrote: > ... > > It seems to me that the only concern on OID is about using OPENSSL > > to get resource sets for further validation process. If the WG has > > decided to deprecate the original by using the Validation > > Reconsidered, why bother to bring a new OID ? > > Because library code which thinks it understands RFC 3779 has been > shipping for a decade now, and the WG has no magic wand which can make > that library code go away. It is very poor form to retroactively > change the semantics of something that has already shipped, at least > when there is an easy way to avoid the problem, as there is here. new oid's seemed reasonable to me... as a chemical engineer playing security engineer on network things. -chris From nobody Mon Mar 13 07:21:12 2017 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 DA5A9129642; Mon, 13 Mar 2017 07:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3mhl0fl9Cib; Mon, 13 Mar 2017 07:21:09 -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 DDF7A12966D; Mon, 13 Mar 2017 07:21:08 -0700 (PDT) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id F1FE53FE97; Mon, 13 Mar 2017 14:21:07 +0000 (UTC) Received: from donkey.her.corp.google.com.ops-netman.net (unknown [104.132.12.94]) (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 762D45C962B6; Mon, 13 Mar 2017 14:21:07 +0000 (UTC) Date: Mon, 13 Mar 2017 10:21:06 -0400 Message-ID: From: Chris Morrow To: Tim Bruijnzeels In-Reply-To: <68C71545-48E4-40B8-91AC-88DE44C4125D@ripe.net> References: <5821A5CF-EFF8-4CE3-9AA4-CFDB9C903D63@cisco.com> <20170311222527.324125ACF21@minas-ithil.hactrn.net> <6359B4B1-478D-4017-B259-7B60BA55FF39@zdns.cn> <68C71545-48E4-40B8-91AC-88DE44C4125D@ripe.net> 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: Cc: Rob Austein , Chris Morrow , "sidr-chairs@ietf.org" , "sidr@ietf.org" , "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-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: Mon, 13 Mar 2017 14:21:10 -0000 At Mon, 13 Mar 2017 10:55:56 +0100, Tim Bruijnzeels wrote: > > Hi, > > So, to me it seems that having new OIDs makes perfect sense as long as > there is a choice of two validation algorithms. Then having an > explicit flag set by CAs tells RPs decide which way to go. Because of > this I also do not see an immediate need to have a time line for all > CAs to use the new protocol for all its products. It's all explicit. I was thinking that today code for CA/RP doesn't understand (mostly) the 'new' way. Tomorrow 'some' of the CA/RP world will shift to being able to do both ways. So, until all of the CA/RP software is updated and deployed, CAs can't make new OID/validation content and expect them to be respected. I expect a transition to the new validation algorithm (for even a single CA) will have to wait until this point in time. Once there are new and old validation algorithm data available a CA probably should flush the 'old' and publish the 'new'. I think Tim's correct that an RP can see: "Oh, new OID here, run new algorithm!" and be perfectly fine... but, having 2 versions of the validation algorithm and seeing published data for both OID sets for a single prefix/publication bundle will be very problematic. There's no proscribed 'prefer new over old' action here, so a CA must only publish one version of their data. -chris From nobody Mon Mar 13 07:25:31 2017 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 33ACB12969B; Mon, 13 Mar 2017 07:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSdRO42w7H9S; Mon, 13 Mar 2017 07:25:23 -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 1D72812969A; Mon, 13 Mar 2017 07:25:22 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from ) id 1cnQuS-0000sr-OM; Mon, 13 Mar 2017 15:25:18 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-195.ripe.net) by nene.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1cnQuS-00071W-IX; Mon, 13 Mar 2017 15:25:16 +0100 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: <20170313131155.D22115DCF34@minas-ithil.hactrn.net> Date: Mon, 13 Mar 2017 15:25:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4E57BAB1-8241-495E-A201-D785FFF3AEC9@ripe.net> References: <5821A5CF-EFF8-4CE3-9AA4-CFDB9C903D63@cisco.com> <20170311222527.324125ACF21@minas-ithil.hactrn.net> <6359B4B1-478D-4017-B259-7B60BA55FF39@zdns.cn> <68C71545-48E4-40B8-91AC-88DE44C4125D@ripe.net> <20170313131155.D22115DCF34@minas-ithil.hactrn.net> To: Rob Austein X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------ X-RIPE-Spam-Report: Spam Total Points: -6.0 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP 1.5 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071904ba42f6741bbe4d985c57319b0f9116 Archived-At: Cc: Chris Morrow , "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" , "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-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: Mon, 13 Mar 2017 14:25:24 -0000 Hi Rob, all, > On 13 Mar 2017, at 14:11, Rob Austein wrote: >=20 > At Mon, 13 Mar 2017 10:55:56 +0100, Tim Bruijnzeels wrote: >>=20 >> So, to me it seems that having new OIDs makes perfect sense as long >> as there is a choice of two validation algorithms. Then having an >> explicit flag set by CAs tells RPs decide which way to go. Because >> of this I also do not see an immediate need to have a time line for >> all CAs to use the new protocol for all its products. It's all >> explicit. >>=20 >> Now, if the ambition is to have reconsidered as the only algorithm >> for doing RPKI validation, then I think that the RPKI Certificate >> Policy OID is enough (section 4.8.9 of RCF4587 - which delegates to >> section 1.2 of RFC6484). I realise that RFC3779 section 2.3 has text >> on path validation as well, but I think could can recognise that a >> different algorithm should apply in the context of *RPKI* >> validation. >>=20 >> If I understand Rob's concerns though he feels that this will cause >> issues, and that therefore the RFC3779 OID cannot be used. Rob, is >> this correct? Why can't RP/OpenSSL code just make the switch based >> on the CA certificate profile? >=20 > The problem is that there are one or two things out there besides RPKI > which use X.509, and it would be nice to avoid breaking them. I understand that. I meant to say that the switch should be based on the = RPKI CA certificate policy qualifier. That is specific to RPKI so, other = applications would not break. Non-RPKI use of RFC3779, would not have this same OID, and therefore = would still have the path validation from section 2.3 in RFC3779. > The OIDs which MUST be changed are the ones labeling the extensions > themselves. The semantics of X.509v3 critical extensions says, > basically, "If you don't understand the meaning of this extension, you > MUST consider this certificate invalid". Changing the meaning of the > extensions while retaining the existing OIDs would break this: there > is code out there which thinks it does understand the RFC 3779 > extensions, but which would now be incorrect, because the RFC 3779 > OIDs would now be used to label things that are not RFC 3779 > extensions. >=20 > Granted, the probability that some random X.509 CA is going to include > RFC 3779 extensions in certificates for any purpose other than RPKI is > fairly low, but it would be nice to avoid creating a situation in > which users of such certificates got inconsistent results depending on > which version of a stock library they happened to use. If this were > OpenSSL doing something stupid I wouldn't care so much, but this was > OpenSSL implementing an IETF proposed standard to the best of the > author's ability, and you're talking about retroactively breaking that > for gratuitous reasons. This is irresponsible. Don't do it. >=20 > I don't understand why we're wasting time debating this (again). OIDs > are cheap, and (I thought) this was a done deal. Can we please just > admit that we're talking about new extensions with new semantics which > borrow syntax from the existing extensions, label them accordingly, > and move on? The reason why I keep talking about this, is because other people = indicated that it could be desirable that validation reconsidered is not = a choice (that would need flagging, so OIDs are appropriate) - but = should become the default. In that case it's much simpler to have a switch on the unique RPKI CP = OID from section 1.2 of RFC6484.=20 The proposed OIDs itself are cheap, and the code changes are simple. The = difficulty is that we need a deployment plan: 1=3D RPs MUST support new OIDs, before 2=3D CAs MAY use new OIDs and an open question still is whether there needs to be a later 3=3D CAs MUST use new OIDs and RPs MUST reject old OIDs Step 2 has operational impact if operators did not upgrade their RP = software. Step 3 has operational impact in case a CA cannot re-issue = certain objects. If we need to end up in a place where 'validation reconsidered' is the = default, then these operational impacts can be minimised. It would boil = down to deciding a date X by which RPs MUST use reconsidered when they = encounter the RPKI CP OID, and a date Y (before X) that these should be = available. Operators that don't upgrade before date X could find that = they consider certain objects invalid, that would be (partially) valid. In any case, I know that you know more about how the openssl code works. = So if there is a reason why the switch cannot work on the RPKI CP OID = without affecting non-RPKI use, or if there is a strong reason for = having both algorithms alongside each other, than I am (still) open to = the OIDs that I painstakingly added to the document. Tim =20 From nobody Mon Mar 13 08:17:03 2017 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 438281294F9; Mon, 13 Mar 2017 08:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opyiu0iw_c13; Mon, 13 Mar 2017 08:17:01 -0700 (PDT) Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F1D51294B1; Mon, 13 Mar 2017 08:16:58 -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 khatovar.hactrn.net (Postfix) with ESMTPS id 0F0B0139A2; Mon, 13 Mar 2017 15:16:57 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 281B65DDF63; Mon, 13 Mar 2017 11:16:57 -0400 (EDT) Date: Mon, 13 Mar 2017 11:16:57 -0400 From: Rob Austein To: Tim Bruijnzeels In-Reply-To: <4E57BAB1-8241-495E-A201-D785FFF3AEC9@ripe.net> References: <5821A5CF-EFF8-4CE3-9AA4-CFDB9C903D63@cisco.com> <20170311222527.324125ACF21@minas-ithil.hactrn.net> <6359B4B1-478D-4017-B259-7B60BA55FF39@zdns.cn> <68C71545-48E4-40B8-91AC-88DE44C4125D@ripe.net> <20170313131155.D22115DCF34@minas-ithil.hactrn.net> <4E57BAB1-8241-495E-A201-D785FFF3AEC9@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: <20170313151657.281B65DDF63@minas-ithil.hactrn.net> Archived-At: Cc: "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" , Chris Morrow , "sidr-chairs@ietf.org" , "sidr@ietf.org" , Rob Austein Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-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: Mon, 13 Mar 2017 15:17:02 -0000 At Mon, 13 Mar 2017 15:25:13 +0100, Tim Bruijnzeels wrote: > > I understand that. I meant to say that the switch should be based on > the RPKI CA certificate policy qualifier. That is specific to RPKI > so, other applications would not break. The problem is that you're talking about applications, while I'm talking about libraries. > Non-RPKI use of RFC3779, would not have this same OID, and therefore > would still have the path validation from section 2.3 in RFC3779. You are making assumptions about how the library code works. As it happens, those assumptions are incorrect for the OpenSSL case. > The reason why I keep talking about this, is because other people > indicated that it could be desirable that validation reconsidered is > not a choice (that would need flagging, so OIDs are appropriate) - > but should become the default. > > In that case it's much simpler to have a switch on the unique RPKI > CP OID from section 1.2 of RFC6484. I disagree. > The proposed OIDs itself are cheap, and the code changes are > simple. The difficulty is that we need a deployment plan: > > 1= RPs MUST support new OIDs, before > 2= CAs MAY use new OIDs > > and an open question still is whether there needs to be a later > 3= CAs MUST use new OIDs and RPs MUST reject old OIDs > > Step 2 has operational impact if operators did not upgrade their RP > software. Step 3 has operational impact in case a CA cannot re-issue > certain objects. Old-policy-OID requires old-extension-OIDs. New-policy-OID requires new-extension-OIDs. Simple, unambiguous, no magic required. > If we need to end up in a place where 'validation reconsidered' is > the default, then these operational impacts can be minimised. Hiding the change does not solve the problem, it just makes it harder to debug when it breaks. > In any case, I know that you know more about how the openssl code > works. So if there is a reason why the switch cannot work on the > RPKI CP OID without affecting non-RPKI use, or if there is a strong > reason for having both algorithms alongside each other, than I am > (still) open to the OIDs that I painstakingly added to the > document. That's what I've been trying to tell you. At least in OpenSSL's case, certificate extensions are processed down in the guts of the library. Certificates with critical extensions which do not pass validation are rejected by the library, regardless of any policy setting. Policy OID constraints require cooperation by the application. So while your scheme sort of works for RPKI-aware applications which enforce an RPKI policy OID, it does not work for non-RPKI applications which encounter RFC 3997 extensions: you will get the same certificate looking valid to one validation engine and invalid to another, because the same OIDs trigger different processing in the two engines. Don't go there. Please, don't go there. This is dangerous. Please just keep the new separate extension OIDs and stop trying to pretend that we can sweep the flag days for an incompatible change under the rug. We can't. Accept that and move on. From nobody Mon Mar 13 08:44:52 2017 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 669A41296F7; Mon, 13 Mar 2017 08:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 IWmQeABqQ4S8; Mon, 13 Mar 2017 08:44:49 -0700 (PDT) Received: from mail.lacnic.net.uy (hermes.lacnic.net.uy [IPv6:2001:13c7:7001:4000::8]) by ietfa.amsl.com (Postfix) with ESMTP id C356312962E; Mon, 13 Mar 2017 08:44:48 -0700 (PDT) Received: from hermes.lacnic.net.uy (localhost [127.0.0.1]) by mail.lacnic.net.uy (Postfix) with ESMTP id 070C016B414BF; Mon, 13 Mar 2017 12:44:46 -0300 (UYT) X-Virus-Scanned: amavisd-new at lacnic.net.uy Received: from mail.lacnic.net.uy ([127.0.0.1]) by hermes.lacnic.net.uy (mail.lacnic.net.uy [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSIeOfLzeCXg; Mon, 13 Mar 2017 12:44:45 -0300 (UYT) Received: from [200.7.87.71] (unknown [IPv6:2001:13c7:7001:7000:3418:572e:53b8:3d0e]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lacnic.net.uy (Postfix) with ESMTPSA id A9B6416B414BE; Mon, 13 Mar 2017 12:44:45 -0300 (UYT) From: "Carlos M. Martinez" To: "Rob Austein" Date: Mon, 13 Mar 2017 12:44:45 -0300 Message-ID: <0C92FF0E-E19E-4CA0-967A-D35B17AD203B@lacnic.net> In-Reply-To: <20170313151657.281B65DDF63@minas-ithil.hactrn.net> References: <5821A5CF-EFF8-4CE3-9AA4-CFDB9C903D63@cisco.com> <20170311222527.324125ACF21@minas-ithil.hactrn.net> <6359B4B1-478D-4017-B259-7B60BA55FF39@zdns.cn> <68C71545-48E4-40B8-91AC-88DE44C4125D@ripe.net> <20170313131155.D22115DCF34@minas-ithil.hactrn.net> <4E57BAB1-8241-495E-A201-D785FFF3AEC9@ripe.net> <20170313151657.281B65DDF63@minas-ithil.hactrn.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown X-Mailer: MailMate (1.9.6r5347) Archived-At: Cc: "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" , Chris Morrow , "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-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: Mon, 13 Mar 2017 15:44:50 -0000 Rob, On 13 Mar 2017, at 12:16, Rob Austein wrote: > You are making assumptions about how the library code works. As it > happens, those assumptions are incorrect for the OpenSSL case. can you expand on this ? I think if you help us on this front a lot of the concerns and misunderstandings will be sorted out. Best regards, -Carlos From nobody Mon Mar 13 14:47:49 2017 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 0BDEF129B80; Mon, 13 Mar 2017 14:47:48 -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.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148944166803.20284.8298077648406334155@ietfa.amsl.com> Date: Mon, 13 Mar 2017 14:47:48 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-slurm-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: Mon, 13 Mar 2017 21:47:48 -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 : Simplified Local internet nUmber Resource Management with the RPKI Authors : David Mandelberg Di Ma Tim Bruijnzeels Filename : draft-ietf-sidr-slurm-04.txt Pages : 17 Date : 2017-03-13 Abstract: The Resource Public Key Infrastructure (RPKI) is a global authorization infrastructure that allows the holder of Internet Number Resources (INRs) to make verifiable statements about those resources. Network operators, e.g., Internet Service Providers (ISPs), can use the RPKI to validate BGP route origination assertions. In the future, ISPs also will be able to use the RPKI to validate the path of a BGP route. However, ISPs may want to establish a local view of the RPKI to control its own network while making use of RPKI data. The mechanisms described in this document provide a simple way to enable INR holders to establish a local, customized view of the RPKI, overriding global RPKI repository data as needed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-slurm-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-slurm-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 Mon Mar 13 15:24:33 2017 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 E316D1293FB; Mon, 13 Mar 2017 15:24:27 -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.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148944386789.20264.11232772923431620349@ietfa.amsl.com> Date: Mon, 13 Mar 2017 15:24:27 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-delta-protocol-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, 13 Mar 2017 22:24:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : RPKI Repository Delta Protocol (RRDP) Authors : Tim Bruijnzeels Oleg Muravskiy Bryan Weber Rob Austein Filename : draft-ietf-sidr-delta-protocol-08.txt Pages : 23 Date : 2017-03-13 Abstract: In the Resource Public Key Infrastructure (RPKI), Certificate Authorities publish certificates, including end entity certificates, Certificate Revocation Lists (CRL), and RPKI signed objects to repositories. Relying Parties retrieve the published information from those repositories. This document specifies a new RPKI Repository Delta Protocol (RRDP) for this purpose. RRDP was specifically designed for scaling. It relies on a notification file which lists the current snapshot and delta files that can be retrieved using HTTP over TLS (HTTPS), and enables to use of CDNs or other caching infrastructure for the retrieval of these files. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-delta-protocol-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 Mon Mar 13 23:28:45 2017 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 DA7DC1294EA for ; Mon, 13 Mar 2017 23:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKF3oLjdbtdr for ; Mon, 13 Mar 2017 23:28:42 -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 C0D971293EC for ; Mon, 13 Mar 2017 23:28:41 -0700 (PDT) X-TM-DID: df6dfe0c231fb932f029bb3603368d79 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Declan Ma In-Reply-To: <0C92FF0E-E19E-4CA0-967A-D35B17AD203B@lacnic.net> Date: Tue, 14 Mar 2017 14:23:01 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <35D7A05D-153E-4A32-9DB4-1399668403BD@zdns.cn> References: <5821A5CF-EFF8-4CE3-9AA4-CFDB9C903D63@cisco.com> <20170311222527.324125ACF21@minas-ithil.hactrn.net> <6359B4B1-478D-4017-B259-7B60BA55FF39@zdns.cn> <68C71545-48E4-40B8-91AC-88DE44C4125D@ripe.net> <20170313131155.D22115DCF34@minas-ithil.hactrn.net> <4E57BAB1-8241-495E-A201-D785FFF3AEC9@ripe.net> <20170313151657.281B65DDF63@minas-ithil.hactrn.net> <0C92FF0E-E19E-4CA0-967A-D35B17AD203B@lacnic.net> To: "Carlos M. Martinez" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Chris Morrow , "sidr-chairs@ietf.org" , "sidr@ietf.org" , Rob Austein , "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-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: Tue, 14 Mar 2017 06:28:43 -0000 +1 As far as we programmed to support Validation Reconsidered by using = OPENSSL , a bug was found. For instance, if one calls v3_addr_get_range() in OPENSSEL library to = get INR 1::/16 from a RC, one will get a right MAX but a wrong MIN NULL, = which should have been 1:: . Di > =D4=DA 2017=C4=EA3=D4=C213=C8=D5=A3=AC23:44=A3=ACCarlos M. Martinez = =D0=B4=B5=C0=A3=BA >=20 > Rob, >=20 > On 13 Mar 2017, at 12:16, Rob Austein wrote: >=20 >> You are making assumptions about how the library code works. As it >> happens, those assumptions are incorrect for the OpenSSL case. >=20 > can you expand on this ? I think if you help us on this front a lot of = the concerns and misunderstandings will be sorted out. >=20 > Best regards, >=20 > -Carlos >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Tue Mar 14 06:06:54 2017 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 F31B612950E; Tue, 14 Mar 2017 06:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8nL1IsKkty4; Tue, 14 Mar 2017 06:06:51 -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 A9E501294FA; Tue, 14 Mar 2017 06:06:51 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from ) id 1cnmA5-000B2j-AW; Tue, 14 Mar 2017 14:06:50 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-166.ripe.net) by titi.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1cnmA5-0008TV-5h; Tue, 14 Mar 2017 14:06:49 +0100 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: <148944386789.20264.11232772923431620349@ietfa.amsl.com> Date: Tue, 14 Mar 2017 14:06:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <69A47DB9-74F4-4E9F-9FEC-45F781D82B99@ripe.net> References: <148944386789.20264.11232772923431620349@ietfa.amsl.com> To: internet-drafts@ietf.org X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------ X-RIPE-Spam-Report: Spam Total Points: -6.0 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP 1.5 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4971] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719099d849f6acc480ff336dcec6784439f Archived-At: Cc: sidr@ietf.org, i-d-announce@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-delta-protocol-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: Tue, 14 Mar 2017 13:06:53 -0000 Hi, This version includes the feedback received during IESG Evaluation. I = would like to thank everyone involved for helping to review and improve = this. The overall protocol didn't change, but many clarifications and = readability improvements were added. Please let us know if you have any comments/concerns/questions about = this update. Thanks Tim =20 > On 13 Mar 2017, at 23:24, 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 : RPKI Repository Delta Protocol (RRDP) > Authors : Tim Bruijnzeels > Oleg Muravskiy > Bryan Weber > Rob Austein > Filename : draft-ietf-sidr-delta-protocol-08.txt > Pages : 23 > Date : 2017-03-13 >=20 > Abstract: > In the Resource Public Key Infrastructure (RPKI), Certificate > Authorities publish certificates, including end entity certificates, > Certificate Revocation Lists (CRL), and RPKI signed objects to > repositories. Relying Parties retrieve the published information > from those repositories. This document specifies a new RPKI > Repository Delta Protocol (RRDP) for this purpose. RRDP was > specifically designed for scaling. It relies on a notification file > which lists the current snapshot and delta files that can be > retrieved using HTTP over TLS (HTTPS), and enables to use of CDNs or > other caching infrastructure for the retrieval of these files. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-08 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-delta-protocol-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 Tue Mar 14 06:35:17 2017 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 A451A128874; Tue, 14 Mar 2017 06:35:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148949851566.12665.13537537690310962601.idtracker@ietfa.amsl.com> Date: Tue, 14 Mar 2017 06:35:15 -0700 Archived-At: Cc: draft-ietf-sidr-delta-protocol@ietf.org, sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org Subject: [sidr] Alexey Melnikov's Yes on draft-ietf-sidr-delta-protocol-08: (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: Tue, 14 Mar 2017 13:35:16 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-sidr-delta-protocol-08: Yes 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-delta-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my DISCUSS. From nobody Tue Mar 14 09:26:47 2017 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 F0E37129480; Tue, 14 Mar 2017 09:26:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , morrowc@ops-netman.net, Chris Morrow , sidr-chairs@ietf.org, sidr@ietf.org, draft-ietf-sidr-delta-protocol@ietf.org, aretana@cisco.com, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <148950880198.30341.8847132518744488349.idtracker@ietfa.amsl.com> Date: Tue, 14 Mar 2017 09:26:41 -0700 Archived-At: Subject: [sidr] Protocol Action: 'RPKI Repository Delta Protocol (RRDP)' to Proposed Standard (draft-ietf-sidr-delta-protocol-08.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.21 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 16:26:42 -0000 The IESG has approved the following document: - 'RPKI Repository Delta Protocol (RRDP)' (draft-ietf-sidr-delta-protocol-08.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-delta-protocol/ Technical Summary In the Resource Public Key Infrastructure (RPKI), certificate authorities publish certificates, including end entity certificates, Certificate Revocation Lists (CRL), and RPKI signed objects to repositories. Relying Parties (RP) retrieve the published information from those repositories. This document specifies a protocol which provides relying parties with a mechanism to query a repository for incremental updates using the HTTP Over TLS (HTTPS) [RFC2818] protocol, thus enabling the RP to keep its state in sync with the repository using a secure transport channel. This document updates [RFC6480], [RFC6481], and [RFC7730]. Working Group Summary The WG process was as most SIDR process goes... long, but generally good in the end. Document Quality There are 2 different protocol implementations to date. One from RipeLabs, one from Dragon Research Group. Personnel Shepherd: morrowc@ops-netman.net - Chris Morrow AD: Alvaro Retana - aretana@cisco.com From nobody Tue Mar 14 14:31:03 2017 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 7B589129AD0 for ; Tue, 14 Mar 2017 14:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r34xFYO6K2iW for ; Tue, 14 Mar 2017 14:31:01 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75ABE126DC2 for ; Tue, 14 Mar 2017 14:31:01 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cnu1y-0007Cy-W0; Tue, 14 Mar 2017 21:30:59 +0000 Date: Wed, 15 Mar 2017 06:30:57 +0900 Message-ID: From: Randy Bush To: Steve KENT Cc: sidr wg list In-Reply-To: <397fc99b27b943a283d8ea54b036ebe3@CY1PR0601MB023.008f.mgd2.msft.net> References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [sidr] BGPsec draft and extended messages X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 21:31:02 -0000 [ moved to wg list ] > I think it makes sense to omit the extended message feature, given the > use of ECDSA P-256. unfortunately, existing bgp data and simple arithmetic would seem to say otherwise. randy From nobody Tue Mar 14 15:26:54 2017 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 730E6129496; Tue, 14 Mar 2017 15:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezoEbERQjQvO; Tue, 14 Mar 2017 15:26:50 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0102.outbound.protection.outlook.com [23.103.201.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D1A9129BB3; Tue, 14 Mar 2017 15:26:50 -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=DZs2Yh0mnvwhNvj0Q1EXuJIp6dWJM/DhUnrlLydUyyc=; b=R7xwG9YGqnzbSZF7I74Jea6XNYbl7IGhBLHU3EEaRb+cJudgZJU+Ty4EUpZqSQ/BpGTrxHPpgUsBVHIq48zcChdLh0NPWwjLcNbvkxQW0g6MvWeKXUloUD08QeHU40Koof0Vq3DwzIeL/hImoTvTJ4HND0pLxAVDBOmWntlYD4w= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0448.namprd09.prod.outlook.com (10.161.252.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Tue, 14 Mar 2017 22:26:46 +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.0961.021; Tue, 14 Mar 2017 22:26:46 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Randy Bush , Steve KENT CC: sidr wg list , Alvaro Retana , "Matthias Waehlisch" , "sidr-chairs@ietf.org" , Sean Turner , "sidrops@ietf.org" Thread-Topic: [sidr] BGPsec draft and extended messages Thread-Index: AdKcN8SBuyxP2TUmTMSCIN0IJlVFkAAEOhsAACVRtkMAChNseAABALyAAACP7LI= Date: Tue, 14 Mar 2017 22:26:46 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.220.93] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0448; 7:zovzPaFbPwAdivYBUBWnTywijaqAHJ7S91UwAzduKhEM3pOxFnjQz+nRg8+VJVLSOhOFsu/DmXwcvzm/Q48nBhQM5nAZDYzG46C37rUG5hVO2xoYYnVB4V6sq54CkSndgU4PVS12h5cXxsOqvF8Ai4HtSCNo7CtNL6NahT2IxZmLcXB+7aIA9SeekJlj1zmGpME2Ntw8MF7sS7EZoPcrjReDmTDkYljHQ+Tk9k/btVLoObhiU0lpO0zFCUDstk0MIYBVbsZ1Nj7JK/A4D/rpzO8q1xVx6EZh6vhwjI3DCnoGqzm65TpPF6hpjipqhTAh0m91Wm1UE+VNiDsvGGdXAw== x-ms-office365-filtering-correlation-id: 85cadefb-1c6a-4fe1-4a3e-08d46b293375 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:DM2PR09MB0448; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123558025)(20161123564025)(20161123560025)(6072148)(6042181); SRVR:DM2PR09MB0448; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0448; x-forefront-prvs: 02462830BE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51414003)(25786008)(966004)(6306002)(7696004)(6246003)(6606003)(99286003)(54906002)(33656002)(55016002)(9686003)(5660300001)(4326008)(54896002)(561944003)(53936002)(74316002)(7736002)(122556002)(2900100001)(10710500007)(38730400002)(77096006)(8936002)(8676002)(2906002)(2950100002)(81166006)(53546007)(3846002)(54356999)(6116002)(76176999)(3280700002)(6506006)(19627405001)(50986999)(15650500001)(7110500001)(2420400007)(229853002)(3660700001)(189998001)(66066001)(102836003)(6436002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0448; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR09MB0446AA8F2902D240F99A861C84240DM2PR09MB0446namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2017 22:26:46.5207 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0448 Archived-At: Subject: Re: [sidr] BGPsec draft and extended messages X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 22:26:52 -0000 --_000_DM2PR09MB0446AA8F2902D240F99A861C84240DM2PR09MB0446namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Just so that everyone on the list is aware of the background info.... I sent this suggestion (email copied below) to Alvaro. Alvaro replied to me in detail. I would request him to post that response on this list as well so everyone has the full context. Alvaro asked me to invite comments on the WG list. Please read the proposal below, and share your thoughts. Thanks. Sriram ________________________________________ From: Sriram, Kotikalapudi (Fed) Sent: Monday, March 13, 2017 4:57 PM To: Alvaro Retana (aretana) Subject: BGPsec draft and extended messages Hi Alvaro, Just trying to think aloud about a possible way to have wording in the BGPs= ec draft that does not require normative dependence on the extended message= draft. I think it can be done in a rational way as follows. Please feel fr= ee to shoot this down if the rationale seems weak. Currently the draft reads in Section 2.2: Note that BGPsec update messages can be quite large, therefore any BGPsec speaker announcing the capability to receive BGPsec messages SHOULD also announce support for the capability to receive BGP extended messages [I-D.ietf-idr-bgp-extended-messages]. Please see related operational guidance in Section 7. Suggestion: Remove the above paragraph from Section 2.2 and add the followi= ng in Section 4.2 (Constructing the BGPsec_Path Attribute): BGPsec update size is subject to a maximum BGP update size. The maximum siz= e at present is 4096 bytes [RFC4271], and it may be extended to a larger si= ze in the future. If the sending router determines that adding its Secure_P= ath Segment and Signature Segment causes the BGPsec update to exceed the ma= ximum size, then it will convert the BGPsec update to an unsigned tradition= al BGP update [using the procedure in Section 4.4] and send the unsigned up= date. (Note: Please see related discussion in Section 7.) Then the existing discussion paragraph in Section 7 (operations) related to= extended messages can be replaced with the following: BGPsec update size is subject to =93current=94 maximum BGP update size, not= ing that =93current=94 maximum size may increase in the future. The maximum= size at present is 4096 bytes [RFC4271], and it is expected be extended to= a larger size in the future [I-D.ietf-idr-bgp-extended-messages]. Given th= e ECDSA with curve P-256 for the signature algorithm [I-D.ietf-sidr-bgpsec-= algs], each AS in an AS path adds approximately 100 bytes of BGPsec data (i= .e. Secure_Path Segment and Signature Segment). Hence, the maximum size of = 4096 bytes is exceeded only if there are 40 or more distinct ASes in the AS= path. (Note: AS prepends are compressed out with the use of pCount as desc= ribed in Section 3.1.) Currently, the average and maximum AS path lengths = in the Internet are 3.8 and 14, respectively, and have remained in this bal= l park for many years [Huston]. [Huston] G. Huston, =93AS6447 BGP Routing Table Analysis Report,=94 March 1= 3, 2017. http://bgp.potaroo.net/as6447/ (BTW, the above wording perhaps also makes it independent of the form exten= ded messages takes eventually =96 separate RFC that updates BGP-4 or as def= ault in BGP-5 OPEN(?) etc. ) I look forward to hearing your thoughts on this. Thank you. Sriram --_000_DM2PR09MB0446AA8F2902D240F99A861C84240DM2PR09MB0446namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Just so that everyone on the list is aware of the background info..= .. 

I sent this suggestion (email copied below) to Alvaro.

Alvaro replied to me in detail. 

I would request him to post that response on this list as well

so everyone has the full context.

Alvaro asked me to invite comments on the WG list. 


Please read the proposal below, and share your thoughts. Thanks.


Sriram 

________________________________________

From: Sriram, Kotikalapudi (Fed)

Sent: Monday, March 13, 2017 4:57 PM

To: Alvaro Retana (aretana)

Subject: BGPsec draft and extended messages

Hi Alvaro,

Just trying to think aloud about a possible way to have wording in the B= GPsec draft that does not require normative dependence on the extended mess= age draft. I think it can be done in a rational way as follows. Please feel= free to shoot this down if the rationale seems weak.

Currently the draft reads in Section 2.2:

   Note that BGPsec update messages can be quite large, theref= ore any

   BGPsec speaker announcing the capability to receive BGPsec = messages

   SHOULD also announce support for the capability to receive = BGP

   extended messages [I-D.ietf-idr-bgp-extended-messages].&nbs= p; Please see

   related operational guidance in Section 7.

Suggestion: Remove the above paragraph from Section 2.2 and add the foll= owing in Section 4.2 (Constructing the BGPsec_Path Attribute):


BGPsec update size is subject to a maximum BGP update size. The maximum = size at present is 4096 bytes [RFC4271], and it may be extended to a larger= size in the future. If the sending router determines that adding its Secur= e_Path Segment and Signature Segment causes the BGPsec update to exceed the maximum size, then it will convert = the BGPsec update to an unsigned traditional BGP update [using the procedur= e in Section 4.4] and send the unsigned update. (Note: Please see related d= iscussion in Section 7.)


Then the existing discussion paragraph in Section 7 (operations) related= to extended messages can be replaced with the following:


BGPsec update size is subject to =93current=94 maximum BGP update size, = noting that =93current=94 maximum size may increase in the future. The maxi= mum size at present is 4096 bytes [RFC4271], and it is expected be extended= to a larger size in the future [I-D.ietf-idr-bgp-extended-messages]. Given the ECDSA with curve P-256 for the signature algorithm [I-D.ietf-sid= r-bgpsec-algs], each AS in an AS path adds approximately 100 bytes of BGPse= c data (i.e. Secure_Path Segment and Signature Segment). Hence, the maximum= size of 4096 bytes is exceeded only if there are 40 or more distinct ASes in the AS path. (Note: AS prepe= nds are compressed out with the use of pCount as described in Section 3.1.)=   Currently, the average and maximum AS path lengths in the Internet a= re 3.8 and 14, respectively, and have remained in this ball park for many years [Huston].


[Huston] G. Huston, =93AS6447 BGP Routing Table Analysis Report,=94 Marc= h 13, 2017.  http://bgp.potaroo.net/as6447/


(BTW, the above wording perhaps also makes it independent of the form ex= tended messages takes eventually =96 separate RFC that updates BGP-4 or as = default in BGP-5 OPEN(?) etc. )

I look forward to hearing your thoughts on this. Thank you.


Sriram

--_000_DM2PR09MB0446AA8F2902D240F99A861C84240DM2PR09MB0446namp_-- From nobody Tue Mar 14 19:58:37 2017 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 5FBD3131874; Tue, 14 Mar 2017 19:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrtlrPsIre60; Tue, 14 Mar 2017 19:58:34 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0127.outbound.protection.outlook.com [23.103.200.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D22C4131873; Tue, 14 Mar 2017 19:58:33 -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=SbJlltqYYq1ICWwk5nWX0++2iEeqAtJmOEZSBm1el5k=; b=lwQl6hZL53zLrnoAVThw9F4TMUSRrPkjKz9B/BLahORDL0VC5gwY9nd1NWRapVMf1jOxTPLiRvqw9JcNqpG9DFrFRLrCrsgVuJyQwWn1VfPAxBTILOFXNKPvUg3N19ZJXUCGc85ficMGLrfgZw/EAbBsrwWmHJilM5gS9so/swk= 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 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Wed, 15 Mar 2017 02:58:31 +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.0961.021; Wed, 15 Mar 2017 02:58:31 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Randy Bush , Steve KENT CC: sidr wg list , "sidrops@ietf.org" , Alvaro Retana , "keyur@arrcus.com" Thread-Topic: [sidr] BGPsec draft and extended messages Thread-Index: AdKcN8SBuyxP2TUmTMSCIN0IJlVFkAAEOhsAACVRtkMAChNseAABALyAAAqiPU8= Date: Wed, 15 Mar 2017 02:58:31 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.220.93] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0446; 7:wpBwLRdISn9GvxzOmyO43Dgul/Dn4PEbW7l+2W64azqv5h6OfZh7UI8HACNgTb4THLYMEdlnAV5m+EglJ9ndo+TklePQLGLUk1wFhhWz2UgJ2KHkezD36ra/euokwvwYJSpWhmGEE/e4oP7OFSfLGGL/rsjevTgukMK6lPZQZjNHuKQ07+hmGHCZs5s+R3m44NnYGeQzVgyUMVg5NDwVSoA56qcO4rpRWaf6XuGv5OKo6oPslNtPTmQwR8Tod+JvwBdVKvOLMBfG/q/nCLZMjXgzf+8MrSvZlk+eWdajtitZEjXCC+PTjpvA9B8Htxr5kae/BLMDjXsmX2LuF50Ckg== x-ms-office365-filtering-correlation-id: 02c1cdce-fd75-4208-5110-08d46b4f2a0c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:DM2PR09MB0446; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123558025)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:DM2PR09MB0446; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0446; x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(39410400002)(39850400002)(39450400003)(39860400002)(39840400002)(54896002)(3846002)(122556002)(76176999)(2420400007)(6606003)(15650500001)(2950100002)(7696004)(2900100001)(236005)(55016002)(5660300001)(6306002)(54906002)(53936002)(77096006)(99286003)(9686003)(8676002)(7736002)(81166006)(25786008)(229853002)(7906003)(86362001)(189998001)(2906002)(38730400002)(10710500007)(6506006)(102836003)(74316002)(6246003)(6116002)(606005)(3280700002)(7110500001)(8936002)(966004)(54356999)(6436002)(3660700001)(33656002)(53336002)(66066001)(4326008)(50986999)(19627405001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0446; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR09MB04468AF74061924F8576067784270DM2PR09MB0446namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2017 02:58:31.5777 (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: Subject: Re: [sidr] BGPsec draft and extended messages X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 02:58:36 -0000 --_000_DM2PR09MB04468AF74061924F8576067784270DM2PR09MB0446namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable >> I think it makes sense to omit the extended message feature, given the >> use of ECDSA P-256. >unfortunately, existing bgp data and simple arithmetic would seem to say o= therwise. We are focusing here on the size of the BGPsec_Path attribute. As I wrote in the rationale part in my other post (in this thread): BGPsec update size is subject to =93current=94 maximum BGP update size, not= ing that =93current=94 maximum size may increase in the future. The maximum= size at present is 4096 bytes [RFC4271], and it is expected be extended to= a larger size in the future [I-D.ietf-idr-bgp-extended-messages]. Given th= e use of ECDSA P-256 for the signature algorithm [I-D.ietf-sidr-bgpsec-algs= ], each AS in an AS path adds approximately 100 bytes of BGPsec data (i.e. = Secure_Path Segment and Signature Segment). Hence, the maximum size of 4096= bytes is exceeded only if there are 40 or more distinct ASes in the AS pat= h. (Note: AS prepends are compressed out with the use of pCount as describe= d in Section 3.1.) Currently, the average and maximum AS path lengths in t= he Internet are 3.8 and 14, respectively, and have remained in this ball pa= rk for many years [Huston]. [Huston] G. Huston, =93AS6447 BGP Routing Table Analysis Report,=94 March 1= 3, 2017. http://bgp.potaroo.net/as6447/ Extended messages work must/will continue. We are only trying to see if BGP= sec draft can have the extended messages draft as an "Informational" reference rather= than "Normative". Sriram --_000_DM2PR09MB04468AF74061924F8576067784270DM2PR09MB0446namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

>> I think it makes sense to omit the extended message feature, gi= ven the

>> use of ECDSA P-256.


>unfortunately, existing bgp data and simple arithmetic would seem to= say otherwise.



We are focusing here on the size of the BGPsec_Path attribute.

As I wrote in the rationale part in my other post (in this thread):



BGPsec update size is subject to =93current=94 maximum BGP update = size, noting that =93current=94 maximum size may increase in the future. Th= e maximum size at present is 4096 bytes [RFC4271], and it is expected be ex= tended to a larger size in the future [I-D.ietf-idr-bgp-extended-messages]. Given the use of ECDSA P-256 for the signature algorithm [I-D.ietf-si= dr-bgpsec-algs], each AS in an AS path adds approximately 100 bytes of BGPs= ec data (i.e. Secure_Path Segment and Signature Segment). Hence, the maximu= m size of 4096 bytes is exceeded only if there are 40 or more distinct ASes in the AS path. (Note: AS prepends a= re compressed out with the use of pCount as described in Section 3.1.) = ; Currently, the average and maximum AS path lengths in the Internet are 3.= 8 and 14, respectively, and have remained in this ball park for many years [Huston]. 



[Huston] G. Huston, =93AS6447 BGP Routing Table A= nalysis Report,=94 March 13, 2017.  http://bgp.potaroo.net/as6447/ 



Extended messages work must/will continue. We are only tryin= g to see if BGPsec draft

can have the extended messages draft as an = "Informational" reference rather than "Normative".



Sriram


--_000_DM2PR09MB04468AF74061924F8576067784270DM2PR09MB0446namp_-- From nobody Tue Mar 14 21:25:43 2017 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 4CD98128896; Tue, 14 Mar 2017 21:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMFmtkb-xmIj; Tue, 14 Mar 2017 21:25:39 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8B27127B31; Tue, 14 Mar 2017 21:25:39 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 15E48B8125D; Tue, 14 Mar 2017 21:25:30 -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 Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, sidr@ietf.org Message-Id: <20170315042530.15E48B8125D@rfc-editor.org> Date: Tue, 14 Mar 2017 21:25:30 -0700 (PDT) Archived-At: Subject: [sidr] RFC 8097 on BGP Prefix Origin Validation State Extended Community X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 04:25:41 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8097 Title: BGP Prefix Origin Validation State Extended Community Author: P. Mohapatra, K. Patel, J. Scudder, D. Ward, R. Bush Status: Standards Track Stream: IETF Date: March 2017 Mailbox: mpradosh@yahoo.com, keyur@arrcus.com, jgs@juniper.net, dward@cisco.com, randy@psg.com Pages: 6 Characters: 12287 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sidr-origin-validation-signaling-11.txt URL: https://www.rfc-editor.org/info/rfc8097 DOI: 10.17487/RFC8097 This document defines a new BGP opaque extended community to carry the origination Autonomous System (AS) validation state inside an autonomous system. Internal BGP (IBGP) speakers that receive this validation state can configure local policies that allow it to influence their decision process. 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 Wed Mar 15 02:24:44 2017 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 44959129A0F; Wed, 15 Mar 2017 02:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0Uv-u63osf2; Wed, 15 Mar 2017 02:24:42 -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 A9F10129A07; Wed, 15 Mar 2017 02:24:42 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1co5AX-0002mw-Ru; Wed, 15 Mar 2017 10:24:35 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-90.ripe.net) by nene.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1co5AX-0002qe-Nm; Wed, 15 Mar 2017 10:24:33 +0100 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_C5394AF2-E4EC-4AEE-8F4B-848DC4C4F3A7" From: Tim Bruijnzeels In-Reply-To: Date: Wed, 15 Mar 2017 10:24:33 +0100 Cc: daniel@afrinic.net, Rob Austein , "sidr-chairs@ietf.org" , "sidr@ietf.org" , "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" Message-Id: <8C26566E-8E22-4D35-85E1-387BA980115E@ripe.net> References: <5821A5CF-EFF8-4CE3-9AA4-CFDB9C903D63@cisco.com> <20170311222527.324125ACF21@minas-ithil.hactrn.net> <6359B4B1-478D-4017-B259-7B60BA55FF39@zdns.cn> <68C71545-48E4-40B8-91AC-88DE44C4125D@ripe.net> To: Chris Morrow X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------ X-RIPE-Spam-Report: Spam Total Points: -6.0 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 HTML_MESSAGE BODY: HTML included in message 1.5 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719e8dd8a0a517714e754f0cb710ce62cf5 Archived-At: Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-07 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 09:24:44 -0000 --Apple-Mail=_C5394AF2-E4EC-4AEE-8F4B-848DC4C4F3A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Chris, > On 13 Mar 2017, at 15:21, Chris Morrow wrote: >=20 > but, having 2 versions of the validation > algorithm and seeing published data for both OID sets for a single > prefix/publication bundle will be very problematic. There's no > proscribed 'prefer new over old' action here, so a CA must only > publish one version of their data. Why is this a problem, really? The OIDs are set on a per certificate basis by the issuing CA. FWIW, in = our hosted set up we *will* be able to pro-actively re-issue everything = using the new OIDs without user interaction, but there are cases in = hosted CA deployments where a hosted CA can automatically re-issue = manifests, but ROAs can only be re-issued by explicit user request, one = by one. So we may see hosted CAs with products like this: 1 CRL (validation algorithm does not apply) 1 MFT (new validation, although it won't matter because inherit is used) 1 ROA with new validation (which has been re-issued by the user) 1 ROA with old validation (which has NOT yet been re-issued) This might seem confusing, but since the OIDs make it very explicit = which algorithm the CA intended to use, I really do not see any = ambiguity here. My main concern is that we need to be quite confident that new RP code = that understands the new OIDs has been available and is deployed. = Because old RPs will reject EVERYTHING once CAs start using the new = OIDs. That is why I would have preferred to not need new OIDs, and just agree = on a day that the new algorithm should be preferred. Rob seems adamant = that the RFC3779 extension library code does not have access to the = context of the full certificate with the RPKI CP OID - so there is no = way to have something like: if (FULL certificate has RPKI CP OID && Date is after 'switch' day) { do NEW on RFC3779 extension } else { do OLD on RFC3779 extension } The impact of RP software not using the new library on 'switch' day is = fairly limited. They would not reject the full repository, but only = reject the exceptional cases where certificates ARE over-claiming. And = of course the date check can be removed in releases of the library after = 'switch' day.. It seems to me that this is a design issue with OpenSSL itself, but be = that as it may - it may be unsurmountable. Rob knows this code much = better than I do. Still the consequence of all this is is that we will have to have a mix, = and that despite our best efforts to warn everyone to upgrade their RP = software I expect that we WILL see a number of operators that suddenly = find that their old RP software has reject our full repository when = start using the new OIDs. If it can't be avoided than so be it, but I believe this perspective = should be considered as well. Cheers Tim --Apple-Mail=_C5394AF2-E4EC-4AEE-8F4B-848DC4C4F3A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Chris,

On 13 Mar 2017, at 15:21, Chris = Morrow <morrowc@ops-netman.net> wrote:

but, having 2 versions of the = validation
algorithm and seeing published data for both OID = sets for a single
prefix/publication bundle will be very = problematic. There's no
proscribed 'prefer new over old' action = here, so a CA must only
publish one version of their = data.

Why is this a = problem, really?

The OIDs are set on = a per certificate basis by the issuing CA. FWIW, in our hosted set up we = *will* be able to pro-actively re-issue everything using the new OIDs = without user interaction, but there are cases in hosted CA deployments = where a hosted CA can automatically re-issue manifests, but ROAs can = only be re-issued by explicit user request, one by one.

So we may see hosted CAs with products like = this:

1 CRL (validation algorithm = does not apply)
1 MFT (new validation, although it won't = matter because inherit is used)
1 ROA with new validation = (which has been re-issued by the user)
1 ROA with old = validation (which has NOT yet been re-issued)

This might seem confusing, but since the OIDs make = it very explicit which algorithm the CA intended to use, I really do not = see any ambiguity here.

My main = concern is that we need to be quite confident that new RP code that = understands the new OIDs has been available and is deployed. Because old = RPs will reject EVERYTHING once CAs start using the new = OIDs.

That is why I would have = preferred to not need new OIDs, and just agree on a day that the new = algorithm should be preferred. Rob seems adamant that the RFC3779 = extension library code does not have access to the context of the full = certificate with the RPKI CP OID - so there is no way to have something = like:

if (FULL certificate has RPKI = CP OID && Date is after 'switch' day) {
  do NEW = on RFC3779 extension
} else {
  do OLD on = RFC3779 extension
}

The = impact of RP software not using the new library on 'switch' day is = fairly limited. They would not reject the full repository, but only = reject the exceptional cases where certificates ARE over-claiming. And = of course the date check can be removed in releases of the library after = 'switch' day..

It seems to me that = this is a design issue with OpenSSL itself, but be that as it may - it = may be unsurmountable. Rob knows this code much better than I = do.

Still the consequence of all = this is is that we will have to have a mix, and that despite our best = efforts to warn everyone to upgrade their RP software I expect that we = WILL see a number of operators that suddenly find that their old RP = software has reject our full repository when start using the new = OIDs.

If it can't be avoided than so = be it, but I believe this perspective should be considered as = well.



Cheers

Tim



= --Apple-Mail=_C5394AF2-E4EC-4AEE-8F4B-848DC4C4F3A7-- From nobody Wed Mar 15 06:45:09 2017 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 D97231314F4; Wed, 15 Mar 2017 06:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwFFaMHOejOh; Wed, 15 Mar 2017 06:44:58 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7F7C1314F0; Wed, 15 Mar 2017 06:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11826; q=dns/txt; s=iport; t=1489585497; x=1490795097; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bI1Kc+ZrDAYFCV6z521apxDkMo9uMG+XI+Ouug7HV7g=; b=OzbGypGgCk5h3SPii1uB7apsOtIxpuHWCXDuGlAUmf2u9q/ClzInchmt 6widcyZEgWewLWbDuYzyIhH0Q2UinC6Q8A+5pirLaPh85uR5X6H5Gd2rk aobU4laNumJwtmbWNl0LKCvY5SbMkIoH7PyKBsIpPEbpQAtuThKZwkYGz o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A7AwD9RMlY/40NJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5jYYEKB4NZig2RNx+QD4Utgg6GIgIagk8/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRYBBAEjVgULAgEIPwMCAgIwFBEBAQQBDQWJeAiuCIImK4o1AQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYZOggUIgmKHWi6CMQWWAIZDAZI6gXuFJYoFiEaLAAEfOIE?= =?us-ascii?q?EWBVBEQGEQiCBY3WIJYENAQEB?= X-IronPort-AV: E=Sophos;i="5.36,168,1486425600"; d="scan'208,217";a="398438011" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Mar 2017 13:44:56 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v2FDiu5R000384 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Mar 2017 13:44:56 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 15 Mar 2017 08:44:55 -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, 15 Mar 2017 08:44:55 -0500 From: "Alvaro Retana (aretana)" To: "Sriram, Kotikalapudi (Fed)" , Randy Bush , Steve KENT CC: sidr wg list , Matthias Waehlisch , "sidr-chairs@ietf.org" , Sean Turner , "sidrops@ietf.org" Thread-Topic: [sidr] BGPsec draft and extended messages Thread-Index: AdKcN8SBuyxP2TUmTMSCIN0IJlVFkAA0o+kaAAxpUAAAF68igA== Date: Wed, 15 Mar 2017 13:44:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.6] Content-Type: multipart/alternative; boundary="_000_BC9717B9C4664278B88648D9C2EA16DFciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sidr] BGPsec draft and extended messages X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 13:45:03 -0000 --_000_BC9717B9C4664278B88648D9C2EA16DFciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkhDQoNCltTcGVha2luZyBhcyBBRF0NCg0KVGhlIHJlcXVpcmVtZW50IGZvciBFeHRlbmRlZCBN ZXNzYWdlcyBoYXMgYmVlbiBpbiB0aGUgQkdQU2VjIGRyYWZ0IHNpbmNlIHRoZSBiZWdpbm5pbmcg KGF0IGxlYXN0IHRoZSBXRyAtMDAgdmVyc2lvbikuICBDaGFuZ2luZyBpdCBub3cgd291bGQgbWVh biBhIHNpZ25pZmljYW50IGRldmlhdGlvbiBpbiB0aGUgcHJvY2VzcyDigJMgYnV0IG5vdCBpbXBv c3NpYmxlLg0KDQpCZWZvcmUgY29tbWl0dGluZyB0byBzdXBwb3J0aW5nIGFueSBjaGFuZ2UgdG8g dGhlIGRvY3VtZW50LCBJIHdvdWxkIGxpa2UgdG8gc2VlIGNoYW5nZXMgZGlzY3Vzc2VkIGluIHRo ZSBzaWRyIFdHIGxpc3QuICBZb3UgbWF5IGV2ZW4gYmUgYWJsZSB0byBjb252aW5jZSB0aGUgc2lk cm9wcyBDaGFpcnMgdG8gZ2l2ZSB5b3Ugc29tZSB0aW1lIGluIENoaWNhZ28gdG8gZGlzY3VzcyBp biBwZXJzb24uICBXZSB3b3VsZCBuZWVkIHRoZSBXRyB0byByZWFjaCBjb25zZW5zdXMgZm9yIHN1 Y2ggYSBjaGFuZ2UuDQoNCg0KW1NwZWFraW5nIGFzIFdHIFBhcnRpY2lwYW50XQ0KDQpJIHRoaW5r IHRoYXQgYSBwb3NzaWJsZSBwYXRoIGZvcndhcmQgaXMgdG8gdGFrZSBhbnkgcmVmZXJlbmNlIHRv IHRoZSBFeHRlbmRlZCBNZXNzYWdlcyBkb2N1bWVudCBvdXQsIGFuZCBzaW1wbHkgcHV0IHRleHQg c2ltaWxhciB0byB0aGlzIGluIChmcm9tIFNyaXJhbeKAmXMgbWVzc2FnZSk6DQoNCuKAnEJHUHNl YyB1cGRhdGUgc2l6ZSBpcyBzdWJqZWN0IHRvIGEgbWF4aW11bSBCR1AgdXBkYXRlIHNpemUuIFRo ZSBtYXhpbXVtIHNpemUgYXQgcHJlc2VudCBpcyA0MDk2IGJ5dGVzIFtSRkM0MjcxXSwgYW5kIGl0 IG1heSBiZSBleHRlbmRlZCB0byBhIGxhcmdlciBzaXplIGluIHRoZSBmdXR1cmUuIElmIHRoZSBz ZW5kaW5nIHJvdXRlciBkZXRlcm1pbmVzIHRoYXQgYWRkaW5nIGl0cyBTZWN1cmVfUGF0aCBTZWdt ZW50IGFuZCBTaWduYXR1cmUgU2VnbWVudCBjYXVzZXMgdGhlIEJHUHNlYyB1cGRhdGUgdG8gZXhj ZWVkIHRoZSBtYXhpbXVtIHNpemUsIHRoZW4gaXQgd2lsbCBjb252ZXJ0IHRoZSBCR1BzZWMgdXBk YXRlIHRvIGFuIHVuc2lnbmVkIHRyYWRpdGlvbmFsIEJHUCB1cGRhdGUgW3VzaW5nIHRoZSBwcm9j ZWR1cmUgaW4gU2VjdGlvbiA0LjRdIGFuZCBzZW5kIHRoZSB1bnNpZ25lZCB1cGRhdGUuIChOb3Rl OiBQbGVhc2Ugc2VlIHJlbGF0ZWQgZGlzY3Vzc2lvbiBpbiBTZWN0aW9uIDcuKeKAnQ0KDQpJIHdv dWxkIGV2ZW4ganVzdCBtZW50aW9uIHRoZSDigJxtYXhpbXVtIG1lc3NhZ2Ugc2l6ZeKAnSAod2l0 aCBubyBzcGVjaWZpYyBudW1iZXJzKSBhbmQgbGVhdmUgb3V0IG1lbnRpb24gb2YgYW55IGZ1dHVy ZSBjaGFuZ2VzLiAgVGhpcyB3YXkgdGhlIEJHUFNlYyBkb2N1bWVudHMgKDEpIGRvbuKAmXQgZGVw ZW5kIG9uIHRoZSBFeHRlbmRlZCBNZXNzYWdlcyBkb2N1bWVudCwgYW5kICgyKSB0aGV5IGRlcGVu ZCBvbiB3aGF0ZXZlciBCR1AgY2FuIGRvLiAgSWYvd2hlbiBFeHRlbmRlZCBNZXNzYWdlcyBhcmUg c2V0dGxlZCBhbmQgaW1wbGVtZW50ZWQgdGhlbiBCR1BTZWMgY2FuIG1ha2UgdXNlIG9mIHRoZW0g KGFzIGNhbiBhbnkgb3RoZXIgYXBwbGljYXRpb24gdXNpbmcgQkdQKS4NCg0KDQpUaGFua3MhDQoN CkFsdmFyby4NCg0KDQoNCg0KDQoNCg0KDQpPbiAzLzE0LzE3LCA2OjI2IFBNLCAiU3JpcmFtLCBL b3Rpa2FsYXB1ZGkgKEZlZCkiIDxrb3Rpa2FsYXB1ZGkuc3JpcmFtQG5pc3QuZ292PG1haWx0bzpr b3Rpa2FsYXB1ZGkuc3JpcmFtQG5pc3QuZ292Pj4gd3JvdGU6DQoNCj4gQWx2YXJvIHJlcGxpZWQg dG8gbWUgaW4gZGV0YWlsLg0K --_000_BC9717B9C4664278B88648D9C2EA16DFciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9y bWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5IaSE8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5bU3BlYWtpbmcgYXMgQURdJm5ic3A7DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpIj5UaGUgcmVxdWlyZW1lbnQgZm9yIEV4dGVuZGVkIE1lc3NhZ2Vz IGhhcyBiZWVuIGluIHRoZSBCR1BTZWMgZHJhZnQgc2luY2UgdGhlIGJlZ2lubmluZyAoYXQgbGVh c3QgdGhlIFdHIC0wMCB2ZXJzaW9uKS4mbmJzcDsgQ2hhbmdpbmcgaXQgbm93IHdvdWxkIG1lYW4g YSBzaWduaWZpY2FudCBkZXZpYXRpb24gaW4gdGhlIHByb2Nlc3MNCiDigJMgYnV0IG5vdCBpbXBv c3NpYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkJlZm9yZSBjb21taXR0aW5nIHRvIHN1 cHBvcnRpbmcgYW55IGNoYW5nZSB0byB0aGUgZG9jdW1lbnQsIEkgd291bGQgbGlrZSB0byBzZWUg Y2hhbmdlcyBkaXNjdXNzZWQgaW4gdGhlIHNpZHIgV0cgbGlzdC4mbmJzcDsgWW91IG1heSBldmVu IGJlIGFibGUgdG8gY29udmluY2UgdGhlIHNpZHJvcHMgQ2hhaXJzIHRvIGdpdmUgeW91IHNvbWUN CiB0aW1lIGluIENoaWNhZ28gdG8gZGlzY3VzcyBpbiBwZXJzb24uJm5ic3A7IFdlIHdvdWxkIG5l ZWQgdGhlIFdHIHRvIHJlYWNoIGNvbnNlbnN1cyBmb3Igc3VjaCBhIGNoYW5nZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj5bU3BlYWtpbmcgYXMgV0cgUGFydGljaXBhbnRdPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aSI+SSB0aGluayB0aGF0IGEgcG9zc2libGUgcGF0aCBmb3J3YXJkIGlzIHRvIHRha2UgYW55IHJl ZmVyZW5jZSB0byB0aGUgRXh0ZW5kZWQgTWVzc2FnZXMgZG9jdW1lbnQgb3V0LCBhbmQgc2ltcGx5 IHB1dCB0ZXh0IHNpbWlsYXIgdG8gdGhpcyBpbiAoZnJvbSBTcmlyYW3igJlzIG1lc3NhZ2UpOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPuKAnEJHUHNlYyB1cGRhdGUgc2l6ZSBpcyBzdWJqZWN0 IHRvIGEgbWF4aW11bSBCR1AgdXBkYXRlIHNpemUuIFRoZSBtYXhpbXVtIHNpemUgYXQgcHJlc2Vu dCBpcyA0MDk2IGJ5dGVzIFtSRkM0MjcxXSwgYW5kIGl0IG1heSBiZSBleHRlbmRlZCB0byBhIGxh cmdlciBzaXplIGluIHRoZSBmdXR1cmUuIElmIHRoZSBzZW5kaW5nIHJvdXRlcg0KIGRldGVybWlu ZXMgdGhhdCBhZGRpbmcgaXRzIFNlY3VyZV9QYXRoIFNlZ21lbnQgYW5kIFNpZ25hdHVyZSBTZWdt ZW50IGNhdXNlcyB0aGUgQkdQc2VjIHVwZGF0ZSB0byBleGNlZWQgdGhlIG1heGltdW0gc2l6ZSwg dGhlbiBpdCB3aWxsIGNvbnZlcnQgdGhlIEJHUHNlYyB1cGRhdGUgdG8gYW4gdW5zaWduZWQgdHJh ZGl0aW9uYWwgQkdQIHVwZGF0ZSBbdXNpbmcgdGhlIHByb2NlZHVyZSBpbiBTZWN0aW9uIDQuNF0g YW5kIHNlbmQgdGhlIHVuc2lnbmVkDQogdXBkYXRlLiAoTm90ZTogUGxlYXNlIHNlZSByZWxhdGVk IGRpc2N1c3Npb24gaW4gU2VjdGlvbiA3LinigJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5J IHdvdWxkIGV2ZW4ganVzdCBtZW50aW9uIHRoZSDigJxtYXhpbXVtIG1lc3NhZ2Ugc2l6ZeKAnSAo d2l0aCBubyBzcGVjaWZpYyBudW1iZXJzKSBhbmQgbGVhdmUgb3V0IG1lbnRpb24gb2YgYW55IGZ1 dHVyZSBjaGFuZ2VzLiZuYnNwOyBUaGlzIHdheSB0aGUgQkdQU2VjIGRvY3VtZW50cyAoMSkgZG9u 4oCZdCBkZXBlbmQgb24gdGhlIEV4dGVuZGVkDQogTWVzc2FnZXMgZG9jdW1lbnQsIGFuZCAoMikg dGhleSBkZXBlbmQgb24gd2hhdGV2ZXIgQkdQIGNhbiBkby4mbmJzcDsgSWYvd2hlbiBFeHRlbmRl ZCBNZXNzYWdlcyBhcmUgc2V0dGxlZCBhbmQgaW1wbGVtZW50ZWQgdGhlbiBCR1BTZWMgY2FuIG1h a2UgdXNlIG9mIHRoZW0gKGFzIGNhbiBhbnkgb3RoZXIgYXBwbGljYXRpb24gdXNpbmcgQkdQKS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj5UaGFua3MhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+QWx2YXJvLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gMy8xNC8xNywgNjoyNiBQTSwgJnF1b3Q7U3JpcmFtLCBLb3Rp a2FsYXB1ZGkgKEZlZCkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzprb3Rpa2FsYXB1ZGkuc3Jp cmFtQG5pc3QuZ292Ij5rb3Rpa2FsYXB1ZGkuc3JpcmFtQG5pc3QuZ292PC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+Jmd0OyBBbHZhcm8g cmVwbGllZCB0byBtZSBpbiBkZXRhaWwuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BC9717B9C4664278B88648D9C2EA16DFciscocom_-- From nobody Wed Mar 15 08:44:48 2017 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 C050E1316AB for ; Wed, 15 Mar 2017 08:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQKLo6ftkCnw for ; Wed, 15 Mar 2017 08:44:44 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 41C821315AE for ; Wed, 15 Mar 2017 08:44:44 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id n21so15460304qta.1 for ; Wed, 15 Mar 2017 08:44:44 -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=UMC4X0VcFpkDrEcjCW/8BanOfuix6BICYMcm4Kxikx0=; b=AtQ69pv6dMO4xtuLPN6CeLvsbhmqtZi5q9BCVozQ/tgWnFi1bDXJrRvpcPjtqavQti 4xmhFkNPfalsN85vj8ywQl6njbodqw4rn6MZLByOA3VBh7KTKmAjXw8TG87vB0cetYYA BePfON+gzHcV+tUyNtaNyvCLVDgjb142z82VE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UMC4X0VcFpkDrEcjCW/8BanOfuix6BICYMcm4Kxikx0=; b=P4OIOPmqs7dF+yX5254cK6fmKzztPrkKkzvlLfmZU80Z7gJiegPpdJHStSSd5/YB40 ywkKgWyUiK9cE9pOnqXdHgyO26ilTFnVz9vcq2+mI7l7AJBD2LK5p97SLRESPIM1MDjx +JORZpv0ZPOWXMw69wUEpg/CdQFKdNnLyKCFSayYEjhV6rh6N0/Q2vAZGUahqEsiujoH OYKHq0widVSCEHN+8kCHy5BAuEY2Fo/8e+wKtpJ92ybTHE4bir9L28Gv4Mzx5v0jvcJ/ Qh8iW3vYy+MlSrDnb4E4BG5twkteLt3NavMnEggierElQ+Ql2nzuPF82orer5b0nE/6o ipaQ== X-Gm-Message-State: AFeK/H2sfXVv0se5ZIKqA9F+zLJiuyHxXByrltyO7EJYOe3yLZ9Klyu7gszQ0B4qRFJwvg== X-Received: by 10.200.45.57 with SMTP id n54mr3704923qta.212.1489592683248; Wed, 15 Mar 2017 08:44:43 -0700 (PDT) Received: from [172.16.0.18] ([96.231.230.131]) by smtp.gmail.com with ESMTPSA id q11sm1536236qkh.16.2017.03.15.08.44.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 08:44:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Sean Turner In-Reply-To: <148844379373.7077.11693707774114284535.idtracker@ietfa.amsl.com> Date: Wed, 15 Mar 2017 11:44:40 -0400 Cc: ops-dir@ietf.org, draft-ietf-sidr-bgpsec-pki-profiles.all@ietf.org, ietf@ietf.org, sidr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <54D7584B-B009-4461-8499-8E7717220867@sn3rd.com> References: <148844379373.7077.11693707774114284535.idtracker@ietfa.amsl.com> To: Shucheng LIU X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [sidr] Review of draft-ietf-sidr-bgpsec-pki-profiles-21 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 15:44:47 -0000 > On Mar 2, 2017, at 03:36, Shucheng LIU wrote: >=20 > ** Editorial ** >=20 > *Section 4 >=20 >> BGPsec Router Certificates always include the BGPsec Rouer EKU >> value; therefore, request without the value result in > certificates >> with the value; and, >=20 > s/Rouer/Router Thanks! If the RFC editor misses this I=E2=80=99ll make sure that it = gets fixed up in AUTH48. spt= From nobody Wed Mar 15 09:43:22 2017 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 4F2B11316A1; Wed, 15 Mar 2017 09:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FT7X0RUfBLDp; Wed, 15 Mar 2017 09:43:19 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 EF95E13171A; Wed, 15 Mar 2017 09:43:18 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.2.137; From: "Susan Hares" To: "'Alvaro Retana \(aretana\)'" , "'Sriram, Kotikalapudi \(Fed\)'" , "'Randy Bush'" , "'Steve KENT'" Cc: , , "'Matthias Waehlisch'" , "'sidr wg list'" References: In-Reply-To: Date: Wed, 15 Mar 2017 12:38:32 -0400 Message-ID: <031501d29daa$95f44320$c1dcc960$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0316_01D29D89.0EE4C600" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIJvgUkdknlbchV64BNKsEAFS0ypwGwu225AcVHGkYCCCF0zqD750fA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [sidr] BGPsec draft and extended messages X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 16:43:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0316_01D29D89.0EE4C600 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Alvaro:=20 =20 Thank you for working through these issues at this late time.=20 =20 =20 IDR is talking input on this topic. So it would be good to post a = summary of your discussion to the IDR list. If it is useful, we can = still set aside time for the authors (or SIDR WG chairs) to present = their needs at IDR. If you wish this, please let the IDR chairs know so = we can set-up time.=20 =20 =20 Sue Hares=20 =20 =20 From: sidr [mailto:sidr-bounces@ietf.org] On Behalf Of Alvaro Retana = (aretana) Sent: Wednesday, March 15, 2017 9:45 AM To: Sriram, Kotikalapudi (Fed); Randy Bush; Steve KENT Cc: sidrops@ietf.org; sidr-chairs@ietf.org; Matthias Waehlisch; sidr wg = list Subject: Re: [sidr] BGPsec draft and extended messages =20 Hi! =20 [Speaking as AD] =20 =20 The requirement for Extended Messages has been in the BGPSec draft since = the beginning (at least the WG -00 version). Changing it now would mean = a significant deviation in the process =E2=80=93 but not impossible. =20 Before committing to supporting any change to the document, I would like = to see changes discussed in the sidr WG list. You may even be able to = convince the sidrops Chairs to give you some time in Chicago to discuss = in person. We would need the WG to reach consensus for such a change. =20 =20 [Speaking as WG Participant] =20 I think that a possible path forward is to take any reference to the = Extended Messages document out, and simply put text similar to this in = (from Sriram=E2=80=99s message): =20 =E2=80=9CBGPsec update size is subject to a maximum BGP update size. The = maximum size at present is 4096 bytes [RFC4271], and it may be extended = to a larger size in the future. If the sending router determines that = adding its Secure_Path Segment and Signature Segment causes the BGPsec = update to exceed the maximum size, then it will convert the BGPsec = update to an unsigned traditional BGP update [using the procedure in = Section 4.4] and send the unsigned update. (Note: Please see related = discussion in Section 7.)=E2=80=9D =20 I would even just mention the =E2=80=9Cmaximum message size=E2=80=9D = (with no specific numbers) and leave out mention of any future changes. = This way the BGPSec documents (1) don=E2=80=99t depend on the Extended = Messages document, and (2) they depend on whatever BGP can do. If/when = Extended Messages are settled and implemented then BGPSec can make use = of them (as can any other application using BGP). =20 =20 Thanks! =20 Alvaro. =20 =20 =20 =20 =20 =20 =20 =20 On 3/14/17, 6:26 PM, "Sriram, Kotikalapudi (Fed)" = wrote: =20 > Alvaro replied to me in detail.=20 ------=_NextPart_000_0316_01D29D89.0EE4C600 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Alvaro:

 

Thank you for working through these issues at this late time. =

<IDR WG chair hat on>

 

IDR is talking input on this topic.=C2=A0 So it would be good to post = a summary of your discussion to the IDR list. =C2=A0=C2=A0If it is = useful, we can still set aside time for the authors (or SIDR WG chairs) = to present their needs at IDR.=C2=A0 If you wish this, please let the = IDR chairs know so we can set-up time.

<IDR WG chair hat off>

 

Sue Hares

=C2=A0

 

From:= = sidr [mailto:sidr-bounces@ietf.org] On Behalf Of Alvaro Retana = (aretana)
Sent: Wednesday, March 15, 2017 9:45 = AM
To: Sriram, Kotikalapudi (Fed); Randy Bush; Steve = KENT
Cc: sidrops@ietf.org; sidr-chairs@ietf.org; Matthias = Waehlisch; sidr wg list
Subject: Re: [sidr] BGPsec draft and = extended messages

 

Hi!

 =

[Speaking = as AD] 

 =

The = requirement for Extended Messages has been in the BGPSec draft since the = beginning (at least the WG -00 version).  Changing it now would = mean a significant deviation in the process =E2=80=93 but not = impossible.

 =

Before = committing to supporting any change to the document, I would like to see = changes discussed in the sidr WG list.  You may even be able to = convince the sidrops Chairs to give you some time in Chicago to discuss = in person.  We would need the WG to reach consensus for such a = change.

 =

 =

[Speaking = as WG Participant]

 =

I think = that a possible path forward is to take any reference to the Extended = Messages document out, and simply put text similar to this in (from = Sriram=E2=80=99s message):

 =

=E2=80=9CBG= Psec update size is subject to a maximum BGP update size. The maximum = size at present is 4096 bytes [RFC4271], and it may be extended to a = larger size in the future. If the sending router determines that adding = its Secure_Path Segment and Signature Segment causes the BGPsec update = to exceed the maximum size, then it will convert the BGPsec update to an = unsigned traditional BGP update [using the procedure in Section 4.4] and = send the unsigned update. (Note: Please see related discussion in = Section 7.)=E2=80=9D

 =

I would = even just mention the =E2=80=9Cmaximum message size=E2=80=9D (with no = specific numbers) and leave out mention of any future changes.  = This way the BGPSec documents (1) don=E2=80=99t depend on the Extended = Messages document, and (2) they depend on whatever BGP can do.  = If/when Extended Messages are settled and implemented then BGPSec can = make use of them (as can any other application using = BGP).

 =

 =

Thanks!

 =

Alvaro.

 =

 =

 =

 =

 =

 =

 =

 =

On 3/14/17, 6:26 PM, = "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov= > wrote:

 

> Alvaro = replied to me in detail. 

------=_NextPart_000_0316_01D29D89.0EE4C600-- From nobody Wed Mar 15 11:15:54 2017 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 5B13D131774; Wed, 15 Mar 2017 11:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rpfCWt65m4V; Wed, 15 Mar 2017 11:15:49 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id A9B51131765; Wed, 15 Mar 2017 11:15:49 -0700 (PDT) Received: from [10.33.204.119] (unknown [156.154.81.54]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id E7E0A540A62; Wed, 15 Mar 2017 14:15:36 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_63016B99-F777-4929-A6DF-D3A4C87C9E29"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Wes George In-Reply-To: Date: Wed, 15 Mar 2017 14:15:29 -0400 Cc: "Sriram, Kotikalapudi (Fed)" , Randy Bush , Steve KENT , sidr wg list , Matthias Waehlisch , "sidr-chairs@ietf.org" , Sean Turner , "sidrops@ietf.org" Message-Id: <4CF183FB-F22F-4133-BE91-86CA44DBEDBE@puck.nether.net> References: To: "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [sidr] BGPsec draft and extended messages X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 18:15:52 -0000 --Apple-Mail=_63016B99-F777-4929-A6DF-D3A4C87C9E29 Content-Type: multipart/alternative; boundary="Apple-Mail=_38823FDC-80EB-4BD4-AB49-B746C663C239" --Apple-Mail=_38823FDC-80EB-4BD4-AB49-B746C663C239 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m behind on mail but Sriram suggested I pay attention to this, = so here=E2=80=99s a drive-by comment, and if this comes up in SIDROps in = Chicago I=E2=80=99ll do my best to attend and participate in the = discussion there. Being pragmatic, I understand that the risk is low for exceeding the max = size without extended message support based on the average AS-path = length, but I have concerns about the suggested solution that treats = unsigned updates as a fallback path for updates that would otherwise be = too large. First, I don=E2=80=99t believe that there is any construct = within the current BGPSec setup that allows for this sort of mixed mode = where most updates are signed but some subset are not. Normally it=E2=80=99= s something negotiated on session establish - either BGPSec is supported = by both neighbors, or it is not - and the BGP machinery handles updates = accordingly. So likely the document would need some additional guidance = on how that mixed mode is supposed to work. I think it=E2=80=99s pretty = straightforward since there is already a defined process for stripping = signatures and sending unsigned updates, but there=E2=80=99s sufficient = grey area that I am not comfortable leaving this =E2=80=9Cas an exercise = for the implementer=E2=80=9D since it needs to properly interoperate. = And if what is being suggested is that one update being too large drops = the entire session back to unsecured mode, that seems even worse. More generally, I have expressed concern in the past (including quite = publicly at NANOG) about =E2=80=9Cfailing open=E2=80=9D and the impacts = of this model. While it=E2=80=99s definitely the lower-risk method when = we=E2=80=99re dealing with something as critical as routing updates, it = has the net effect of creating situations where the very benefit gained = by deploying the technology is negated because any number of problems = can cause fallback to the unsecured model that is effectively the same = as having not deployed in the first place. The deployment threshold for = things like this is usually that the net improvement in protection has = to be worth the increased overhead of deployment and maintenance. I have = been having trouble making the argument that OV and PV fall on the right = side of that line due to the amount of places where things fail open by = design. Some of those concerns are addressed by work in progress to move = away from rsync and address other potential failure cases, but the = potential for what amounts to a silent failure where some subset of = routes on a session that I expect to be secured suddenly are not seems = high in this case, and thus I don=E2=80=99t see this as an acceptable = tradeoff. Given the headwinds for deployment of path validation - it requires a = certain level of hardware support (CPU/Memory) to deploy at real scale, = software features that haven=E2=80=99t been implemented yet, etc., I = don=E2=80=99t see a delay while we get extended message support sorted = as any really serious deal-breaker. Realistically, vendors and operators = will be better served if this set of features can be implemented as a = group to minimize the amount of touching and re-touching the same area = of code and certifying and deploying multiple code versions to get = everything. In other words, if I were deciding on a deployment timeline, = I=E2=80=99d plan to wait until a critical mass of features is available = either way, so whether that waiting happens now or later, the result is = the same, and the better focus would be to get Extended Messages moved = through the process with all possible haste instead of trying to pull = BGPSec back for late-stage changes to reduce its dependency on the = former. Wes George > On Mar 15, 2017, at 9:44 AM, Alvaro Retana (aretana) = wrote: >=20 > Hi! >=20 > [Speaking as AD] >=20 > The requirement for Extended Messages has been in the BGPSec draft = since the beginning (at least the WG -00 version). Changing it now = would mean a significant deviation in the process =E2=80=93 but not = impossible. >=20 > Before committing to supporting any change to the document, I would = like to see changes discussed in the sidr WG list. You may even be able = to convince the sidrops Chairs to give you some time in Chicago to = discuss in person. We would need the WG to reach consensus for such a = change. >=20 >=20 > [Speaking as WG Participant] >=20 > I think that a possible path forward is to take any reference to the = Extended Messages document out, and simply put text similar to this in = (from Sriram=E2=80=99s message): >=20 > =E2=80=9CBGPsec update size is subject to a maximum BGP update size. = The maximum size at present is 4096 bytes [RFC4271], and it may be = extended to a larger size in the future. If the sending router = determines that adding its Secure_Path Segment and Signature Segment = causes the BGPsec update to exceed the maximum size, then it will = convert the BGPsec update to an unsigned traditional BGP update [using = the procedure in Section 4.4] and send the unsigned update. (Note: = Please see related discussion in Section 7.)=E2=80=9D >=20 > I would even just mention the =E2=80=9Cmaximum message size=E2=80=9D = (with no specific numbers) and leave out mention of any future changes. = This way the BGPSec documents (1) don=E2=80=99t depend on the Extended = Messages document, and (2) they depend on whatever BGP can do. If/when = Extended Messages are settled and implemented then BGPSec can make use = of them (as can any other application using BGP). >=20 >=20 > Thanks! >=20 > Alvaro. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 3/14/17, 6:26 PM, "Sriram, Kotikalapudi (Fed)" = > = wrote: >=20 > > Alvaro replied to me in detail. --Apple-Mail=_38823FDC-80EB-4BD4-AB49-B746C663C239 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I=E2=80=99m behind on mail but Sriram = suggested I pay attention to this, so here=E2=80=99s a drive-by comment, = and if this comes up in SIDROps in Chicago I=E2=80=99ll do my best to = attend and participate in the discussion there. 

Being pragmatic, I = understand that the risk is low for exceeding the max size without = extended message support based on the average AS-path length, but I have = concerns about the suggested solution that treats unsigned updates as a = fallback path for updates that would otherwise be too large. First, I = don=E2=80=99t believe that there is any construct within the current = BGPSec setup that allows for this sort of mixed mode where most updates = are signed but some subset are not. Normally it=E2=80=99s something = negotiated on session establish - either BGPSec is supported by both = neighbors, or it is not - and the BGP machinery handles updates = accordingly. So likely the document would need some additional guidance = on how that mixed mode is supposed to work. I think it=E2=80=99s pretty = straightforward since there is already a defined process for stripping = signatures and sending unsigned updates, but there=E2=80=99s sufficient = grey area that I am not comfortable leaving this =E2=80=9Cas an exercise = for the implementer=E2=80=9D since it needs to properly interoperate. = And if what is being suggested is that one update being too large drops = the entire session back to unsecured mode, that seems even = worse.

More = generally, I have expressed concern in the past (including quite = publicly at NANOG) about =E2=80=9Cfailing open=E2=80=9D and the impacts = of this model. While it=E2=80=99s definitely the lower-risk method when = we=E2=80=99re dealing with something as critical as routing updates, it = has the net effect of creating situations where the very benefit gained = by deploying the technology is negated because any number of problems = can cause fallback to the unsecured model that is effectively the same = as having not deployed in the first place. The deployment threshold for = things like this is usually that the net improvement in protection has = to be worth the increased overhead of deployment and maintenance. I have = been having trouble making the argument that OV and PV fall on the right = side of that line due to the amount of places where things fail open by = design. Some of those concerns are addressed by work in progress to move = away from rsync and address other potential failure cases, but the = potential for what amounts to a silent failure where some subset of = routes on a session that I expect to be secured suddenly are not seems = high in this case, and thus I don=E2=80=99t see this as an acceptable = tradeoff. 

Given the headwinds for deployment of path validation - it = requires a certain level of hardware support (CPU/Memory) to deploy at = real scale, software features that haven=E2=80=99t been implemented yet, = etc., I don=E2=80=99t see a delay while we get extended message support = sorted as any really serious deal-breaker. Realistically, vendors and = operators will be better served if this set of features can be = implemented as a group to minimize the amount of touching and = re-touching the same area of code and certifying and deploying multiple = code versions to get everything. In other words, if I were deciding on a = deployment timeline, I=E2=80=99d plan to wait until a critical mass of = features is available either way, so whether that waiting happens now or = later, the result is the same, and the better focus would be to get = Extended Messages moved through the process with all possible haste = instead of trying to pull BGPSec back for late-stage changes to reduce = its dependency on the former. 


Wes = George

On Mar 15, 2017, at 9:44 AM, Alvaro Retana (aretana) <aretana@cisco.com> = wrote:

Hi!
 
[Speaking as AD] 
 
The requirement for Extended Messages has been in = the BGPSec draft since the beginning (at least the WG -00 = version).  Changing it now would mean a significant deviation in = the process =E2=80=93 but not impossible.
 
Before committing to supporting any change to the document, I = would like to see changes discussed in the sidr WG list.  You may = even be able to convince the sidrops Chairs to give you some time in = Chicago to discuss in person.  We would need the WG to reach = consensus for such a change.
 
 
[Speaking as WG Participant]
 
I think that a possible path forward is to take any reference = to the Extended Messages document out, and simply put text similar to = this in (from Sriram=E2=80=99s message):
 
=E2=80=9CBGPsec update size is subject to a maximum BGP = update size. The maximum size at present is 4096 bytes [RFC4271], and it = may be extended to a larger size in the future. If the sending router = determines that adding its Secure_Path Segment and Signature Segment = causes the BGPsec update to exceed the maximum size, then it will = convert the BGPsec update to an unsigned traditional BGP update [using = the procedure in Section 4.4] and send the unsigned update. (Note: = Please see related discussion in Section 7.)=E2=80=9D
 
I would even just mention the =E2=80=9Cmaximum message = size=E2=80=9D (with no specific numbers) and leave out mention of any = future changes.  This way the BGPSec documents (1) don=E2=80=99t = depend on the Extended Messages document, and (2) they depend on = whatever BGP can do.  If/when Extended Messages are settled and = implemented then BGPSec can make use of them (as can any other = application using BGP).
 
 
Thanks!
 
Alvaro.
 
 
 
 
 
 
 
 
On 3/14/17, = 6:26 PM, "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov> wrote:
 
> Alvaro = replied to me in detail. 

= --Apple-Mail=_38823FDC-80EB-4BD4-AB49-B746C663C239-- --Apple-Mail=_63016B99-F777-4929-A6DF-D3A4C87C9E29 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----- iQIcBAEBCgAGBQJYyYTBAAoJEBdIPc22E6UhvfIP/jLa5c1jChsYZ8PJIPF3XzPx q05KjBSLdwqE96PpKeiUAh/i7pIylHC+U8SRrSfZGv5TnJgOsusFJPZUZOkAB2E0 fSlOVbnkIuuzL7hCvt7My7PHpa0ufSAPqk0sdf2wPmVnoEh6FtNSc6cVVxv7Lm8h rrQMVtMUTFushXgzvYqpqbxvk6rmQ9/ca3YRSV8SFKcY692hXAuxP5b021TSKI88 WkxuwS1gM/MiZcqSsXpzRq3XGi8zPt53QbCADU7l1MIEijUfneMwxFk1Fj/0J2r/ H5jFrZsDZnecxRCXIuihIbwlLP7G9n6S9Iwpp9OtK/fVc8w4QX/dt1jc+yqYEdX9 GPE1+VSeYrRWwWujIymzSfZaJ2EH7OCCFNLloq9G/VIdaZzyjWl1pTXVSLmKTOen WA+D90ie7wuK8+sSOqDsEkI53MB7exUE71O3tcjHu552HdSKheTEfmVJBdz5rhOe /LTbmW2kLCR+Qa8KjKlvVjjSJezldGS2yWJpHVoKQ4zElzyDsMde464Tx8pL2xu2 bVXDQbKucz3Ohkxaf+WoWxbyLyjQnS/38xPjYTXOs/Cehxqzzk3vwO/i8SlyexeK noRC4JXrAQBhHHsC0GglUUmGWOKBa7mZ5q4LQHJsj4qsdLOC9seaeYyxEsA8AqpR jvuoWKyjWnmrlgz289mC =xPn6 -----END PGP SIGNATURE----- --Apple-Mail=_63016B99-F777-4929-A6DF-D3A4C87C9E29-- From nobody Wed Mar 15 15:19:00 2017 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 37609129C4A; Wed, 15 Mar 2017 15:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3x-SPsjVUUIj; Wed, 15 Mar 2017 15:18:55 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0114.outbound.protection.outlook.com [23.103.201.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BB60129C2F; Wed, 15 Mar 2017 15:18:54 -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=lqEwXRnAeH8a4q+S7KQJO2b7wvf2wGMCH01R6zQP4gY=; b=OIH1n3GldmXaktJxXbpNV9/tNABmB1La6RakW/wO/UUkhLDRc+ErxmYE+Wdlv2/2Ct2iVfiS2slpVUyWLhUU4mJXH02QUyf0gHPgKQ/YV3iU9S95oTpWpMcc020TNSpkswmDWU0tTnzgs64XqRtpiclH4PHB+Vghc0YSLWc+1ic= 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 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Wed, 15 Mar 2017 22:18:52 +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.0961.021; Wed, 15 Mar 2017 22:18:52 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Wes George , "Alvaro Retana (aretana)" CC: Randy Bush , Steve KENT , "sidr wg list" , Matthias Waehlisch , "sidr-chairs@ietf.org" , Sean Turner , "sidrops@ietf.org" Thread-Topic: [sidr] BGPsec draft and extended messages Thread-Index: AdKcN8SBuyxP2TUmTMSCIN0IJlVFkAAEOhsAACVRtkMAChNseAABALyAAACP7LIAIXQFgAAJcw6AAAhP9PA= Date: Wed, 15 Mar 2017 22:18:52 +0000 Message-ID: References: <4CF183FB-F22F-4133-BE91-86CA44DBEDBE@puck.nether.net> In-Reply-To: <4CF183FB-F22F-4133-BE91-86CA44DBEDBE@puck.nether.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: puck.nether.net; dkim=none (message not signed) header.d=none;puck.nether.net; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.110.145] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0446; 7:L6Gb0v9iXJyvsW4pARL0H6iaqQR+vHpV5vROYRk10JpllogvFj6ppxAjrs+RN+oGbShZzfm9TzKSZgSuZIWMg1d4LTnqzuS5h1FcS1gTWWiD3590wC/qsw1Gjy7yfXQWvombfLQH83SIAelDQyIxTFxbc9GPVDZyQJalFyvIMBrVChoB/syAeDxWhLTAhv5qRuAPqNiDm5+UXdKAtMbrvazyE+cTwHkXlmJJ/PgYrjPh0PwxuVQpc8EapmBFyWCrLRATHb3L2DsOLdJNN33EIwGrDgB61FoROZ9iSN8zYPpc7aSzUUCqlstWroG6LnRwkc7E4RdZ0HicL45AOcj9Ng== x-ms-office365-filtering-correlation-id: 71930e5e-a723-4acc-63bd-08d46bf14309 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:DM2PR09MB0446; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(20161123558025)(6072148); SRVR:DM2PR09MB0446; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0446; x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39450400003)(39850400002)(39410400002)(4326008)(6246003)(102836003)(6116002)(38730400002)(189998001)(2906002)(6506006)(10710500007)(74316002)(93886004)(33656002)(790700001)(50986999)(606005)(8936002)(7110500001)(54356999)(3280700002)(66066001)(3660700001)(6436002)(19609705001)(15650500001)(5660300001)(99286003)(55016002)(6306002)(77096006)(53936002)(9686003)(236005)(54906002)(122556002)(76176999)(3846002)(2900100001)(2950100002)(2420400007)(7696004)(54896002)(7906003)(8676002)(7736002)(81166006)(229853002)(86362001)(25786008); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0446; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR09MB0446CCB7DE24681F23429D7784270DM2PR09MB0446namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2017 22:18:52.0655 (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: Subject: Re: [sidr] BGPsec draft and extended messages X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 22:18:57 -0000 --_000_DM2PR09MB0446CCB7DE24681F23429D7784270DM2PR09MB0446namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2VzLA0KDQoNCkNvbW1lbnRzIGlubGluZSBiZWxvdyBtYXJrZWQgd2l0aCBba3NdLg0KDQoNCj4N Cj5CZWluZyBwcmFnbWF0aWMsIEkgdW5kZXJzdGFuZCB0aGF0IHRoZSByaXNrIGlzIGxvdyBmb3Ig ZXhjZWVkaW5nIHRoZSBtYXggc2l6ZSB3aXRob3V0IGV4dGVuZGVkIG1lc3NhZ2Ugc3VwcG9ydCBi YXNlZCBvbiB0aGUgYXZlcmFnZSBBUy1wYXRoIGxlbmd0aCwgYnV0IEkgaGF2ZSBjb25jZXJucyBh Ym91dCB0aGUgc3VnZ2VzdGVkIHNvbHV0aW9uIHRoYXQgdHJlYXRzIHVuc2lnbmVkIHVwZGF0ZXMg YXMgYSBmYWxsYmFjayBwYXRoIGZvciB1cGRhdGVzIHRoYXQgd291bGQgb3RoZXJ3aXNlIGJlIHRv byBsYXJnZS4NCj4NCg0KDQpba3NdIFRoZXJlIHNlZW1zIHRvIGJlIHNvbWUgbWlzdW5kZXJzdGFu ZGluZyBoZXJlLiBMZXQgbWUgdHJ5IHRvIGNsYXJpZnkuDQoNCg0KW2tzXSBUaGUgcHJvcG9zZWQg Y2hhbmdlIGlzIHNpbXBseSB0aGF0IEJHUHNlYyBzcGVjaWZpY2F0aW9uIGFja25vd2xlZGdlcyB0 aGF0IHRoZXJlIGlzIGEgbWF4aW11bSBtZXNzYWdlIHNpemUsIHdoaWNoIGlzIHByb3ZpZGVkIGJ5 IEJHUC4gKFRoYXQgaXMgNDA5NiBieXRlcyBtYXhpbXVtIHNpemUgY3VycmVudGx5IGFuZCBpbiB0 aGUgZnV0dXJlIGl0IG1heSBiZSBtb3JlLikgQkdQc2VjIHNpbXBseSBhYmlkZXMgYnkgdGhlIG1h eGltdW0gc2l6ZS4gVGhlbiB0aGUgZGVzaWduIHF1ZXN0aW9uIGlzOiBXaGF0IGRvZXMgdGhlIHNl bmRpbmcgQkdQc2VjIHJvdXRlciBkbyB3aGVuIGl0IGZpbmRzIHRoYXQgYnkgYWRkaW5nIGl0cyBT ZWN1cmVfUGF0aCBhbmQgU2lnbmF0dXJlIFNlZ21lbnQsIHRoZSBzaXplIGV4Y2VlZHMgdGhlIG1h eGltdW0gbWVzc2FnZSBzaXplPyAoVGhpcyBxdWVzdGlvbiBuZWVkcyB0byBiZSBhZGRyZXNzZWQg aW5kZXBlbmRlbnQgb2YgdGhlIGFjdHVhbCB2YWx1ZSBvZiB0aGUgbWF4aW11bSBzaXplIHByb3Zp ZGVkIGJ5IEJHUC4pDQoNCg0KW2tzXSBUaGUgc2Vjb25kYXJ5IHF1ZXN0aW9uIGlzIGhvdyBvZnRl biBkb2VzIGl0IGhhcHBlbiAoaS5lLiBleGNlZWRpbmcgdGhlIG1heGltdW0gc2l6ZSk/ICBZb3Ug c2VlbWVkIHRvIHNheSDigJxyaXNrIGlzIGxvdyBmb3IgZXhjZWVkaW5nIHRoZSBtYXggc2l6ZSB3 aXRob3V0IGV4dGVuZGVkIG1lc3NhZ2Ugc3VwcG9ydCBiYXNlZCBvbiB0aGUgKiphdmVyYWdlKiog QVMtcGF0aCBsZW5ndGgu4oCdICBBY3R1YWxseSwgdGhlIHdvcnN0LWNhc2UgQVMtcGF0aCBsZW5n dGggd2FzIHVzZWQuIFBsZWFzZSBzZWUgdGhlIGFuYWx5c2lzIGluIG15IHByZXZpb3VzIHBvc3Qu DQoNCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaWRyL2N1cnJlbnQv bXNnMDg1MDIuaHRtbA0KDQoNCj5GaXJzdCwgSSBkb27igJl0IGJlbGlldmUgdGhhdCB0aGVyZSBp cyBhbnkgY29uc3RydWN0IHdpdGhpbiB0aGUgY3VycmVudCBCR1BTZWMgc2V0dXAgdGhhdCBhbGxv d3MgZm9yIHRoaXMgc29ydCBvZiBtaXhlZCBtb2RlIHdoZXJlIG1vc3QgdXBkYXRlcyBhcmUgc2ln bmVkIGJ1dCBzb21lIHN1YnNldCBhcmUgbm90LiBOb3JtYWxseSBpdOKAmXMgc29tZXRoaW5nIG5l Z290aWF0ZWQgb24gc2Vzc2lvbiBlc3RhYmxpc2ggLSBlaXRoZXIgQkdQU2VjIGlzIHN1cHBvcnRl ZCBieSBib3RoIG5laWdoYm9ycywgb3IgaXQgaXMgbm90IC0gYW5kIHRoZSBCR1AgbWFjaGluZXJ5 IGhhbmRsZXMgdXBkYXRlcyBhY2NvcmRpbmdseS4NCg0KDQpba3NdIFdoZW4gQkdQc2VjIGlzIG5l Z290aWF0ZWQsIGl0IHNpbXBseSBtZWFucyB0aGF0IHRoZSByb3V0ZXIgY2FuIHNlbmQvcmVjZWl2 ZSBCR1BzZWMgdXBkYXRlcy4gVHJhZGl0aW9uYWwgdW5zaWduZWQgdXBkYXRlcyBjYW4gc3RpbGwg YmUgZXhjaGFuZ2VkIG9uIHRoYXQgc2Vzc2lvbiBhcyBuZWNlc3NhcnkuIFRoaXMgd2FzIHBhcnQg b2YgdGhlIGRlc2lnbiBmcm9tIHRoZSBzdGFydC4gVGhhdOKAmXMgYmVjYXVzZSBhbiBBUyBtYXkg bmVnb3RpYXRlIEJHUHNlYyB3aXRoIGEgcGVlciBidXQgY2FuIGhhdmUgYSBjdXN0b21lciB0aGF0 IGlzIG5vdCB1cGdyYWRlZCB0byBCR1BzZWMuIE9uY2UgYSBCR1BzZWMgc2Vzc2lvbiBpcyBlc3Rh Ymxpc2hlZCwgYW4gdXBkYXRlIG1heSBoYXZlIEJHUHNlY19QYXRoIG9yICh1bnNpZ25lZCkgQVNf UEFUSCBhdHRyaWJ1dGUsIGJ1dCBub3QgYm90aC4gU2VlIHNlY3Rpb24gMi4yLCBwLjU6DQoNCg0K 4oCcQkdQIHVwZGF0ZSBtZXNzYWdlcyB3aXRob3V0IHRoZSBCR1BzZWNfUGF0aCBhdHRyaWJ1dGUg KGkuZS4gdW5zaWduZWQgdXBkYXRlcykgTUFZIGJlDQogICBzZW50IHdpdGhpbiBhIHNlc3Npb24g cmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB0aGUgdXNlIG9mIEJHUHNlYw0KICAgaXMgc3Vj Y2Vzc2Z1bGx5IG5lZ290aWF0ZWQu4oCdDQoNCg0KPlNvIGxpa2VseSB0aGUgZG9jdW1lbnQgd291 bGQgbmVlZCBzb21lIGFkZGl0aW9uYWwgZ3VpZGFuY2Ugb24gaG93IHRoYXQgbWl4ZWQgbW9kZSBp cyBzdXBwb3NlZCB0byB3b3JrLiBJIHRoaW5rIGl04oCZcyBwcmV0dHkgc3RyYWlnaHRmb3J3YXJk IHNpbmNlIHRoZXJlIGlzIGFscmVhZHkgYSBkZWZpbmVkIHByb2Nlc3MgZm9yIHN0cmlwcGluZyBz aWduYXR1cmVzIGFuZCBzZW5kaW5nIHVuc2lnbmVkIHVwZGF0ZXMsIGJ1dCB0aGVyZeKAmXMgc3Vm ZmljaWVudCBncmV5IGFyZWEgdGhhdCBJIGFtIG5vdCBjb21mb3J0YWJsZSBsZWF2aW5nIHRoaXMg 4oCcYXMgYW4gZXhlcmNpc2UgZm9yIHRoZSBpbXBsZW1lbnRlcuKAnSBzaW5jZSBpdCBuZWVkcyB0 byBwcm9wZXJseSBpbnRlcm9wZXJhdGUuDQoNCg0KW2tzXSBQbGVhc2Ugc2VlIG15IHJlc3BvbnNl IGFib3ZlLiBIb3dldmVyLCBpdCBpcyB3b3J0aCBkb3VibGUgY2hlY2tpbmcgdG8gbWFrZSBzdXJl IHRoYXQgd2hhdCB5b3UgYXJlIHN1Z2dlc3RpbmcgaXMgc3RhdGVkIGNsZWFybHkgaW4gdGhlIGRv Y3VtZW50LiBJ4oCZbGwgZG8gdGhhdC4NCg0KDQo+QW5kIGlmIHdoYXQgaXMgYmVpbmcgc3VnZ2Vz dGVkIGlzIHRoYXQgb25lIHVwZGF0ZSBiZWluZyB0b28gbGFyZ2UgZHJvcHMgdGhlIGVudGlyZSBz ZXNzaW9uIGJhY2sgdG8gdW5zZWN1cmVkIG1vZGUsIHRoYXQgc2VlbXMgZXZlbiB3b3JzZS4NCg0K DQpba3NdIE5vLiBUaGF0IGlzIG5vdCBiZWluZyBzdWdnZXN0ZWQuDQoNCg0KVGhhbmtzLg0KDQoN ClNyaXJhbQ0KDQoNCg0K --_000_DM2PR09MB0446CCB7DE24681F23429D7784270DM2PR09MB0446namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQt c3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5XZXMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Q29tbWVudHMgaW5saW5lIGJlbG93IG1hcmtl ZCB3aXRoIFtrc10uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDtCZWluZyBwcmFnbWF0aWMsIEkg dW5kZXJzdGFuZCB0aGF0IHRoZSByaXNrIGlzIGxvdyBmb3IgZXhjZWVkaW5nIHRoZSBtYXggc2l6 ZSB3aXRob3V0IGV4dGVuZGVkIG1lc3NhZ2Ugc3VwcG9ydCBiYXNlZCBvbiB0aGUgYXZlcmFnZSBB Uy1wYXRoIGxlbmd0aCwgYnV0IEkgaGF2ZSBjb25jZXJucyBhYm91dCB0aGUNCiBzdWdnZXN0ZWQg c29sdXRpb24gdGhhdCB0cmVhdHMgdW5zaWduZWQgdXBkYXRlcyBhcyBhIGZhbGxiYWNrIHBhdGgg Zm9yIHVwZGF0ZXMgdGhhdCB3b3VsZCBvdGhlcndpc2UgYmUgdG9vIGxhcmdlLg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OzxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPltrc10gVGhlcmUgc2VlbXMgdG8gYmUgc29tZSBtaXN1bmRlcnN0YW5kaW5n IGhlcmUuIExldCBtZSB0cnkgdG8gY2xhcmlmeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5ba3NdIFRoZSBwcm9wb3Nl ZCBjaGFuZ2UgaXMgc2ltcGx5IHRoYXQgQkdQc2VjIHNwZWNpZmljYXRpb24gYWNrbm93bGVkZ2Vz IHRoYXQgdGhlcmUgaXMgYSBtYXhpbXVtIG1lc3NhZ2Ugc2l6ZSwgd2hpY2ggaXMgcHJvdmlkZWQg YnkgQkdQLiAoVGhhdCBpcyA0MDk2IGJ5dGVzIG1heGltdW0gc2l6ZSBjdXJyZW50bHkNCiBhbmQg aW4gdGhlIGZ1dHVyZSBpdCBtYXkgYmUgbW9yZS4pIEJHUHNlYyBzaW1wbHkgYWJpZGVzIGJ5IHRo ZSBtYXhpbXVtIHNpemUuIFRoZW4gdGhlIGRlc2lnbiBxdWVzdGlvbiBpczogV2hhdCBkb2VzIHRo ZSBzZW5kaW5nIEJHUHNlYyByb3V0ZXIgZG8gd2hlbiBpdCBmaW5kcyB0aGF0IGJ5IGFkZGluZyBp dHMgU2VjdXJlX1BhdGggYW5kIFNpZ25hdHVyZSBTZWdtZW50LCB0aGUgc2l6ZSBleGNlZWRzIHRo ZSBtYXhpbXVtIG1lc3NhZ2Ugc2l6ZT8NCiAoVGhpcyBxdWVzdGlvbiBuZWVkcyB0byBiZSBhZGRy ZXNzZWQgaW5kZXBlbmRlbnQgb2YgdGhlIGFjdHVhbCB2YWx1ZSBvZiB0aGUgbWF4aW11bSBzaXpl IHByb3ZpZGVkIGJ5IEJHUC4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+W2tzXSBUaGUgc2Vjb25kYXJ5IHF1ZXN0aW9u IGlzIGhvdyBvZnRlbiBkb2VzIGl0IGhhcHBlbiAoaS5lLiBleGNlZWRpbmcgdGhlIG1heGltdW0g c2l6ZSk/Jm5ic3A7IFlvdSBzZWVtZWQgdG8gc2F5IOKAnHJpc2sgaXMgbG93IGZvciBleGNlZWRp bmcgdGhlIG1heCBzaXplIHdpdGhvdXQgZXh0ZW5kZWQgbWVzc2FnZSBzdXBwb3J0DQogYmFzZWQg b24gdGhlICoqYXZlcmFnZSoqIEFTLXBhdGggbGVuZ3RoLuKAnSZuYnNwOyBBY3R1YWxseSwgdGhl IHdvcnN0LWNhc2UgQVMtcGF0aCBsZW5ndGggd2FzIHVzZWQuIFBsZWFzZSBzZWUgdGhlIGFuYWx5 c2lzIGluIG15IHByZXZpb3VzIHBvc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9zaWRyL2N1cnJlbnQvbXNnMDg1MDIuaHRtbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaWRyL2N1cnJlbnQvbXNnMDg1MDIuaHRtbDwvc3Bhbj48 L2E+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Rmlyc3QsIEkgZG9u4oCZdCBiZWxpZXZl IHRoYXQgdGhlcmUgaXMgYW55IGNvbnN0cnVjdCB3aXRoaW4gdGhlIGN1cnJlbnQgQkdQU2VjIHNl dHVwIHRoYXQgYWxsb3dzIGZvciB0aGlzIHNvcnQgb2YgbWl4ZWQgbW9kZSB3aGVyZSBtb3N0IHVw ZGF0ZXMgYXJlIHNpZ25lZCBidXQgc29tZSBzdWJzZXQgYXJlIG5vdC4NCiBOb3JtYWxseSBpdOKA mXMgc29tZXRoaW5nIG5lZ290aWF0ZWQgb24gc2Vzc2lvbiBlc3RhYmxpc2ggLSBlaXRoZXIgQkdQ U2VjIGlzIHN1cHBvcnRlZCBieSBib3RoIG5laWdoYm9ycywgb3IgaXQgaXMgbm90IC0gYW5kIHRo ZSBCR1AgbWFjaGluZXJ5IGhhbmRsZXMgdXBkYXRlcyBhY2NvcmRpbmdseS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5b a3NdIFdoZW4gQkdQc2VjIGlzIG5lZ290aWF0ZWQsIGl0IHNpbXBseSBtZWFucyB0aGF0IHRoZSBy b3V0ZXIgY2FuIHNlbmQvcmVjZWl2ZSBCR1BzZWMgdXBkYXRlcy4gVHJhZGl0aW9uYWwgdW5zaWdu ZWQgdXBkYXRlcyBjYW4gc3RpbGwgYmUgZXhjaGFuZ2VkIG9uIHRoYXQgc2Vzc2lvbiBhcyBuZWNl c3NhcnkuDQogVGhpcyB3YXMgcGFydCBvZiB0aGUgZGVzaWduIGZyb20gdGhlIHN0YXJ0LiBUaGF0 4oCZcyBiZWNhdXNlIGFuIEFTIG1heSBuZWdvdGlhdGUgQkdQc2VjIHdpdGggYSBwZWVyIGJ1dCBj YW4gaGF2ZSBhIGN1c3RvbWVyIHRoYXQgaXMgbm90IHVwZ3JhZGVkIHRvIEJHUHNlYy4gT25jZSBh IEJHUHNlYyBzZXNzaW9uIGlzIGVzdGFibGlzaGVkLCBhbiB1cGRhdGUgbWF5IGhhdmUgQkdQc2Vj X1BhdGggb3IgKHVuc2lnbmVkKSBBU19QQVRIIGF0dHJpYnV0ZSwNCiBidXQgbm90IGJvdGguIFNl ZSBzZWN0aW9uIDIuMiwgcC41OiZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj7igJxCR1AgdXBkYXRlIG1lc3Nh Z2VzIHdpdGhvdXQgdGhlIEJHUHNlY19QYXRoIGF0dHJpYnV0ZSAoaS5lLiB1bnNpZ25lZCB1cGRh dGVzKSBNQVkgYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgc2VudCB3aXRoaW4gYSBzZXNzaW9uIHJlZ2FyZGxlc3Mg b2Ygd2hldGhlciBvciBub3QgdGhlIHVzZSBvZiBCR1BzZWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgaXMgc3VjY2Vz c2Z1bGx5IG5lZ290aWF0ZWQu4oCdJm5ic3A7DQo8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Y29sb3I6YmxhY2si PiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0O1NvIGxpa2VseSB0aGUgZG9jdW1lbnQgd291 bGQgbmVlZCBzb21lIGFkZGl0aW9uYWwgZ3VpZGFuY2Ugb24gaG93IHRoYXQgbWl4ZWQgbW9kZSBp cyBzdXBwb3NlZCB0byB3b3JrLiBJIHRoaW5rIGl04oCZcyBwcmV0dHkgc3RyYWlnaHRmb3J3YXJk IHNpbmNlIHRoZXJlIGlzIGFscmVhZHkgYSBkZWZpbmVkIHByb2Nlc3MNCiBmb3Igc3RyaXBwaW5n IHNpZ25hdHVyZXMgYW5kIHNlbmRpbmcgdW5zaWduZWQgdXBkYXRlcywgYnV0IHRoZXJl4oCZcyBz dWZmaWNpZW50IGdyZXkgYXJlYSB0aGF0IEkgYW0gbm90IGNvbWZvcnRhYmxlIGxlYXZpbmcgdGhp cyDigJxhcyBhbiBleGVyY2lzZSBmb3IgdGhlIGltcGxlbWVudGVy4oCdIHNpbmNlIGl0IG5lZWRz IHRvIHByb3Blcmx5IGludGVyb3BlcmF0ZS4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5ba3NdIFBsZWFz ZSBzZWUgbXkgcmVzcG9uc2UgYWJvdmUuIEhvd2V2ZXIsIGl0IGlzIHdvcnRoIGRvdWJsZSBjaGVj a2luZyB0byBtYWtlIHN1cmUgdGhhdCB3aGF0IHlvdSBhcmUgc3VnZ2VzdGluZyBpcyBzdGF0ZWQg Y2xlYXJseSBpbiB0aGUgZG9jdW1lbnQuIEnigJlsbCBkbyB0aGF0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDtB bmQgaWYgd2hhdCBpcyBiZWluZyBzdWdnZXN0ZWQgaXMgdGhhdCBvbmUgdXBkYXRlIGJlaW5nIHRv byBsYXJnZSBkcm9wcyB0aGUgZW50aXJlIHNlc3Npb24gYmFjayB0byB1bnNlY3VyZWQgbW9kZSwg dGhhdCBzZWVtcyBldmVuIHdvcnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPltrc10gTm8uIFRoYXQgaXMgbm90IGJl aW5nIHN1Z2dlc3RlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGFua3MuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+U3JpcmFtPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_DM2PR09MB0446CCB7DE24681F23429D7784270DM2PR09MB0446namp_-- From nobody Sat Mar 18 01:12:14 2017 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 D2E0E120724 for ; Sat, 18 Mar 2017 01:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSSnKnEXf7ku for ; Sat, 18 Mar 2017 01:12:10 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC9D12422F for ; Sat, 18 Mar 2017 01:12:10 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9C6D5B80D54; Sat, 18 Mar 2017 01:11:57 -0700 (PDT) To: randy@psg.com, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, morrowc@ops-netman.net, sandy@tislabs.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: achatz@forthnet.gr, sidr@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170318081157.9C6D5B80D54@rfc-editor.org> Date: Sat, 18 Mar 2017 01:11:57 -0700 (PDT) Archived-At: Subject: [sidr] [Editorial Errata Reported] RFC7115 (4973) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 08:12:13 -0000 The following errata report has been submitted for RFC7115, "Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7115&eid=4973 -------------------------------------- Type: Editorial Reported by: Tassos Chatzithomaoglou Section: 3 & 5 Original Text ------------- section 3 --------- For example, if, instead of 10.0.0.0/16-24, one issues 10.0.0.0/16 and 10.0.42.0/24, a forged origin attack cannot succeed against 10.0.666.0/24. section 5 --------- Consider having a ROA for AS 42 for prefix 10.0.0.0/16-24. A BGP announcement for 10.0.666.0/24 from AS 666 would be Invalid Corrected Text -------------- section 3 --------- For example, if, instead of 10.0.0.0/16-24, one issues 10.0.0.0/16 and 10.0.42.0/24, a forged origin attack cannot succeed against 10.0.66.0/24. section 5 --------- Consider having a ROA for AS 42 for prefix 10.0.0.0/16-24. A BGP announcement for 10.0.66.0/24 from AS 666 would be Invalid Notes ----- 666 is not a valid octet for an ipv4 address Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7115 (draft-ietf-sidr-origin-ops-23) -------------------------------------- Title : Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI) Publication Date : January 2014 Author(s) : R. Bush Category : BEST CURRENT PRACTICE Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Sat Mar 18 03:38:46 2017 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 67B45120727 for ; Sat, 18 Mar 2017 03:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsGwPIKjlyl7 for ; Sat, 18 Mar 2017 03:38:44 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E642D1250B8 for ; Sat, 18 Mar 2017 03:38:43 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cpBkp-0003An-BK; Sat, 18 Mar 2017 10:38:35 +0000 Date: Sat, 18 Mar 2017 05:38:34 -0500 Message-ID: From: Randy Bush To: RFC Errata System Cc: akatlas@gmail.com, db3546@att.com, aretana@cisco.com, morrowc@ops-netman.net, sandy@tislabs.com, achatz@forthnet.gr, sidr@ietf.org In-Reply-To: <20170318081157.9C6D5B80D54@rfc-editor.org> References: <20170318081157.9C6D5B80D54@rfc-editor.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [sidr] [Editorial Errata Reported] RFC7115 (4973) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 10:38:45 -0000 666 was not accidental. randy From nobody Sat Mar 18 07:00:20 2017 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 7952112708C; Sat, 18 Mar 2017 07:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iz8yms2nrJc; Sat, 18 Mar 2017 07:00:17 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7FC12751F; Sat, 18 Mar 2017 07:00:17 -0700 (PDT) Received: from [IPv6:2610:178:8::40f6:8f10:4485:ece9] (unknown [IPv6:2610:178:8:0:40f6:8f10:4485:ece9]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id E94FA540DC8; Sat, 18 Mar 2017 10:00:04 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_F70881C1-A36E-481D-9FCF-4C1BB9D239BD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Wes George In-Reply-To: Date: Sat, 18 Mar 2017 09:59:48 -0400 Cc: "Alvaro Retana (aretana)" , Randy Bush , Steve KENT , sidr wg list , Matthias Waehlisch , "sidr-chairs@ietf.org" , Sean Turner , "sidrops@ietf.org" Message-Id: References: <4CF183FB-F22F-4133-BE91-86CA44DBEDBE@puck.nether.net> To: "Sriram, Kotikalapudi (Fed)" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [sidr] BGPsec draft and extended messages X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 14:00:19 -0000 --Apple-Mail=_F70881C1-A36E-481D-9FCF-4C1BB9D239BD Content-Type: multipart/alternative; boundary="Apple-Mail=_5A39DCE0-59F0-4925-8677-58BA9BF971AE" --Apple-Mail=_5A39DCE0-59F0-4925-8677-58BA9BF971AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 15, 2017, at 6:18 PM, Sriram, Kotikalapudi (Fed) = wrote: >=20 > >First, I don=E2=80=99t believe that there is any construct within the = current BGPSec setup that allows for this sort of mixed mode where most = updates are signed but some subset are not. Normally it=E2=80=99s = something negotiated on session establish - either BGPSec is supported = by both neighbors, or it is not - and the BGP machinery handles updates = accordingly. >=20 >=20 > [ks] When BGPsec is negotiated, it simply means that the router can = send/receive BGPsec updates. Traditional unsigned updates can still be = exchanged on that session as necessary. This was part of the design from = the start. That=E2=80=99s because an AS may negotiate BGPsec with a peer = but can have a customer that is not upgraded to BGPsec. Once a BGPsec = session is established, an update may have BGPsec_Path or (unsigned) = AS_PATH attribute, but not both. See section 2.2, p.5: >=20 >=20 > =E2=80=9CBGP update messages without the BGPsec_Path attribute (i.e. = unsigned updates) MAY be > sent within a session regardless of whether or not the use of = BGPsec > is successfully negotiated.=E2=80=9D WG] My original email was insufficiently precise when expressing my = concern on this, as it was written in relative haste. I=E2=80=99ll try = again. I always interpreted this as allowing for updates that were never = secured (because the downstream neighbor doesn=E2=80=99t support it) to = be sent between BGPSec capable neighbors, as you explain above. This = makes perfect sense given BGPSec=E2=80=99s decision to not allow = partially-signed updates. My concern is that using this text as justification for updates that = otherwise would be secured (because they came through a path of = neighbors that all support BGPSec end to end) dropping back to insecure = on account of the size of the update violates the principle of least = astonishment and again allows for degraded security by failing open. Wes --Apple-Mail=_5A39DCE0-59F0-4925-8677-58BA9BF971AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Mar 15, 2017, at 6:18 PM, Sriram, Kotikalapudi (Fed) = <kotikalapudi.sriram@nist.gov> wrote:
 
>First, I = don=E2=80=99t believe that there is any construct within the current = BGPSec setup that allows for this sort of mixed mode where most updates = are signed but some subset are not. Normally it=E2=80=99s something = negotiated on session establish - either BGPSec is supported by both = neighbors, or it is not - and the BGP machinery handles updates = accordingly.
 
 
[ks] When BGPsec is negotiated, it simply means that the = router can send/receive BGPsec updates. Traditional unsigned updates can = still be exchanged on that session as necessary. This was part of the = design from the start. That=E2=80=99s because an AS may negotiate BGPsec = with a peer but can have a customer that is not upgraded to BGPsec. Once = a BGPsec session is established, an update may have BGPsec_Path or = (unsigned) AS_PATH attribute, but not both. See section 2.2, = p.5:  
 
 
=E2=80=9CBGP update messages without the BGPsec_Path = attribute (i.e. unsigned updates) MAY be
   sent = within a session regardless of whether or not the use of BGPsec
   is = successfully negotiated.=E2=80=9D   


WG] My original email = was insufficiently precise when expressing my concern on this, as it was = written in relative haste. I=E2=80=99ll try again. I always interpreted = this as allowing for updates that were never secured (because the = downstream neighbor doesn=E2=80=99t support it) to be sent between = BGPSec capable neighbors, as you explain above. This makes perfect sense = given BGPSec=E2=80=99s decision to not allow partially-signed = updates. 
My concern is that using this text as = justification for updates that otherwise would be secured (because they = came through a path of neighbors that all support BGPSec end to end) = dropping back to insecure on account of the size of the update violates = the principle of least astonishment and again allows for degraded = security by failing open.

Wes
= --Apple-Mail=_5A39DCE0-59F0-4925-8677-58BA9BF971AE-- --Apple-Mail=_F70881C1-A36E-481D-9FCF-4C1BB9D239BD 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----- iQIcBAEBCgAGBQJYzT1VAAoJEBdIPc22E6UhD28P/iRgJHCkSRe+wun3cMO0XgXZ Q7CRxkerks0fJ0tE+fM3P+uOz8tavvsPevwC0u6i/LopTblpZQv4wnKPCFlekc1B Lu9ogoxA18XwpA6rKVxW2Jc/4ZSyUA4SmKBcUnelbSReyN3uQTl3GoiLSMgQt5sA pQCpFD71Xqcfy2QLUk8giZac5nJT+rmuUlzAmFfiBf6mxBhaOXd1uZVPYng6GISJ IDdxWzM7yxTnoJWe2flbuY9/4wGBGXGVdOPF+YBL6pS1CQK/m7U+Ycy/lF1PEPFS 4GSvfPS6YiZMKBVgR8VmPJydMnBcS9EP5nSjFqZHI6X+IUjij1qzVCw5CYJIVaQ7 +WcGM2PpBOa8zCi+pY/pWwqmKQ9n55GdAf50wslQDt1yEprMkmVkXvTSBwKM4RMK p9oewhW7ykKmv6AnIu32QGDPzDyL8UwW4n4eKB4cKEAq4MAAIH4X/I6Gf5L86DI3 GeOfNbMx3AuTXvFmTO4Us6Methv95oaP4V48p2qNfDIJ2AUYr7QQZ29Xi54jxi/2 FN+YXj18ME0YLmxxUzQfFyrSv+OzviOOr9eMvQwX3unqxQpMALpPRGG7PByw6oLP 9JOXxjhAXBYri2KnEw1HKjeNDDB4nidYbIJBD+Ut7uSqcI8hvE2NIWg2726kO4Yv BSF4He48Z5JkRWlNIVop =QpJk -----END PGP SIGNATURE----- --Apple-Mail=_F70881C1-A36E-481D-9FCF-4C1BB9D239BD-- From nobody Tue Mar 21 08:41:51 2017 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 816F6129ADF; Tue, 21 Mar 2017 08:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUmon1nqgoed; Tue, 21 Mar 2017 08:41:47 -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 63CA5129B37; Tue, 21 Mar 2017 08:39:09 -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=AiUJHsScDjub6YXUXAEyIF7d21E3WJKoldp7+8LxWD8=; b=mIn9pk2JhUCem4ZAuncr3Z64Hcs4XtisVduMrTzBpLQLU7v2lQE7AQSMKus5ynymjjvHXTxoKmEsvMvmXxAnl2TeaX7q2vXIUK0yGjoec7e8yNnAuUJU0daV4350JXpiU2XD//AU9SW1Evi4ZY7ynLVb3huQk41cg6i6LESLWBo= 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 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Tue, 21 Mar 2017 15:39:06 +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.0977.019; Tue, 21 Mar 2017 15:39:06 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Wes George CC: "Alvaro Retana (aretana)" , Randy Bush , Steve KENT , sidr wg list , "Matthias Waehlisch" , "sidr-chairs@ietf.org" , Sean Turner , "sidrops@ietf.org" Thread-Topic: [sidr] BGPsec draft and extended messages Thread-Index: AdKcN8SBuyxP2TUmTMSCIN0IJlVFkAAEOhsAACVRtkMAChNseAABALyAAACP7LIAIXQFgAAJcw6AAAhP9PAAhaHeAACZP1lg Date: Tue, 21 Mar 2017 15:39:06 +0000 Message-ID: References: <4CF183FB-F22F-4133-BE91-86CA44DBEDBE@puck.nether.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: puck.nether.net; dkim=none (message not signed) header.d=none;puck.nether.net; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.110.145] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0446; 7:PjMlIdMJ0MoEi+vgGeLWUpbRtlLvXoZVQwVe7JGoxArDTGC6hnLYaGAf274ATBABkXrgJwqpW7739fYSh3+o4jOTFVGc5ZPTVvpj6UFaLrOXOlz/vBk7Jwj1LgWqI18LZau2Z0EtnSANSMRTzx/qU4AJs00AgQj4hjGJRrH04LaNgbmOv+4BPC5qur7Gjs9c1800m/Hyhel0KX0db0JBoDGqieZ5SF49Mk80YtEzylSMx4jW8Zy9yeIqDJLUe4EMtyn563go5PyLrEt9dARPuTenhh6Ug4LIHExi6JXJXv48tn8XaiSWNPG9XuyCJrW2RkxzVq1DmKDy4bngC1Yf2Q== x-ms-office365-filtering-correlation-id: a7139243-deae-48ef-e84b-08d470706929 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:DM2PR09MB0446; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123562025)(20161123558025)(20161123560025)(20161123564025)(6072148); SRVR:DM2PR09MB0446; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0446; x-forefront-prvs: 02530BD3AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39410400002)(39450400003)(39860400002)(39840400002)(50986999)(76176999)(7736002)(54356999)(110136004)(2900100001)(2420400007)(93886004)(7520500002)(38730400002)(229853002)(3846002)(122556002)(102836003)(6116002)(4326008)(6246003)(19609705001)(790700001)(7110500001)(77096006)(6506006)(3280700002)(53936002)(3660700001)(86362001)(25786008)(189998001)(8676002)(10710500007)(6436002)(54896002)(6306002)(54906002)(2906002)(15650500001)(9686003)(6916009)(2950100002)(99286003)(7696004)(66066001)(33656002)(55016002)(81166006)(8936002)(74316002)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0446; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR09MB0446455BBBCC27D9B3A82E11843D0DM2PR09MB0446namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2017 15:39:06.7443 (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: Subject: Re: [sidr] BGPsec draft and extended messages X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 15:41:50 -0000 --_000_DM2PR09MB0446455BBBCC27D9B3A82E11843D0DM2PR09MB0446namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2VzLA0KDQpUaGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9uLiBNeSBjb21tZW50cyBiZWxvdy4N Cg0KDQrigKYuLiBzbmlwIOKApi4NCj5XR10gTXkgb3JpZ2luYWwgZW1haWwgd2FzIGluc3VmZmlj aWVudGx5IHByZWNpc2Ugd2hlbiBleHByZXNzaW5nIG15IGNvbmNlcm4gb24gdGhpcywgYXMgaXQg d2FzIHdyaXR0ZW4gaW4gcmVsYXRpdmUgaGFzdGUuIEnigJlsbCB0cnkgYWdhaW4uIEkgYWx3YXlz IGludGVycHJldGVkIHRoaXMgYXMgYWxsb3dpbmcgZm9yIHVwZGF0ZXMgdGhhdCB3ZXJlIG5ldmVy IHNlY3VyZWQgKGJlY2F1c2UgdGhlIGRvd25zdHJlYW0gbmVpZ2hib3IgZG9lc27igJl0IHN1cHBv cnQgaXQpIHRvIGJlIHNlbnQgYmV0d2VlbiBCR1BTZWMgY2FwYWJsZSBuZWlnaGJvcnMsIGFzIHlv dSBleHBsYWluIGFib3ZlLiBUaGlzIG1ha2VzIHBlcmZlY3Qgc2Vuc2UgZ2l2ZW4gQkdQU2Vj4oCZ cyBkZWNpc2lvbiB0byBub3QgYWxsb3cgcGFydGlhbGx5LXNpZ25lZCB1cGRhdGVzLg0KDQoNCj5X R10gTXkgY29uY2VybiBpcyB0aGF0IHVzaW5nIHRoaXMgdGV4dCBhcyBqdXN0aWZpY2F0aW9uIGZv ciB1cGRhdGVzIHRoYXQgb3RoZXJ3aXNlIHdvdWxkIGJlIHNlY3VyZWQgKGJlY2F1c2UgdGhleSBj YW1lIHRocm91Z2ggYSBwYXRoIG9mIG5laWdoYm9ycyB0aGF0IGFsbCBzdXBwb3J0IEJHUFNlYyBl bmQgdG8gZW5kKSBkcm9wcGluZyBiYWNrIHRvIGluc2VjdXJlIG9uIGFjY291bnQgb2YgdGhlIHNp emUgb2YgdGhlIHVwZGF0ZSB2aW9sYXRlcyB0aGUgcHJpbmNpcGxlIG9mIGxlYXN0IGFzdG9uaXNo bWVudCBhbmQgYWdhaW4gYWxsb3dzIGZvciBkZWdyYWRlZCBzZWN1cml0eSBieSBmYWlsaW5nIG9w ZW4uDQoNCg0KQkdQc2VjX1BhdGggYXR0cmlidXRlIHNpemUgZG9lcyBub3QgZXhjZWVkIDRLLg0K RUNEU0EgUC0yNTYgc2lnbmF0dXJlIHNpemUgaXMgNjQgYnl0ZXMuDQpTbywgI2J5dGVzIGFkZGVk IHRvIEJHUHNlY19QYXRoIGFyZSBhYm91dCAxMDAgYnl0ZXMgcGVyIEFTLg0KRXh0ZW5kZWQgbWVz c2FnZSB3YXMgdGhvdWdodCB0byBiZSBuZWVkZWQgd2hlbiBSU0EtMjA0OCAoMjU2IGJ5dGVzIHNp Zykgd2FzIGluaXRpYWxseSBwcm9wb3NlZC4NCldpdGggUC0yNTYsIEJHUHNlY19QYXRoIGF0dHJp YnV0ZSBkb2VzIG5vdCBleGNlZWQgNEsgdXAgdG8gNDAgQVNlcyBpbiB0aGUgcGF0aC4NCihOb3Rl OiBBUyBwcmVwZW5kcyBhcmUgY29tcHJlc3NlZCBvdXQgZHVlIHRvIHVzZSBvZiBwQ291bnQuKQ0K SW4gdGhlIEludGVybmV0LCB0aGUgb2JzZXJ2ZWQgbWF4aW11bSBBUyBwYXRoIGxlbmd0aCBpcyAx NCBbSHVzdG9uXS4NClRoZSBtYXhpbXVtIEFTIHBhdGggbGVuZ3RoIGhhcyByZW1haW5lZCBpbiB0 aGlzIGJhbGwgcGFyayBmb3IgbWFueSB5ZWFycyBub3cuDQpUaGVyZWZvcmUsIGl0IGRvZXNu4oCZ dCBhcHBlYXIgdGhhdCDigJxkcm9wcGluZyBiYWNrIHRvIOKAnGluc2VjdXJlIG9uIGFjY291bnQg b2YNCnRoZSBzaXplIG9mIHRoZSB1cGRhdGXigJ0gIHdvdWxkIGhhcHBlbiBpbiBwcmFjdGljZS4N Cg0KDQpTbywgdGhlIHF1ZXN0aW9uIGlzOiBEb2VzIHRoZSBXRyBhZ3JlZSB0aGF0IHRoZSBleHRl bmRlZCBtZXNzYWdlcyBkcmFmdA0KY2FuIGJlIGFuIEluZm9ybWF0aXZlIHJhdGhlciB0aGFuIGEg Tm9ybWF0aXZlIHJlZmVyZW5jZT8NCg0KDQpBbHZhcm8gKHNwZWFraW5nIGFzIFdHIFBhcnRpY2lw YW50KSBzdWdnZXN0ZWQ6DQoNCg0K4oCcSSB3b3VsZCBldmVuIGp1c3QgbWVudGlvbiB0aGUg4oCc bWF4aW11bSBtZXNzYWdlIHNpemXigJ0gKHdpdGggbm8gc3BlY2lmaWMgbnVtYmVycykgYW5kIGxl YXZlIG91dCBtZW50aW9uIG9mIGFueSBmdXR1cmUgY2hhbmdlcy4gIFRoaXMgd2F5IHRoZSBCR1BT ZWMgZG9jdW1lbnRzICgxKSBkb27igJl0IGRlcGVuZCBvbiB0aGUgRXh0ZW5kZWQgTWVzc2FnZXMg ZG9jdW1lbnQsIGFuZCAoMikgdGhleSBkZXBlbmQgb24gd2hhdGV2ZXIgQkdQIGNhbiBkby4gIElm L3doZW4gRXh0ZW5kZWQgTWVzc2FnZXMgYXJlIHNldHRsZWQgYW5kIGltcGxlbWVudGVkIHRoZW4g QkdQU2VjIGNhbiBtYWtlIHVzZSBvZiB0aGVtIChhcyBjYW4gYW55IG90aGVyIGFwcGxpY2F0aW9u IHVzaW5nIEJHUCku4oCdDQoNCg0KU3RldmUgS2VudCBzYWlkIGVhcmxpZXIgaW4gdGhlIHRocmVh ZDoNCg0KDQrigJxJIHRoaW5rIGl0IG1ha2VzIHNlbnNlIHRvIG9taXQgdGhlIGV4dGVuZGVkIG1l c3NhZ2UgZmVhdHVyZSwgZ2l2ZW4gdGhlIHVzZSBvZiBFQ0RTQSBQLTI1Ni7igJ0NCg0KDQpTcmly YW0NCg0KDQoNCg== --_000_DM2PR09MB0446455BBBCC27D9B3A82E11843D0DM2PR09MB0446namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVy dGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5XZXMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgdGhlIGNsYXJpZmljYXRp b24uIE15IGNvbW1lbnRzIGJlbG93LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKApi4uIHNuaXAg4oCmLjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtXR10gTXkgb3JpZ2luYWwg ZW1haWwgd2FzIGluc3VmZmljaWVudGx5IHByZWNpc2Ugd2hlbiBleHByZXNzaW5nIG15IGNvbmNl cm4gb24gdGhpcywgYXMgaXQgd2FzIHdyaXR0ZW4gaW4gcmVsYXRpdmUgaGFzdGUuIEnigJlsbCB0 cnkgYWdhaW4uIEkgYWx3YXlzIGludGVycHJldGVkIHRoaXMgYXMgYWxsb3dpbmcgZm9yIHVwZGF0 ZXMgdGhhdCB3ZXJlIG5ldmVyIHNlY3VyZWQgKGJlY2F1c2UgdGhlIGRvd25zdHJlYW0NCiBuZWln aGJvciBkb2VzbuKAmXQgc3VwcG9ydCBpdCkgdG8gYmUgc2VudCBiZXR3ZWVuIEJHUFNlYyBjYXBh YmxlIG5laWdoYm9ycywgYXMgeW91IGV4cGxhaW4gYWJvdmUuIFRoaXMgbWFrZXMgcGVyZmVjdCBz ZW5zZSBnaXZlbiBCR1BTZWPigJlzIGRlY2lzaW9uIHRvIG5vdCBhbGxvdyBwYXJ0aWFsbHktc2ln bmVkIHVwZGF0ZXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O1dHXSBNeSBjb25jZXJuIGlz IHRoYXQgdXNpbmcgdGhpcyB0ZXh0IGFzIGp1c3RpZmljYXRpb24gZm9yIHVwZGF0ZXMgdGhhdCBv dGhlcndpc2Ugd291bGQgYmUgc2VjdXJlZCAoYmVjYXVzZSB0aGV5IGNhbWUgdGhyb3VnaCBhIHBh dGggb2YgbmVpZ2hib3JzIHRoYXQgYWxsIHN1cHBvcnQgQkdQU2VjIGVuZCB0byBlbmQpIGRyb3Bw aW5nIGJhY2sgdG8gaW5zZWN1cmUgb24gYWNjb3VudCBvZiB0aGUgc2l6ZSBvZg0KIHRoZSB1cGRh dGUgdmlvbGF0ZXMgdGhlIHByaW5jaXBsZSBvZiBsZWFzdCBhc3RvbmlzaG1lbnQgYW5kIGFnYWlu IGFsbG93cyBmb3IgZGVncmFkZWQgc2VjdXJpdHkgYnkgZmFpbGluZyBvcGVuLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJHUHNlY19Q YXRoIGF0dHJpYnV0ZSBzaXplIGRvZXMgbm90IGV4Y2VlZCA0Sy48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ RUNEU0EgUC0yNTYgc2lnbmF0dXJlIHNpemUgaXMgNjQgYnl0ZXMuIDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+U28sICNieXRlcyBhZGRlZCB0byBCR1BzZWNfUGF0aCBhcmUg YWJvdXQgMTAwIGJ5dGVzIHBlciBBUy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkV4dGVuZGVkIG1lc3NhZ2Ugd2FzIHRob3VnaHQgdG8gYmUgbmVlZGVkIHdoZW4gUlNBLTIw NDggKDI1NiBieXRlcyBzaWcpIHdhcyBpbml0aWFsbHkgcHJvcG9zZWQuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRoIFAtMjU2LCBCR1BzZWNfUGF0aCBhdHRyaWJ1dGUg ZG9lcyBub3QgZXhjZWVkIDRLIHVwIHRvIDQwIEFTZXMgaW4gdGhlIHBhdGguPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oTm90ZTogQVMgcHJlcGVuZHMgYXJlIGNvbXByZXNz ZWQgb3V0IGR1ZSB0byB1c2Ugb2YgcENvdW50Lik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkluIHRoZSBJbnRlcm5ldCwgdGhlIG9ic2VydmVkIG1heGltdW0gQVMgcGF0aCBs ZW5ndGggaXMgMTQgW0h1c3Rvbl0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgbWF4aW11bSBBUyBwYXRoIGxlbmd0aCBoYXMgcmVtYWluZWQgaW4gdGhpcyBiYWxsIHBh cmsgZm9yIG1hbnkgeWVhcnMgbm93Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGVyZWZvcmUsIGl0IGRvZXNu4oCZdCBhcHBlYXIgdGhhdCDigJxkcm9wcGluZyBiYWNr IHRvIOKAnGluc2VjdXJlIG9uIGFjY291bnQgb2YNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+dGhlIHNpemUgb2YgdGhlIHVwZGF0ZeKAnSZuYnNwOyB3b3VsZCBoYXBwZW4g aW4gcHJhY3RpY2UuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvLCB0aGUgcXVlc3Rpb24gaXM6IERvZXMgdGhlIFdH IGFncmVlIHRoYXQgdGhlIGV4dGVuZGVkIG1lc3NhZ2VzIGRyYWZ0DQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNhbiBiZSBhbiBJbmZvcm1hdGl2ZSByYXRoZXIgdGhhbiBh IE5vcm1hdGl2ZSByZWZlcmVuY2U/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWx2YXJvIChzcGVha2luZyBhcyBXRyBQ YXJ0aWNpcGFudCkgc3VnZ2VzdGVkOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnEkgd291bGQgZXZlbiBqdXN0IG1l bnRpb24gdGhlIOKAnG1heGltdW0gbWVzc2FnZSBzaXpl4oCdICh3aXRoIG5vIHNwZWNpZmljIG51 bWJlcnMpIGFuZCBsZWF2ZSBvdXQgbWVudGlvbiBvZiBhbnkgZnV0dXJlIGNoYW5nZXMuJm5ic3A7 IFRoaXMgd2F5IHRoZSBCR1BTZWMgZG9jdW1lbnRzICgxKSBkb27igJl0IGRlcGVuZCBvbiB0aGUg RXh0ZW5kZWQgTWVzc2FnZXMgZG9jdW1lbnQsIGFuZCAoMikgdGhleSBkZXBlbmQgb24gd2hhdGV2 ZXINCiBCR1AgY2FuIGRvLiZuYnNwOyBJZi93aGVuIEV4dGVuZGVkIE1lc3NhZ2VzIGFyZSBzZXR0 bGVkIGFuZCBpbXBsZW1lbnRlZCB0aGVuIEJHUFNlYyBjYW4gbWFrZSB1c2Ugb2YgdGhlbSAoYXMg Y2FuIGFueSBvdGhlciBhcHBsaWNhdGlvbiB1c2luZyBCR1ApLuKAnTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN0ZXZl IEtlbnQgc2FpZCBlYXJsaWVyIGluIHRoZSB0aHJlYWQ6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCcSSB0aGluayBp dCBtYWtlcyBzZW5zZSB0byBvbWl0IHRoZSBleHRlbmRlZCBtZXNzYWdlIGZlYXR1cmUsIGdpdmVu IHRoZSB1c2Ugb2YgRUNEU0EgUC0yNTYu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3JpcmFtPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM2PR09MB0446455BBBCC27D9B3A82E11843D0DM2PR09MB0446namp_-- From nobody Tue Mar 21 11:00:58 2017 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 09027129C58; Tue, 21 Mar 2017 11:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xq7E8riBEcZw; Tue, 21 Mar 2017 11:00:38 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0114.outbound.protection.outlook.com [23.103.200.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 403C6129C43; Tue, 21 Mar 2017 11:00:38 -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=MtlZXKhMN2w6ttqnjcOR4pO7BvG72Tnzd7z/mUAwiB0=; b=d/VjByct7fNy3HPQRLOhbeaRpRHJIE9t7pfX97ajE6cOhG4pOjSavqOHUu9ijepaHi9xn+1XnEKkiPcGREicjJOT60OnuIfFZwcKq8ZGBcitzm2IYiWYiS8X+saU0NmQjOxphOGlX4pw+TYEoRimptGpdYDyNl88qdyNFKYZKtM= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0445.namprd09.prod.outlook.com (10.161.252.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Tue, 21 Mar 2017 18:00:36 +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.0977.019; Tue, 21 Mar 2017 18:00:36 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "grow@ietf.org" , "idr@ietf.org" CC: "sidr wg list (sidr@ietf.org)" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" Thread-Topic: operator inputs -- route leak solution Thread-Index: AdKia1LxrjWKYnevQ5+4FG+AD/ZO4w== Date: Tue, 21 Mar 2017 18:00:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.110.145] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0445; 7:xBQU71LM1+X3o0+Ty1/UwWlrOxncq+oJt+62mY5tIjRUmVCwGVQXIHZSBKkAqv27yEORlnSHP/t2qyis88m6fPo0AEOR51q3CpIH/HhBi6Qne7E21djlT8YEKgYZUlIt+mlN2YhFsLqzhyilxM88LemjTUvwMFpoLJiYbT8Oacg+9Ugs8PJzFksOesYoQsyO10C0G4A8oPkyRJr5bRgGsq0g9JDs2HvulqryB6sxTFuuE6YA9y7Zg8ORXhybY9Q6FeM9tCcNwO1WAjT0olpg28Zi48HvrsgLRnQMZRM1rrj09CCqaMzF7oW5yZomtbOs1GdDcccXwn28l5rrCbN3ZA== x-ms-office365-filtering-correlation-id: 7ba95e3f-b4b6-4025-082b-08d470842d66 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:DM2PR09MB0445; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(256337837700080); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123558025)(20161123564025)(6072148); SRVR:DM2PR09MB0445; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0445; x-forefront-prvs: 02530BD3AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39450400003)(39840400002)(39410400002)(39860400002)(305945005)(86362001)(3280700002)(7736002)(74316002)(3660700001)(6506006)(38730400002)(2906002)(2900100001)(54356999)(50986999)(66066001)(7696004)(33656002)(5660300001)(6436002)(55016002)(966004)(53936002)(9686003)(99286003)(54906002)(6306002)(77096006)(122556002)(8936002)(189998001)(8676002)(81166006)(3846002)(6116002)(2501003)(102836003)(4326008)(25786009)(450100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0445; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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: 21 Mar 2017 18:00:36.3476 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0445 Archived-At: Subject: [sidr] operator inputs -- route leak solution X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 18:00:41 -0000 Inviting comments especially from GROW WG folk (network operators).=20 Please look at this and address the question posed at the end. Thank you. The most common form of route leak occurs when multi-homed=20 customer AS-C receives a route from its transit provider AS-A and leaks it to another transit provider AS-B. =20 [RFC 7908 https://tools.ietf.org/html/rfc7908 ] Customer AS-C is often the single point of failure. AS-A and AS-B may be doing intra-AS community tagging etc.=20 perfectly well to prevent route leaks, but AS-C does not and ends up leakin= g. The leaked route propagates via AS-B to the rest of Internet=20 due to prefer customer route policy. (Example: Google/Hathway/Airtel leak - https://bgpmon.net/what-caused-the-google-service-interruption/ =20 see many more examples in RFC 7908 ) A solution component for this has long been discussed in=20 SIDR/GROW/IDR and well documented in IDR (see Section 4)=20 ( https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigatio= n-06 ).=20 The solution involves AS-A setting a field (in an optional transitive attri= bute) in BGP update to indicate that=20 (1) it is sending the route to a customer AS (or lateral peer), and=20 (2) the route SHOULD be considered a leak if subsequently received from a customer or a lateral peer. This is one component of the overall solution. It has been presented and discussed and I believe accepted in SIDR/IDR/GROW over the last few years (at least since 2014). Question:=20 >From an operator point of view, are you willing to place a piece of relationship info (as stated above) in the BGP update for the significant gain of a route leak solution that works well to detect/stop route leaks that do happen, and prevents single point of failures in incremental/partial deployment scenarios? Sriram=20 P.S. There is already immense BGP-derived public data out there on AS peeri= ng relations: http://as-rank.caida.org/?mode0=3Das-info&mode1=3Das-table&as=3D3356&data-s= elected-id=3D39=20 http://bgp.he.net/AS7018#_graph4=20 =20 =20 =20 From nobody Tue Mar 21 13:55:28 2017 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 33A5612ECF5 for ; Tue, 21 Mar 2017 13:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-5dTc4JaYcP for ; Tue, 21 Mar 2017 13:55:18 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (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 EE76D12EE44 for ; Tue, 21 Mar 2017 13:55:15 -0700 (PDT) X-Original-To: sidr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 258C961931 for ; Tue, 21 Mar 2017 21:55:14 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id D0D3D606E8; Tue, 21 Mar 2017 21:55:13 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id C21C96B17D; Tue, 21 Mar 2017 21:55:13 +0100 (CET) Date: Tue, 21 Mar 2017 21:55:13 +0100 From: Gert Doering To: "Sriram, Kotikalapudi (Fed)" Cc: "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" Message-ID: <20170321205513.GA2367@Space.Net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [sidr] [Idr] operator inputs -- route leak solution X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 20:55:19 -0000 Hi, On Tue, Mar 21, 2017 at 06:00:36PM +0000, Sriram, Kotikalapudi (Fed) wrote: > >>From an operator point of view, > are you willing to place a piece of relationship info (as stated above) > in the BGP update for the significant gain of a route leak solution > that works well to detect/stop route leaks that do happen, > and prevents single point of failures in incremental/partial > deployment scenarios? I'm not sure it will do any good. Those ISPs that care about the garbage their customers try to inject already do prefix/as-path filtering. Those ISPs that do not care today will not add bother to add a filter on this well-known community value (... and most likely, the customer router sending out unfiltered garbage won't have "send-community" enabled either). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Tue Mar 21 15:19:53 2017 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 4F0121293E4; Tue, 21 Mar 2017 15:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yop8UWtzmMYZ; Tue, 21 Mar 2017 15:19:43 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0E561299D6; Tue, 21 Mar 2017 15:19:43 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id b140so57059674iof.1; Tue, 21 Mar 2017 15:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qsY+bWNf4uVp4x+J0c2SJTRhOlzE4eRrYm0v2JAQb9g=; b=WSsVexnRwM6tmHe16Ea4zuR6nKfRzYrtIWdztwRtFSYinnCQkiiHgZ0ZWkVNcKdVY/ s+/zCHz1kjfmCQr0e9fZ8ItumA2s+FGeF6myOKzTis/uZiTmIOcqj5qKFwOL+6jG48IB AchG8r9wT0SIOkLCVCG/sg4jEJAnPkVQyBgqwAeFH1sHQ13I9whZpNTiX24f7WW43mNB wNuBrQ4eT9yOa+jPC5gR3m4T7WyhPRb8oipfLACKl7i5rWD9bG/twvcqFvtOWXr4AF8q 4FGBCSzq89v6ii7mHikRKYzo86RXRuaY9s0LrpZKRxBaHX2h5ncbzStJmIYhAKQOmKU4 Kg6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qsY+bWNf4uVp4x+J0c2SJTRhOlzE4eRrYm0v2JAQb9g=; b=RQtP8FZ0VUYanPXF0akXdX7cvNcCa1riN86eDNsU0ud2SShc+/9AEnOSmVpHInGGK2 Bn+rHGyeVJiPTL/PvRIi2J14RIRJ5YLJ4cZSdUbpznuqo3GqcZWqyICo1CmgeLRdBL6r B7rqSU1lWCP/nZu2+5FbcehJ0CPPza83SxwIm3pcDVPPR2glKW3Dkh14oGAocVYXybti xs6lo+gOUEVKz1KCF1y7i/tFaV5ayGz8hFKYYUhoFO3GE2nd89pN+P0g2DhSeEkjHfNp Y4vW0zer+ETx//jj+AupHwEA5fiBvTwWi/QcEAqVXQAnJiBUotgAq5llN8ynqVHnremX 1vkg== X-Gm-Message-State: AFeK/H2y8fy8wQgmMhfoLSTc20qd6oqwQhRbqAslaPRUHO2K1hOlt9lPBrephBjB/shOT0ER3O8VLmXu/nfn1Q== X-Received: by 10.107.157.146 with SMTP id g140mr32456766ioe.63.1490134783056; Tue, 21 Mar 2017 15:19:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.121.77 with HTTP; Tue, 21 Mar 2017 15:19:42 -0700 (PDT) In-Reply-To: <20170321205513.GA2367@Space.Net> References: <20170321205513.GA2367@Space.Net> From: Brian Dickson Date: Tue, 21 Mar 2017 15:19:42 -0700 Message-ID: To: Gert Doering Cc: "Sriram, Kotikalapudi (Fed)" , "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" Content-Type: multipart/alternative; boundary=001a11409824696c41054b450a11 Archived-At: Subject: Re: [sidr] [Idr] operator inputs -- route leak solution X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 22:19:45 -0000 --001a11409824696c41054b450a11 Content-Type: text/plain; charset=UTF-8 Pre-emptive top-post in case anyone mistakes the technique proposed: This will NOT be implemented via communities. The proposal is for a NEW optional transitive attribute. If any operators can answer the original question, this will be very helpful. Thank you in advance to any and all operators. Reminder on optional+transitive logic - If the attribute is not understood/implemented/enabled, the attribute is passed unmodified. - If it is understood & implemented & enabled, behavior is subject to the applicable standards. - Thus, optional transitives are "opt-in", by definition. The proposal itself is an IDR WG I-D, and as such not finalized; input here is definitely helpful in reaching consensus, understanding requirements, etc. Brian On Tue, Mar 21, 2017 at 1:55 PM, Gert Doering wrote: > Hi, > > On Tue, Mar 21, 2017 at 06:00:36PM +0000, Sriram, Kotikalapudi (Fed) wrote: > > >>From an operator point of view, > > are you willing to place a piece of relationship info (as stated above) > > in the BGP update for the significant gain of a route leak solution > > that works well to detect/stop route leaks that do happen, > > and prevents single point of failures in incremental/partial > > deployment scenarios? > > I'm not sure it will do any good. > > Those ISPs that care about the garbage their customers try to inject > already do prefix/as-path filtering. > > Those ISPs that do not care today will not add bother to add a filter on > this well-known community value (... and most likely, the customer > router sending out unfiltered garbage won't have "send-community" > enabled either). > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > --001a11409824696c41054b450a11 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Pre-emptive top-post in case anyone mistakes the technique= proposed: This will NOT be implemented via communities.

The proposal is for a NEW optional transitive attribute.
If any operators can answer the original question, this will b= e very helpful. Thank you in advance to any and all operators.=C2=A0
<= div>
Reminder on optional+transitive logic=C2=A0
- = If the attribute is not understood/implemented/enabled, the attribute is pa= ssed unmodified.=C2=A0
- If it is understood & implemented &a= mp; enabled, behavior is subject to the applicable standards.
- T= hus, optional transitives are "opt-in", by definition.
=
The proposal itself is an IDR WG I-D, and as such not finali= zed; input here is definitely helpful in reaching consensus, understanding = requirements, etc.

Brian

On Tue, Mar 21, 2017 at 1:55 PM,= Gert Doering <gert@space.net> wrote:
Hi,

On Tue, Mar 21, 2017 at 06:00:36PM +0000, Sriram, Kotikalapudi (Fed) wrote:=
> >>From an operator point of view,
> are you willing to place a piece of relationship info (as stated above= )
> in the BGP update for the significant gain of a route leak solution > that works well to detect/stop route leaks that do happen,
> and prevents single point of failures in incremental/partial
> deployment scenarios?

I'm not sure it will do any good.

Those ISPs that care about the garbage their customers try to inject
already do prefix/as-path filtering.

Those ISPs that do not care today will not add bother to add a filter on this well-known community value (... and most likely, the customer
router sending out unfiltered garbage won't have "send-community&q= uot;
enabled either).

Gert Doering
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsratsvo= rs.: A. Grundner-Culemann
D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0HRB: 136055 (AG Muenchen)
Tel: = +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-IdNr.: = DE813185279

--001a11409824696c41054b450a11-- From nobody Tue Mar 21 16:37:02 2017 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 610D7129409; Tue, 21 Mar 2017 16:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=domino.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 RSBjPzlRqKkM; Tue, 21 Mar 2017 16:36:46 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0130.outbound.protection.outlook.com [104.47.1.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8AF2129496; Tue, 21 Mar 2017 16:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=domino.onmicrosoft.com; s=selector1-domino-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RZf1ujktFS/b52i+UMplQhDgJTkeScooLEH3ctIlZlI=; b=T8l0RW3yRd0VEhqlxuBcjo8NAKUC9pqwmPqcDVO0cOPSlEVdsC/LMWsAHeyXs2P8KBDT73KUslDt/19y3wL1lFIeQKSUlCE9jh4DcIGRGEuKX/nP8dhchwXH05Cz57iGd7wknJTyzy5eYippOJ9Au1gE67qUG3UDIAQWNeYGiS0= Received: from AM4PR03MB1425.eurprd03.prod.outlook.com (10.164.77.155) by AM4PR03MB1427.eurprd03.prod.outlook.com (10.164.77.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Tue, 21 Mar 2017 23:36:40 +0000 Received: from AM4PR03MB1425.eurprd03.prod.outlook.com ([10.164.77.155]) by AM4PR03MB1425.eurprd03.prod.outlook.com ([10.164.77.155]) with mapi id 15.01.0977.020; Tue, 21 Mar 2017 23:36:40 +0000 From: "Neil J. McRae" To: "Sriram, Kotikalapudi (Fed)" CC: "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" Thread-Topic: [Idr] operator inputs -- route leak solution Thread-Index: AdKia1LxrjWKYnevQ5+4FG+AD/ZO4wAMKpth Date: Tue, 21 Mar 2017 23:36:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nist.gov; dkim=none (message not signed) header.d=none;nist.gov; dmarc=none action=none header.from=domino.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [107.77.224.155] x-microsoft-exchange-diagnostics: 1; AM4PR03MB1427; 7:tyTnIuVIwh5JEFjo2h+aFF46ANIfZr8wkDh54mlgbmQzX83VfBID0oPU6MXT50MY5CDxN03uB1HWVd9dIr/BvLQwRCPi6zJvm/Ph9L2qR5gxZTqlOXG7JpsCiZBvG/CDEwTwK9aI0kNCFLyvL3o/moi3rA4E4F4jHwQ0G/66y4LPL+q7BFS+J5eLvct3yn67cE8QaJzosn8HFnku86oTzHYO1dRfcJarXv4vFlstwRsd/58ectVZnePEHqX7/p+Rcxaf6mh/PgrlDLQkcMwmnkwOcbu7lh4wTAsUJpFfS1w79mBVf01sEiQUt8unpU+IdoIk0dcsJ2r64gjng7LQCA== x-ms-office365-filtering-correlation-id: 07f08d1c-a623-471e-07f0-08d470b3201b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:AM4PR03MB1427; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(256337837700080); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123558025)(20161123560025)(20161123564025)(20161123562025)(2016111802025)(6072148)(6043046); SRVR:AM4PR03MB1427; BCL:0; PCL:0; RULEID:; SRVR:AM4PR03MB1427; x-forefront-prvs: 02530BD3AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39450400003)(24454002)(966004)(2906002)(99286003)(5660300001)(8676002)(82746002)(83716003)(50986999)(53936002)(102836003)(122556002)(25786009)(2900100001)(54906002)(6116002)(229853002)(6512007)(86362001)(38730400002)(6246003)(6306002)(66066001)(3846002)(81166006)(110136004)(4326008)(77096006)(6436002)(6916009)(6506006)(3660700001)(189998001)(7736002)(33656002)(54356999)(3280700002)(2950100002)(76176999)(36756003)(305945005)(53546009)(6486002)(8936002)(8656002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR03MB1427; H:AM4PR03MB1425.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: domino.org X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2017 23:36:40.3569 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 398f3eb4-3394-48e7-885c-de1ab2a9cf2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR03MB1427 Archived-At: Subject: Re: [sidr] [Idr] operator inputs -- route leak solution X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 23:36:49 -0000 It seems a reasonable approach as long as it's kept as simple as described = here. Regards, Neil. > On 21 Mar 2017, at 18:00, Sriram, Kotikalapudi (Fed) wrote: >=20 > Inviting comments especially from GROW WG folk (network operators).=20 > Please look at this and address the question posed at the end. Thank you. >=20 > The most common form of route leak occurs when multi-homed=20 > customer AS-C receives a route from its transit provider AS-A > and leaks it to another transit provider AS-B. =20 > [RFC 7908 https://tools.ietf.org/html/rfc7908 ] >=20 > Customer AS-C is often the single point of failure. > AS-A and AS-B may be doing intra-AS community tagging etc.=20 > perfectly well to prevent route leaks, but AS-C does not and ends up leak= ing. > The leaked route propagates via AS-B to the rest of Internet=20 > due to prefer customer route policy. > (Example: Google/Hathway/Airtel leak - > https://bgpmon.net/what-caused-the-google-service-interruption/ =20 > see many more examples in RFC 7908 ) >=20 > A solution component for this has long been discussed in=20 > SIDR/GROW/IDR and well documented in IDR (see Section 4)=20 > ( https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigat= ion-06 ).=20 > The solution involves AS-A setting a field (in an optional transitive att= ribute) > in BGP update to indicate that=20 > (1) it is sending the route to a customer AS (or lateral peer), and=20 > (2) the route SHOULD be considered a leak if subsequently received > from a customer or a lateral peer. > This is one component of the overall solution. > It has been presented and discussed and I believe accepted > in SIDR/IDR/GROW over the last few years (at least since 2014). >=20 > Question:=20 >> From an operator point of view, > are you willing to place a piece of relationship info (as stated above) > in the BGP update for the significant gain of a route leak solution > that works well to detect/stop route leaks that do happen, > and prevents single point of failures in incremental/partial > deployment scenarios? >=20 > Sriram=20 >=20 > P.S. There is already immense BGP-derived public data out there on AS pee= ring relations: >=20 > http://as-rank.caida.org/?mode0=3Das-info&mode1=3Das-table&as=3D3356&data= -selected-id=3D39=20 >=20 > http://bgp.he.net/AS7018#_graph4 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed Mar 22 08:07:22 2017 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 3FE191298AA for ; Wed, 22 Mar 2017 07:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMagkpXqTvOs for ; Wed, 22 Mar 2017 07:33:20 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (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 7803B1298A9 for ; Wed, 22 Mar 2017 07:33:05 -0700 (PDT) X-Original-To: sidr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 9E1A06165A for ; Wed, 22 Mar 2017 15:33:03 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 231F361637; Wed, 22 Mar 2017 15:33:03 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 14C5F3435E; Wed, 22 Mar 2017 15:33:03 +0100 (CET) Date: Wed, 22 Mar 2017 15:33:03 +0100 From: Gert Doering To: Brian Dickson Cc: Gert Doering , "Sriram, Kotikalapudi (Fed)" , "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" Message-ID: <20170322143302.GG2367@Space.Net> References: <20170321205513.GA2367@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JjQGvUpjKaxqoY/q" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [sidr] [Idr] operator inputs -- route leak solution X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 14:33:21 -0000 --JjQGvUpjKaxqoY/q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Mar 21, 2017 at 03:19:42PM -0700, Brian Dickson wrote: > Pre-emptive top-post in case anyone mistakes the technique proposed: This > will NOT be implemented via communities. >=20 > The proposal is for a NEW optional transitive attribute. >=20 > If any operators can answer the original question, this will be very > helpful. Thank you in advance to any and all operators. >=20 > Reminder on optional+transitive logic > - If the attribute is not understood/implemented/enabled, the attribute is > passed unmodified. > - If it is understood & implemented & enabled, behavior is subject to the > applicable standards. > - Thus, optional transitives are "opt-in", by definition. It does not really matter if this is a well-known community or a new transitive attribute. If ISPs do not turn this *on* on their customer connections, it will not do anything - and given that those ISPs that *need* to turn this on are the ones that are not caring today, I'm still not seeing why they would turn this on tomorrow. So you're adding implementation complexity which will not help anything. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --JjQGvUpjKaxqoY/q Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAljSix4ACgkQ31bAZeTO f8ULhxAAiPcBCmIotqsF0CoqP09alfDDaKam+WqBuTX/EFvah+KVFg5THx42yJoK 8HRHwMPghStcjXy8zbOd/jzOCpvq0x+OMCwqdD2WeExQcWum7nk5AyVtL9PqWn/F Ye8rbVuBuq1c2KH8YzmFv7MQu4OKmC/OEtjrYfFN/WhH2DPU/7QEj/HOYM7sxknW 4vAtiuI0aXfRW2rc2z/UrzOdOVaLfXQYVto2vkj0UhtP9KuKq7wvSTeWwXxSrEpX /MQLTpEfaZjXnkY8Z31sI8jTIakfXV/HUS9k0rG0m6Qp+snnk34jJYcWMvVZS+hn 5Fgj2xfQfUvzYEuqxntTBz87PrJwtZa9YA9DHSMvnp3sulHDQKtKBy90SsuwpKNg cdKZc1MBeQl2H1NOTJod2T5e4GHnbxmUnh6bJV3s9LN1raP8L3xdUN2gALsEglwE /zu6X3Xu2RzwPJF5s+MljPMhoZqlWMYzCxLmuHJytN/Lz8VcsIEiR+JtKrk3HPWZ M8yXcaQgR+YL682ySa4pkxAm3chtpatJanQZkoCIaMBQSPxhPMgdlyJXP3fZDEVl tuguuCI+AsmYH120mtXkAHTrYuMsz02RwbmErQA3PqHKoyy3UQPl6bV90c9tmd/N 40PBsbnxrmxSHWzZKvMNFjQ4cuo6SciRF0aq9e1pR0GvomGfr+I= =mefv -----END PGP SIGNATURE----- --JjQGvUpjKaxqoY/q-- From nobody Wed Mar 22 15:13:21 2017 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 4C603127342; Wed, 22 Mar 2017 15:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 xCZ06se0aQXb; Wed, 22 Mar 2017 15:13:04 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 DBC7A127735; Wed, 22 Mar 2017 15:13:03 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id 190so31004151itm.0; Wed, 22 Mar 2017 15:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oUHKLFxuZRky4t5r6WW0J1XCW+fLpRqc3d2eE1QmR/Y=; b=V9zI3/OXt0h8dzmKaggNrxMdCHAD5XiTNcrf0hx9YtqjiEKcHuJbhN3RMvPOAKd8tp y5R3DvFn6RoX3CD999aix5r8p3LuvwN+emRjcDxM5HuVJOmGCQitwQ4fibgoec+EIQni 6QzkeXENXtPK/AYBiREOM3NOooSkm33b5CyoGhRxIK0q9zviYKAB4JU5RKmPCbotPEKZ +GaIIZs4eDIk8SamDrvo9TQy/YCrKujkVl8Oi1RVQhmPfFE6J8nzJ/EBhQLjXNI4FcJ3 U3bJLhOWAaPq2pK95CVdDMEhH5qiIHePlfTronraFt6wg+eHvHkdXCGH3JlwYkc7hcNc DKOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oUHKLFxuZRky4t5r6WW0J1XCW+fLpRqc3d2eE1QmR/Y=; b=XUCiWtjZdPrtlbJldMMPmbjxMxJES81XKKfFpAthYw/JyOhdtin/z5kQlPVurv8hKg 4F3Yu8kgAgvkroCSDP9aL4hiAEOvPas8nzqUUFMFutPJUjC9XDSTI1M3XE5zcAvOAhsi wJ//JmRuK9W/aGIYc1TtKFLINlQItjHlMsgXcjMN5M7Ioivovov9ieuLDW0KXuXsNLn5 9AwD8MFEByoQZpPCa14zTYsdtXrvApIsG4J/PFUDOXmr/4xWirk0YgIefh9qQmwlmQiF MFfxeX015Yvi34AdvYibAf7zhEgTYT8LGCXKyWXHzU+yZStoX+jTsR3O39ei7XEnFSy3 IEeg== X-Gm-Message-State: AFeK/H3HxY2xPVkDHS/tX2hB4ZTAPfdnnQrQBramODZ/+x+t26wT6X82SloauUqVpUWTD16Yd7OmVWMtK8M6BQ== X-Received: by 10.36.4.67 with SMTP id 64mr10149401itb.19.1490220783203; Wed, 22 Mar 2017 15:13:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.121.77 with HTTP; Wed, 22 Mar 2017 15:13:02 -0700 (PDT) In-Reply-To: <20170322143302.GG2367@Space.Net> References: <20170321205513.GA2367@Space.Net> <20170322143302.GG2367@Space.Net> From: Brian Dickson Date: Wed, 22 Mar 2017 15:13:02 -0700 Message-ID: To: Gert Doering Cc: "Sriram, Kotikalapudi (Fed)" , "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" Content-Type: multipart/alternative; boundary=001a1140ad4e6ba0a9054b59103c Archived-At: Subject: Re: [sidr] [Idr] operator inputs -- route leak solution X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 22:13:06 -0000 --001a1140ad4e6ba0a9054b59103c Content-Type: text/plain; charset=UTF-8 On Wed, Mar 22, 2017 at 7:33 AM, Gert Doering wrote: > Hi, > > On Tue, Mar 21, 2017 at 03:19:42PM -0700, Brian Dickson wrote: > > Pre-emptive top-post in case anyone mistakes the technique proposed: This > > will NOT be implemented via communities. > > > > The proposal is for a NEW optional transitive attribute. > > > > If any operators can answer the original question, this will be very > > helpful. Thank you in advance to any and all operators. > > > > Reminder on optional+transitive logic > > - If the attribute is not understood/implemented/enabled, the attribute > is > > passed unmodified. > > - If it is understood & implemented & enabled, behavior is subject to the > > applicable standards. > > - Thus, optional transitives are "opt-in", by definition. > > It does not really matter if this is a well-known community or a new > transitive attribute. > > If ISPs do not turn this *on* on their customer connections, it will not > do anything - and given that those ISPs that *need* to turn this on are > the ones that are not caring today, I'm still not seeing why they would > turn this on tomorrow. > > There is direct benefit to partial (even very sparse) deployment. The deployment is self-serving; whoever turns this on protects themselves and their downstream customers. This becomes a differentiator with direct benefits, and creates market pressure to deploy. Here's the simplest example showing how few parties need to implement this, for benefit. (Key: O = originator, T = top-tier ISP, L = leaker; number N disambiguates; subscript y/n means "implements") On1 - (arbitrary path) - Tn1 - (arbitrary path) - L - (arbitrary path) - Tn2 - (arbitrary path) - On2 - leaks in both directions pass without any tagging/blocking; - Path via L is preferred, because T1 and T2 prefer customer routes (which include L) - All traffic between Tn1 and Tn2 is affected (assuming L leaks the entire routing table) - In addition to latency caused by extra hops, there will likely be queueing-based latency, and significant loss On1 - (arbitrary path) - Ty3 - (arbitrary path) - L - (arbitrary path) - Ty4 - (arbitrary path) - On2 - leaks in both directions are blocked, at Ty3 and Ty4 respectively - The leak is blocked despite neither On1 nor On2 activating the protocol - The actual path selected will be something else, possibly/probably: - On1 - ... - Ty3 - Ty4 - ... - On2 - Since Ty3 and Ty4 both block the L routes (leaked) inbound, those routes are excluded - Assuming Ty3 and Ty4 peer, there will not be a better path respectively, modulo other peers with shorter AS paths to On1 or On2. If both of the above paths (Tn1 - L - Tn2, and Ty3 - Ty4) are valid paths, the following will be the case: - In all likelihood, there will be massive latency and packet loss, on the first path via L - The other path will not have that latency/loss - On1 and On2 will both be better served by - preferentially routing to Ty3 and Ty4 (apply better local-pref inbound to Ty3 and Ty4) - preferentially announcing to Ty3 and Ty4 (prepend to Tn1 and Tn2) - On1 and On2 obtain benefit by being able route around L (the leaker) - Ty3 and Ty4 get benefit by having more traffic to/from their customers - Potential customers may choose Ty3 and Ty4 for those reasons - Networks who deploy on their own infrastructure gain similar benefits, even if they All of the above presumes intermediate ASNs that do not implement (all of the "arbitrary path" bits), yet there is benefit to all the named parties. The same would be true for ASNs at Tier-2 who peer at various exchange points, who implement; they would possibly position themselves better than Tier-1's until any Tier-1's implement. NB - ASNs who are upstream of L, but downstream of Ty3 and Ty4 would NOT see the benefit, unless they also implement, so there is further reason to implement for Tier-N, N>1. FYI - I worked as a senior network engineer, where inbound peering ACLs of other Tier-1 networks, allowed us to escape the AS7001 incident unscathed. This scales a lot better, since there is no need for ACL maintenance. Applying to customers/peers should be easy, assuming the ISP knows which BGP neighbors are customers... Brian > So you're adding implementation complexity which will not help anything. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > --001a1140ad4e6ba0a9054b59103c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 22, 2017 at 7:33 AM, Gert Doering <gert@space.net> wrote:
Hi,

On Tue, Mar 21, 2017 at 03:19:42PM -0700, Brian Dickson wrote:
> Pre-emptive top-post in case anyone mistakes the technique proposed: T= his
> will NOT be implemented via communities.
>
> The proposal is for a NEW optional transitive attribute.
>
> If any operators can answer the original question, this will be very > helpful. Thank you in advance to any and all operators.
>
> Reminder on optional+transitive logic
> - If the attribute is not understood/implemented/enabled, the att= ribute is
> passed unmodified.
> - If it is understood & implemented & enabled, behavior is sub= ject to the
> applicable standards.
> - Thus, optional transitives are "opt-in", by definition.
It does not really matter if this is a well-known community or a new=
transitive attribute.

If ISPs do not turn this *on* on their customer connections, it will not do anything - and given that those ISPs that *need* to turn this on are
the ones that are not caring today, I'm still not seeing why they would=
turn this on tomorrow.


There is direct benefit to partial (ev= en very sparse) deployment.

The deployment is self= -serving; whoever turns this on protects themselves and their downstream cu= stomers.

This becomes a differentiator with direct= benefits, and creates market pressure to deploy.

= Here's the simplest example showing how few parties need to implement t= his, for benefit.
(Key: O =3D originator, T =3D top-tier ISP, L = =3D leaker; number N disambiguates; subscript y/n means "implements&qu= ot;)

On1 - (arbitrary path) - Tn1 - (arbitrary pat= h) - L - (arbitrary path) - Tn2 - (arbitrary path) - On2
  • = leaks in both directions pass without any tagging/blocking;=C2=A0
  • P= ath via L is preferred, because T1 and T2 prefer customer routes (which inc= lude L)
  • All traffic between Tn1 and Tn2 is affected (assuming L= leaks the entire routing table)
  • In addition to latency caused by e= xtra hops, there will likely be queueing-based latency, and significant los= s
On1 - (arbitrary path) - Ty3 - (arbitrary path) - L -= (arbitrary path) - Ty4 - (arbitrary path) - On2=C2=A0
  • le= aks in both directions are blocked, at Ty3 and Ty4 respectively
  • The leak is blocked despite neither On1 nor On2 activating the protoco= l
  • The actual path selected will be something else, possibly/pr= obably:
    • On1 - ... - Ty3 - Ty4 - ... - On2
    • Since Ty3 and= Ty4 both block the L routes (leaked) inbound, those routes are excluded
    • Assuming Ty3 and Ty4 peer, there will not be a better path respective= ly, modulo other peers with shorter AS paths to On1 or On2.
    <= div>If both of the above paths (Tn1 - L - Tn2, and Ty3 - Ty4) are valid pat= hs, the following will be the case:
    • In all likelihood, th= ere will be massive latency and packet loss, on the first path via L
      • The other path will not have that latency/loss
    • On1 and On2 will b= oth be better served by=C2=A0
      • preferentially routing to Ty3 and= Ty4 (apply better =C2=A0local-pref inbound to Ty3 and Ty4)
      • prefere= ntially announcing to Ty3 and Ty4 (prepend to Tn1 and Tn2)
    • On1= and On2 obtain benefit by being able route around L (the leaker)
      • <= ul>
    • Ty3 and Ty4 get benefit by having more traffic to/from their custome= rs
    • Potential customers may choose Ty3 and Ty4 for those reasons
    • Networks who deploy on their own infrastructure gain similar benefits,= even if they=C2=A0
    All of the above presumes inte= rmediate ASNs that do not implement (all of the "arbitrary path" = bits), yet there is benefit to all the named parties.

    <= /div>
    The same would be true for ASNs at Tier-2 who peer at various exc= hange points, who implement; they would possibly position themselves better= than Tier-1's until any Tier-1's implement.

    NB - ASNs who are upstream of L, but downstream of Ty3 and Ty4 would NOT= see the benefit, unless they also implement, so there is further reason to= implement for Tier-N, N>1.

    FYI - I worked as a= senior network engineer, where inbound peering ACLs of other Tier-1 networ= ks, allowed us to escape the AS7001 incident unscathed.=C2=A0
    Thi= s scales a lot better, since there is no need for ACL maintenance.
    Applying to customers/peers should be easy, assuming the ISP knows which = BGP neighbors are customers...

    Brian
    =C2=A0
    So you're adding implementation complexity which will not help anything= .

    Gert Doering
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster
    --
    have you enabled IPv6 on something today...?

    SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
    Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsratsvo= rs.: A. Grundner-Culemann
    D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0HRB: 136055 (AG Muenchen)
    Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0USt-IdNr.: DE813185279

    --001a1140ad4e6ba0a9054b59103c-- From nobody Wed Mar 22 16:50:49 2017 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 A78F1128D19; Wed, 22 Mar 2017 16:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fi5vWmEX-vps; Wed, 22 Mar 2017 16:50:34 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE5E7127201; Wed, 22 Mar 2017 16:50:33 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cqq1Q-0000LC-T1; Wed, 22 Mar 2017 23:50:33 +0000 Date: Wed, 22 Mar 2017 18:50:32 -0500 Message-ID: From: Randy Bush To: "Sriram, Kotikalapudi (Fed)" Cc: "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [sidr] [Sidrops] operator inputs -- route leak solution X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 23:50:36 -0000 > SIDR/GROW/IDR and well documented in IDR (see Section 4) > ( https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-06 ). > The solution involves AS-A setting a field (in an optional transitive > attribute) glad you liked the attribute approach well enough to plagarize it from our draft. now you just need to change from misconfigurable statements of relationships to plagarize the bgp open part of our draft and your golden. randy From nobody Wed Mar 22 18:09:39 2017 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 013341292F5; Wed, 22 Mar 2017 18:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCO3WtYsAR8q; Wed, 22 Mar 2017 18:09:36 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 1C385128954; Wed, 22 Mar 2017 18:09:36 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id w124so32095238itb.1; Wed, 22 Mar 2017 18:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qtGpYjit16EONu0EM0Wx5kW3QiIcY7QDfJOGkqQtaJI=; b=imeni+XKvXGsUU5vlf/8RXUaCta7nnXAzPjdTM+BkAdRHUvZFjFOLr5XyWz8/aCRAy gNYMmxthjEOCdagRbhrmHzCedInHQaxSCv6N18LQnuJmPo/G7aOty5TEkuW2QUbHYwLI 8vVVcnnOtH2yaLSTkh2WtzsM4R5dB91ZERfn5Mu3axSzFvsSQ77SfIqLzxlMVxx2g7xq /jwgkELna0y0lIisGKeV13loiLr8IJ/uSuVXMY0KSQHIHx14ekjxv6sGQ7PYxcHwrR8f GZhGkU/OZLfVeaNz9dAGXe2O7m3YzXibI4vB35oXszn35ca+wEWfAk9mNefTnWBkXmsR elMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qtGpYjit16EONu0EM0Wx5kW3QiIcY7QDfJOGkqQtaJI=; b=MvBj4vWAv7Aivhv/v9wXKoI2LNi7unIY4COjM+h+EeYoCPm9UtwIUXsGPpSZyg0W6z 7d4HV0k8t+CzHLjx5sRR00QFkKzSbpfOD113p2KFW6MaPFrAWDTKj4Hqgn5er4Mc+BQW WXbQOfz1zEy4qZXEwfXNQqiNqWsLgjprHy46I+OadjofjGpqOXqBn701Ew5E6aAjmjGN 94H51/ltSIRw0Kmk5Nb140YaJcVNQGC90NXzTsapRYn48vdU3gaCk/UHS97i0QLATd26 Tl82ysbmn2eoUmA2EQA1qp2oSpmtp+oCfL/lIsIjA+iN220WjXpBDsQIAYjBkvWrfWtA QxQg== X-Gm-Message-State: AFeK/H1YBDj2CfyijOurR5zm5LQSB2deOcXkvCvzEAYkxssc3v9A6vyp97+8NAUSTAhS4VFyUX7nC+0x0ySUog== X-Received: by 10.36.102.195 with SMTP id k186mr338487itc.75.1490231375484; Wed, 22 Mar 2017 18:09:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.121.77 with HTTP; Wed, 22 Mar 2017 18:09:34 -0700 (PDT) In-Reply-To: References: From: Brian Dickson Date: Wed, 22 Mar 2017 18:09:34 -0700 Message-ID: To: Randy Bush Cc: "Sriram, Kotikalapudi (Fed)" , "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" Content-Type: multipart/alternative; boundary=001a1147f558c4efba054b5b87e3 Archived-At: Subject: Re: [sidr] [Sidrops] operator inputs -- route leak solution X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 01:09:38 -0000 --001a1147f558c4efba054b5b87e3 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 22, 2017 at 4:50 PM, Randy Bush wrote: > > SIDR/GROW/IDR and well documented in IDR (see Section 4) > > ( https://tools.ietf.org/html/draft-ietf-idr-route-leak- > detection-mitigation-06 ). > > The solution involves AS-A setting a field (in an optional transitive > > attribute) > > glad you liked the attribute approach well enough to plagarize it from > our draft. now you just need to change from misconfigurable statements > of relationships to plagarize the bgp open part of our draft and your > golden. > > Randy, With all due respect, your draft fails to acknowledge the earlier work by me (from 2012), outside of the recent drafts of which I am a co-author. Specifically: draft-dickson-sidr-route-leak-def (which became the basis for RFC 7908) draft-dickson-sidr-route-leak-reqts draft-dickson-sidr-route-leak-solns So, perhaps it would be best to avoid claims of plagiarizing, when (a) there is clear evidence that the source of the material predates your work, and (b) when your work does not credit the original work by me. Pot calling the kettle black, throwing stones in glass houses, and all that. You might want to also read those (expired) I-Ds, to get clarity on preserving leak prevention across "special" peering sessions They also cover the ability to prevent leaks, without requiring the disclosure of customer relationships -- something for which you have expressed a strong desire. FWIW, I will be working with my co-authors on the relationship-disclosure detail. Maybe we can schedule some white-board time in Chicago. Brian P.S. It is "you're golden". --001a1147f558c4efba054b5b87e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On W= ed, Mar 22, 2017 at 4:50 PM, Randy Bush <randy@psg.com> wrote:
    = > SIDR/GROW/IDR and well documented in IDR (see Section 4)
    > ( https://tools.ie= tf.org/html/draft-ietf-idr-route-leak-detection-mitigation-06= =C2=A0 ).
    > The solution involves AS-A setting a field (in an optional transitive<= br> > attribute)

    glad you liked the attribute approach well enough to plagarize it fr= om
    our draft.=C2=A0 now you just need to change from misconfigurable statement= s
    of relationships to plagarize the bgp open part of our draft and your
    golden.


    Randy,

    =
    With all due respect, your draft fails to acknowledge the earlier work= by me (from 2012), outside of the recent drafts of which I am a co-author.=

    Specifically:
    draft-dickson-sidr-route-= leak-def (which became the basis for RFC 7908)
    draft-dickson-= sidr-route-leak-reqts
    draft-dickson-sidr-route-leak-solns
    =

    So, perhaps it would be best to avoid claims of p= lagiarizing, when (a) there is clear evidence that the source of the materi= al predates your work, and (b) when your work does not credit the original = work by me.

    Pot calling the kettle black, throwing= stones in glass houses, and all that.

    You might w= ant to also read those (expired) I-Ds, to get clarity on preserving leak pr= evention across "special" peering sessions
    They also co= ver the ability to prevent leaks, without requiring the disclosure of custo= mer relationships -- something for which you have expressed a strong desire= .

    FWIW, I will be working with my co-authors on th= e relationship-disclosure detail.

    Maybe we can sch= edule some white-board time in Chicago.

    Brian

    P.S.=C2=A0 It is "you're golden".
    <= /div>
    --001a1147f558c4efba054b5b87e3-- From nobody Wed Mar 22 20:21:33 2017 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 55242129B28; Wed, 22 Mar 2017 20:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sp5gXmSgkcmj; Wed, 22 Mar 2017 20:21:30 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2AAC1200A0; Wed, 22 Mar 2017 20:21:29 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cqtJW-00022B-T9; Thu, 23 Mar 2017 03:21:27 +0000 Date: Wed, 22 Mar 2017 22:21:26 -0500 Message-ID: From: Randy Bush To: Brian Dickson Cc: "Sriram, Kotikalapudi (Fed)" , "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [sidr] [Sidrops] operator inputs -- route leak solution X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 03:21:31 -0000 > With all due respect, your draft fails to acknowledge the earlier work by > me (from 2012), outside of the recent drafts of which I am a > co-author. apologies. this should be corrected, > So, perhaps it would be best to avoid claims of plagiarizing, when (a) > there is clear evidence that the source of the material predates your work, > and (b) when your work does not credit the original work by me. word for word From nobody Wed Mar 22 20:34:12 2017 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 434EA129438; Wed, 22 Mar 2017 20:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLtG7LG5bahH; Wed, 22 Mar 2017 20:34:09 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0099.outbound.protection.outlook.com [23.103.201.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21F9B12942F; Wed, 22 Mar 2017 20:34:08 -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=HxYKCR7u8SHJhFeVh3X66vemla6rJNNjhuaPG4YnIXU=; b=v1/qajZTMRQTqSut/5/9HkDtBX3yl+5Y5wo2LgQ+nNEt/pS2hfDFcyqJKPsxNzpV4JINLRQDqB31vslvQMn/I+FB4mKwKYfeZxkLNX7fdAvjPIS+SFWEdBRGdPZjPnP/yIuLgCIH1glxps4B3NcrBo7iUy5YwP9DgD39cNbPcyw= 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 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Thu, 23 Mar 2017 03:34:07 +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.0977.019; Thu, 23 Mar 2017 03:34:07 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Randy Bush CC: "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" , "idr-chairs@ietf.org" Thread-Topic: [Sidrops] operator inputs -- route leak solution Thread-Index: AdKia1LxrjWKYnevQ5+4FG+AD/ZO4wA+8SkAAAcwRBI= Date: Thu, 23 Mar 2017 03:34:07 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.223.1] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0446; 7:Xccu20Y8r07osmhTSUZ30bPMWEDEhjFtGoI4CsC4/zxqB2q6l4lphtSdim1gAjaW5knchfQZeJeS2JW+Y5giwFgC4dET0h/VFKJNmoUQlhD85yTshL9m0YymTVXH4KNjQ1e2qWMkjXHVOtHvz6nyrIoMnJDYhXVvShh4Z1shpBN/3JeHpBcBj7sGcSaC7/OCE0nslHQZ+nNVk2xSJAFWVjpQCI+Bzgqts720SWTFuiGyU0paWT4ExMNtF2xb+R5AZI9ULGj5AjRIjLKN3T+R9AK6xPxj2Vtg78LN6UsHoEcoBnkoJK6WMAYuCY0p6E+eg66ULLRer1qelH813U8Ipw== x-ms-office365-filtering-correlation-id: c3754c7c-e977-4ff1-21c1-08d4719d7656 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:DM2PR09MB0446; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(20161123558025)(6072148); SRVR:DM2PR09MB0446; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0446; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39860400002)(39450400003)(39840400002)(305945005)(3846002)(7736002)(54356999)(50986999)(76176999)(4326008)(102836003)(229853002)(122556002)(6246003)(6116002)(38730400002)(77096006)(6506006)(2900100001)(3660700001)(99286003)(110136004)(66066001)(86362001)(3280700002)(53936002)(189998001)(8676002)(2950100002)(2906002)(6916009)(9686003)(6306002)(74316002)(54906002)(6436002)(81166006)(7696004)(55016002)(33656002)(25786009)(8936002)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0446; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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: 23 Mar 2017 03:34:07.3891 (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: Subject: Re: [sidr] [Sidrops] operator inputs -- route leak solution X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 03:34:11 -0000 >> SIDR/GROW/IDR and well documented in IDR (see Section 4) >> ( https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitiga= tion-06 ). >> The solution involves AS-A setting a field (in an optional transitive >> attribute) >glad you liked the attribute approach well enough to plagarize it from >our draft. now you just need to change from misconfigurable statements >of relationships to plagarize the bgp open part of our draft and your >golden. Randy, To the response that Brian already offered,=20 I would like to add the following with due respect. Our version-00 working group draft was published July 22, 2015, and it stat= ed: " The proposed RLP encoding SHOULD be carried in BGP-4 [RFC4271] updates in an optional transitive path attribute. "=20 https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-= 00 =20 =20 Your version-00 individual draft was published in March 2016.=20 Sriram =20 =20 From nobody Thu Mar 23 00:50:20 2017 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 6EAF3131746 for ; Thu, 23 Mar 2017 00:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDF-LLOXl8mv for ; Thu, 23 Mar 2017 00:50:12 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (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 7BA56129450 for ; Thu, 23 Mar 2017 00:50:10 -0700 (PDT) X-Original-To: sidr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 2270661778 for ; Thu, 23 Mar 2017 08:50:09 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 9D47D61565; Thu, 23 Mar 2017 08:50:08 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 8EA3B6BACB; Thu, 23 Mar 2017 08:50:08 +0100 (CET) Date: Thu, 23 Mar 2017 08:50:08 +0100 From: Gert Doering To: Brian Dickson Cc: Gert Doering , "Sriram, Kotikalapudi (Fed)" , "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" Message-ID: <20170323075008.GL2367@Space.Net> References: <20170321205513.GA2367@Space.Net> <20170322143302.GG2367@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mO1Hs8HP9h3I4vdI" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [sidr] [Idr] operator inputs -- route leak solution X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 07:50:14 -0000 --mO1Hs8HP9h3I4vdI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Mar 22, 2017 at 03:13:02PM -0700, Brian Dickson wrote: > There is direct benefit to partial (even very sparse) deployment. >=20 > The deployment is self-serving; whoever turns this on protects themselves > and their downstream customers. Those that are interested in doing so already do customer route filtering today. For those that are not interested, where's the incentive in starting to do so if you have to do a software upgrade first (*and* the other upstreams of your customers need to send this attribute)? > This becomes a differentiator with direct benefits, and creates market > pressure to deploy. A-ha. Right, exactly like "filter customer routes" is working today to give "market pressure". I always had the impression that *market* pressure is totally in favour of "accept everything from the customer, send down the pipe whatever you can, and then bill the customer for the traffic"... Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --mO1Hs8HP9h3I4vdI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAljTfi8ACgkQ31bAZeTO f8W7hw//bAlzlXD1a6H3ecoJAHNUCg3o/AlWjKcwx4Uh8ztyMcRUoGvnLnQKozCU nnKc+9Eglx14VKwsLhikTkj4pd9cZd/xe+uY5HtQOo1DQR2jWQaA/HX28Vqg/PMS yNIpz0ePpFFNvjIwZjjFojuZSX6WNl4ulYauJOHwOJicnFC6Vqy71RbjasWgyZMO PQ6QP9FYOkOj9oAmG9rJQGY0rzGUk0QIA+n4VvhqWnqeGQlThyzYnVlDIvkfbQMd BpPJcCq7ftzY5uQHXDPQReX+VBTfbIKgt9ngHTW6DUIHCXOyBm0GJ541r+y2nail 4qyaTbPrEdFtMGttU7IsGseXTVAQgf454ts0N4M+AmuhkErO8J8otSHM15DrA7yB BVYk+c3zlnxhk15Q4oThG2kW5iYkYlBLDc4AaRILjK0cl6MKf33IAwU8wodsNwwS J0BWUucy+Flbu9pV6PT1u6122dLxSNBmPstZr3k+NGKLYqMBPtdTUsVSLxqSUhbj PwFWNcts8wTDGaU5vy7BW/spcrElnamsA4DYnNGt5D4Ya/YE2DsTAlGiC73bkakt Qj90NEdpwvE78EVKhMmNEGB6umP9q8D3UEqwVnh684zrVokV+Rw6GI5yQaRyuqnA x+dISBRm9qA/EQZDaSQsLf8rUcQRKa2fZRuxT+Os1ug1mO4uGlU= =yv6G -----END PGP SIGNATURE----- --mO1Hs8HP9h3I4vdI-- From nobody Thu Mar 23 06:00:18 2017 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 EB29F1293F8; Thu, 23 Mar 2017 06:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_ENHANCEMENT=0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9lRRZcKlZu2; Thu, 23 Mar 2017 06:00:03 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 F20371296EA; Thu, 23 Mar 2017 06:00:02 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.9.114; From: "Susan Hares" To: "'Brian Dickson'" , "'Randy Bush'" Cc: , , , "'sidr wg list'" , References: In-Reply-To: Date: Thu, 23 Mar 2017 08:54:28 -0400 Message-ID: <02fa01d2a3d4$9bff4dc0$d3fde940$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02FB_01D2A3B3.14EEBF30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFy2aVjjW9G+WpNY0ppJr8stM1gVQGcf8JwAoeB1GSiQNC3IA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [sidr] [GROW] [Sidrops] operator inputs -- route leak solution X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 13:00:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02FB_01D2A3B3.14EEBF30 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Brian, Sriram and Randy:=20 =20 =20 Let me suggest we take the rest of this discussion on these IDR two = drafts offline from IDR. The IDR Chairs noted when the = draft-ietf-idr-route-leak-detection mitigation was adopted that there = was overlap between you two documents. We also noted interests in both = technical approaches. We asked to you provide a combined document that = the chairs could present to the IDR WG. This IETF is a wonderful time = to work on this project. Chicago has many fine establishments in which = to discuss this combined document. =20 =20 I suggest we focused on the technical issues on the IDR mail lists. For = discussions of IDR on the grow list, I suggest that we listen to the = valuable input from the operators on what their needs and ask clarifying = questions. =20 =20 =20 Thank you,=20 =20 Sue Hares=20 =20 From: GROW [mailto:grow-bounces@ietf.org] On Behalf Of Brian Dickson Sent: Wednesday, March 22, 2017 9:10 PM To: Randy Bush Cc: idr@ietf.org; = draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org; = grow@ietf.org; sidr wg list (sidr@ietf.org); sidrops@ietf.org Subject: Re: [GROW] [Sidrops] operator inputs -- route leak solution =20 On Wed, Mar 22, 2017 at 4:50 PM, Randy Bush wrote: > SIDR/GROW/IDR and well documented in IDR (see Section 4) > ( = https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigatio= n-06 ). > The solution involves AS-A setting a field (in an optional transitive > attribute) glad you liked the attribute approach well enough to plagarize it from our draft. now you just need to change from misconfigurable statements of relationships to plagarize the bgp open part of our draft and your golden. =20 Randy, =20 With all due respect, your draft fails to acknowledge the earlier work = by me (from 2012), outside of the recent drafts of which I am a = co-author. =20 Specifically: draft-dickson-sidr-route-leak-def (which became the basis for RFC 7908) draft-dickson-sidr-route-leak-reqts draft-dickson-sidr-route-leak-solns =20 So, perhaps it would be best to avoid claims of plagiarizing, when (a) = there is clear evidence that the source of the material predates your = work, and (b) when your work does not credit the original work by me. =20 Pot calling the kettle black, throwing stones in glass houses, and all = that. =20 You might want to also read those (expired) I-Ds, to get clarity on = preserving leak prevention across "special" peering sessions They also cover the ability to prevent leaks, without requiring the = disclosure of customer relationships -- something for which you have = expressed a strong desire. =20 FWIW, I will be working with my co-authors on the = relationship-disclosure detail. =20 Maybe we can schedule some white-board time in Chicago. =20 Brian =20 P.S. It is "you're golden". ------=_NextPart_000_02FB_01D2A3B3.14EEBF30 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

    Brian, Sriram and Randy:

     

    <IDR co-chair hat on>

    Let me suggest we take the rest of this discussion on these IDR two = drafts offline from IDR.=C2=A0 The IDR Chairs noted=C2=A0 when the = draft-ietf-idr-route-leak-detection mitigation was adopted =C2=A0that = there was overlap between you two documents.=C2=A0 We also noted = interests in both technical approaches.=C2=A0 We asked to you provide a = combined document that the chairs could present to the IDR WG.=C2=A0 = This IETF is a wonderful time to work on this project. = =C2=A0=C2=A0Chicago has many fine establishments in which to discuss = this combined document. =C2=A0=C2=A0

     

    I suggest we focused on the technical issues on the IDR mail = lists.=C2=A0 For discussions of IDR on the grow list, I suggest that we = listen to the valuable input from the operators on what their needs and = ask clarifying questions. =C2=A0

    <IDR co-chair hat off>

     

    Thank you,

     

    Sue Hares

     

    From:= = GROW [mailto:grow-bounces@ietf.org] On Behalf Of Brian = Dickson
    Sent: Wednesday, March 22, 2017 9:10 PM
    To: = Randy Bush
    Cc: idr@ietf.org; = draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org; = grow@ietf.org; sidr wg list (sidr@ietf.org); = sidrops@ietf.org
    Subject: Re: [GROW] [Sidrops] operator inputs = -- route leak solution

     

    On Wed, Mar 22, 2017 at 4:50 PM, Randy Bush <randy@psg.com> = wrote:

    > SIDR/GROW/IDR = and well documented in IDR (see Section 4)
    > ( https://tools.ietf.org/html/draft-ietf-idr-route-leak-d= etection-mitigation-06  ).
    > = The solution involves AS-A setting a field (in an optional = transitive
    > = attribute)

    glad you liked the attribute approach well = enough to plagarize it from
    our draft.  now you just need to = change from misconfigurable statements
    of relationships to plagarize = the bgp open part of our draft and your
    golden.

     

    Randy,

     

    With all due respect, your draft fails to acknowledge = the earlier work by me (from 2012), outside of the recent drafts of = which I am a co-author.

     

    Specifically:

    draft-dickson-sidr-route-leak-def (which became the = basis for RFC 7908)

    draft-dickson-sidr-route-leak-reqts

    draft-dickson-sidr-route-leak-solns

     

    So, perhaps it would be best to avoid claims of = plagiarizing, when (a) there is clear evidence that the source of the = material predates your work, and (b) when your work does not credit the = original work by me.

     

    Pot calling the kettle black, throwing stones in glass = houses, and all that.

     

    You might want to also read those (expired) I-Ds, to = get clarity on preserving leak prevention across "special" = peering sessions

    They also = cover the ability to prevent leaks, without requiring the disclosure of = customer relationships -- something for which you have expressed a = strong desire.

     

    FWIW, I will be working with my co-authors on the = relationship-disclosure detail.

     

    Maybe we can schedule some white-board time in = Chicago.

     

    Brian

     

    P.S.  It is "you're = golden".

    ------=_NextPart_000_02FB_01D2A3B3.14EEBF30-- From nobody Thu Mar 23 13:17:27 2017 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 87C91131648; Thu, 23 Mar 2017 13:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVoGpe_H90Yo; Thu, 23 Mar 2017 13:17:09 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81F291315D3; Thu, 23 Mar 2017 13:17:09 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cr9AO-0007Ar-BF; Thu, 23 Mar 2017 20:17:04 +0000 Date: Thu, 23 Mar 2017 15:17:04 -0500 Message-ID: From: Randy Bush To: Gert Doering Cc: Brian Dickson , "idr@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidrops@ietf.org" , "Sriram, Kotikalapudi (Fed)" , "sidr wg list (sidr@ietf.org)" , "grow@ietf.org" In-Reply-To: <20170323075008.GL2367@Space.Net> References: <20170321205513.GA2367@Space.Net> <20170322143302.GG2367@Space.Net> <20170323075008.GL2367@Space.Net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [sidr] [Idr] operator inputs -- route leak solution X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 20:17:10 -0000 >> The deployment is self-serving; whoever turns this on protects themselves >> and their downstream customers. > > Those that are interested in doing so already do customer route filtering > today. if god had meant us to fly in planes, she would not have given us trains. oh wait, americans don't have trains. :) randy From nobody Sat Mar 25 00:17:15 2017 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 081ED126557 for ; Sat, 25 Mar 2017 00:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8NqiQNT4yAI for ; Sat, 25 Mar 2017 00:17:09 -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 3E3C1120227 for ; Sat, 25 Mar 2017 00:17:09 -0700 (PDT) X-TM-DID: cb7af92e39e4cdb6026a29105c32e5bc From: Declan Ma Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: Date: Sat, 25 Mar 2017 16:09:36 +0900 To: sidr wg list , sidrops@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [sidr] RPSTIR updated X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Mar 2017 07:17:13 -0000 Hi, folks, We RPSTIR team just had the very software updated to support the = algorithm specified by Validation Reconsidered = (draft-ietf-sidr-rpki-validation-reconsidered-07) . Given the SIDR WG has not reach the agreement whether and how new OIDs = should be employed, this release, for the time being, is counting on the = old OIDs. And we will shift into new OIDs accordingly once the IETF has come into = a conclusion about that.=20 Welcome to have a try on this new version of RPSTIR.=20 We would appreciate your feedbacks.=20 https://github.com/bgpsecurity/rpstir/releases Declan(Di) Ma ZDNS From nobody Sat Mar 25 04:17:28 2017 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 B4EED129415; Sat, 25 Mar 2017 04:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tV77hc1_7Cuh; Sat, 25 Mar 2017 04:17:19 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1FD128BB6; Sat, 25 Mar 2017 04:17:19 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 915D2B80A4D; Sat, 25 Mar 2017 04:17:12 -0700 (PDT) To: achatz@forthnet.gr, randy@psg.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: aretana@cisco.com, iesg@ietf.org, sidr@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170325111712.915D2B80A4D@rfc-editor.org> Date: Sat, 25 Mar 2017 04:17:12 -0700 (PDT) Archived-At: Subject: [sidr] [Errata Held for Document Update] RFC7115 (4973) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Mar 2017 11:17:22 -0000 The following errata report has been held for document update for RFC7115, "Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7115&eid=4973 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Tassos Chatzithomaoglou Date Reported: 2017-03-18 Held by: Alvaro Retana (IESG) Section: 3 & 5 Original Text ------------- section 3 --------- For example, if, instead of 10.0.0.0/16-24, one issues 10.0.0.0/16 and 10.0.42.0/24, a forged origin attack cannot succeed against 10.0.666.0/24. section 5 --------- Consider having a ROA for AS 42 for prefix 10.0.0.0/16-24. A BGP announcement for 10.0.666.0/24 from AS 666 would be Invalid Corrected Text -------------- section 3 --------- For example, if, instead of 10.0.0.0/16-24, one issues 10.0.0.0/16 and 10.0.42.0/24, a forged origin attack cannot succeed against 10.0.66.0/24. section 5 --------- Consider having a ROA for AS 42 for prefix 10.0.0.0/16-24. A BGP announcement for 10.0.66.0/24 from AS 666 would be Invalid Notes ----- 666 is not a valid octet for an ipv4 address === I am marking this report as "Held for Document Update" [1], which means that the author might consider its merits for a future update. If the use of the "666" octet was intentional, then a short note explaining might be appropriate to avoid further confusion. - Alvaro. [1] https://www.ietf.org/iesg/statement/errata-processing.html -------------------------------------- RFC7115 (draft-ietf-sidr-origin-ops-23) -------------------------------------- Title : Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI) Publication Date : January 2014 Author(s) : R. Bush Category : BEST CURRENT PRACTICE Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Sat Mar 25 04:37:03 2017 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 7C72C12741D; Sat, 25 Mar 2017 04:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oZcRLkcoINt; Sat, 25 Mar 2017 04:36:54 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E850128656; Sat, 25 Mar 2017 04:36:54 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1crjzz-0005Kg-Ma; Sat, 25 Mar 2017 11:36:47 +0000 Date: Sat, 25 Mar 2017 06:36:47 -0500 Message-ID: From: Randy Bush To: RFC Errata System Cc: achatz@forthnet.gr, aretana@cisco.com, iesg@ietf.org, sidr@ietf.org In-Reply-To: <20170325111712.915D2B80A4D@rfc-editor.org> References: <20170325111712.915D2B80A4D@rfc-editor.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [sidr] [Errata Held for Document Update] RFC7115 (4973) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Mar 2017 11:36:55 -0000 > I am marking this report as "Held for Document Update" [1], which > means that the author might consider its merits for a future update. > If the use of the "666" octet was intentional, then a short note > explaining might be appropriate to avoid further confusion. problem is it's not a short note. In the current internet routing ecology, a /24 is the longest prefix which has a good chance at global propagation. The prefix allocated by RFC 5737, with much verbosity, are three non-contiguous /24s. The result is that documents which want to discuss routable prefixes which involve subnetting can not use space from RFC 5737. This is a general problem which someone (else) should fix. In RFC 7115, the subject of this erratum, routeable and subnettable examples were needed. So the well-known private network 10/8, see RFC 1918, was used in the examples. To indicate that it was not really intended to be used, an impossible octet, 666, was chosen. this was explained a number of times as this rfc went through the original sausage factory. randy From nobody Mon Mar 27 10:35:39 2017 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 80D07127077; Mon, 27 Mar 2017 10:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhB7GZriAXhp; Mon, 27 Mar 2017 10:35: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 A7DE7124BFA; Mon, 27 Mar 2017 10:35:36 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id D62DB28B003B; Mon, 27 Mar 2017 13:35:35 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 83C071F8036; Mon, 27 Mar 2017 13:35:35 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_04B4C98E-8AE7-4E29-87A4-899CA9A47743"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Sandra Murphy In-Reply-To: Date: Mon, 27 Mar 2017 13:35:30 -0400 Cc: Sandra Murphy , RFC Errata System , iesg@ietf.org, achatz@forthnet.gr, sidr@ietf.org Message-Id: <1681FB94-57AC-4B58-B8EE-9B5B66DD013C@tislabs.com> References: <20170325111712.915D2B80A4D@rfc-editor.org> To: Randy Bush X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [sidr] [Errata Held for Document Update] RFC7115 (4973) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 17:35:38 -0000 --Apple-Mail=_04B4C98E-8AE7-4E29-87A4-899CA9A47743 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We=E2=80=99ve run into problems with the RFC5737 documentation examples = not being suitable for the types of exampes we needed. Previously, the suggestion was to put that explanation in the draft, to = prevent recurrence of a complaint. e.g. = https://mailarchive.ietf.org/arch/msg/sidr/0d99F1FOLGugyhM9JzmoDCE8KDA However, the errata in this case is not posed as a complaint about the = failure to use the documentation cases. The errata says 666 is not a valid octet for an ipv4 address That is a true statement. Randy=E2=80=99s previous response was: 666 was not accidental. That is a true statement. But I believe a short note to explain the non-accidental use of 666 is = something like: In some cultures, the number 666 is supposed to be the number of =E2=80=9C= the beast=E2=80=9D, i.e. the devil, and therefore a sign of evil. The = text chooses this number 666 in the prefix 10.0.666.0/24 with the intent = to imply that the announcement is deliberately evil, disregarding the = fact that 666 is not a legitimate ipv4 prefix octet. Of course, I=E2=80=99m not the author, so I could be wrong. =E2=80=94Sandy > On Mar 25, 2017, at 7:36 AM, Randy Bush wrote: >=20 >> I am marking this report as "Held for Document Update" [1], which >> means that the author might consider its merits for a future update. >> If the use of the "666" octet was intentional, then a short note >> explaining might be appropriate to avoid further confusion. >=20 > problem is it's not a short note. >=20 > In the current internet routing ecology, a /24 is the longest = prefix > which has a good chance at global propagation. The prefix = allocated > by RFC 5737, with much verbosity, are three non-contiguous /24s. > The result is that documents which want to discuss routable = prefixes > which involve subnetting can not use space from RFC 5737. This is = a > general problem which someone (else) should fix. >=20 > In RFC 7115, the subject of this erratum, routeable and subnettable > examples were needed. So the well-known private network 10/8, see > RFC 1918, was used in the examples. To indicate that it was not > really intended to be used, an impossible octet, 666, was chosen. >=20 > this was explained a number of times as this rfc went through the > original sausage factory. >=20 > randy >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_04B4C98E-8AE7-4E29-87A4-899CA9A47743 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 iQIcBAEBCgAGBQJY2U1qAAoJEHplpQeet0IZMr4P/00NK0wZdz9XoVimHd2FMMUL n4EApr5788ochYV38YufvNQkAG4C4vpYdwPwPMI/r6tEWeKbNBMOJYYcYsgD5GAi Nj/uYYYYdonb7QrGIgPbqD/jwF8+h1pFqhQR9gH+NsJ02BZfUKAGenCswvzyXuKy BVuWQpo2TDLsjWNXOTja+cJc+V3FZRvyer/p31fyllgU8nlhpuGYaNLhGN1xmdLB JxdVksTTCyDmFD7QMOyv1ZgqNrOwPQv0XShtDiPoVuKbE0rQhF1N8XqiDoTKWpdc ke5NmPaUP89+l0S+DUftnwoaAyttwTvdNlKqQZ8dthLDqCG7D9unRySlJk2CWda1 scb0Q2IY/5UeV+j1uDdJa7q9AUrLbciqEGxJUJMzW6/9dVLHxGK14Ae0sickEcvZ E7aAGK3ZVgvSxwKxdfoNMC4m14V5QJ44pNTwWYTUYrYGPg3pvCeFkI+iPi7cGU0l ut3o9njrQhEwDzHJuklCw/tPTIC2k7AB+h/hq5+OEiP825PrUT5Sdyw5XfJqVppr UC/aDLZL1Djbxanf0kqxSmHxxfMdrKrsXUI5EXJQUD8xy7bGwzQHWDsMtwlCqag/ oNWFFGlNmXL8X5HOt4xNlhhPR3G711KsgFD4j19N5e85afTELRgsj89H/xiboiu4 DI5xusyDpEOA41lrGfbZ =Psvp -----END PGP SIGNATURE----- --Apple-Mail=_04B4C98E-8AE7-4E29-87A4-899CA9A47743-- From nobody Mon Mar 27 11:34:56 2017 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 70F0B1205D3; Mon, 27 Mar 2017 11:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3BwwuxcZVam; Mon, 27 Mar 2017 11:34:48 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CF7E1292FC; Mon, 27 Mar 2017 11:34:48 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1csZTX-0007Lb-8g; Mon, 27 Mar 2017 18:34:43 +0000 Date: Mon, 27 Mar 2017 13:34:42 -0500 Message-ID: From: Randy Bush To: Sandra Murphy Cc: RFC Errata System , iesg@ietf.org, achatz@forthnet.gr, sidr@ietf.org In-Reply-To: <1681FB94-57AC-4B58-B8EE-9B5B66DD013C@tislabs.com> References: <20170325111712.915D2B80A4D@rfc-editor.org> <1681FB94-57AC-4B58-B8EE-9B5B66DD013C@tislabs.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-2022-JP Archived-At: Subject: Re: [sidr] [Errata Held for Document Update] RFC7115 (4973) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 18:34:49 -0000 > In some cultures, the number 666 is supposed to be the number of $B!H(Bthe > beast$B!I(B, i.e. the devil, and therefore a sign of evil. The text > chooses this number 666 in the prefix 10.0.666.0/24 with the intent to > imply that the announcement is deliberately evil, disregarding the > fact that 666 is not a legitimate ipv4 prefix octet. > > Of course, I$B!G(Bm not the author, so I could be wrong. you are, but no big deal. it could have been anything gt 255, but i knew 666 would catch the western eye. randy From nobody Thu Mar 30 12:21:51 2017 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 9E29C1296D4; Thu, 30 Mar 2017 12:21:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , morrowc@ops-netman.net, Chris Morrow , sidr-chairs@ietf.org, sidr@ietf.org, aretana@cisco.com, draft-ietf-sidr-publication@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149090170964.15554.3495686060143876488.idtracker@ietfa.amsl.com> Date: Thu, 30 Mar 2017 12:21:49 -0700 Archived-At: Subject: [sidr] Protocol Action: 'A Publication Protocol for the Resource Public Key Infrastructure (RPKI)' to Proposed Standard (draft-ietf-sidr-publication-12.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 19:21:50 -0000 The IESG has approved the following document: - 'A Publication Protocol for the Resource Public Key Infrastructure (RPKI)' (draft-ietf-sidr-publication-12.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-publication/ Technical Summary This document defines a protocol for publishing Resource Public Key Infrastructure (RPKI) objects. Even though the RPKI will have many participants issuing certificates and creating other objects, it is operationally useful to consolidate the publication of those objects. This document provides the protocol for doing so. Working Group Summary Good discussion in the WG list and meetings. Nothing specific worth noting. Document Quality There are two implementations of the publication protocol. Personnel Shepherd: Chris Morrow AD: Alvaro Retana From nobody Fri Mar 31 08:46:59 2017 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 DB91C129435; Fri, 31 Mar 2017 08:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.608 X-Spam-Level: X-Spam-Status: No, score=0.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, SUSPICIOUS_RECIPS=2.51] 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 GgBg301WeObg; Fri, 31 Mar 2017 08:46:55 -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 6DD831294DF; Fri, 31 Mar 2017 08:46:55 -0700 (PDT) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id 9DAC53FD95; Fri, 31 Mar 2017 15:46:53 +0000 (UTC) Received: from morrowc.roam.corp.google.com.ops-netman.net (dhcp-860c.meeting.ietf.org [31.133.134.12]) (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 4E0DA395433E; Fri, 31 Mar 2017 15:46:53 +0000 (UTC) Date: Fri, 31 Mar 2017 09:46:52 -0600 Message-ID: From: Chris Morrow To: sidr-chairs@ietf.org, sidrops-chairs@ietf.org, sidr-ads@ietf.org, sidrops-ads@ietf.org, sidrops@ietf.org, sidr@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-lta-use-cases-07 - ENDS 04/21/2017 (April 21 2017) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 15:46:57 -0000 howdy Sidr/SidrOps folks, I believe the draft: draft-ietf-sidr-lta-use-cases-07 has been prepared for publication, and we must decide as WGs that this is the case. As a reminder this is one of several drafts started in SIDR which was moved to SIDROPS, so this is really a 'SIDROPS WGLC', but there are still interested parties on SIDR's mailing list, so the call is going to both groups. Document 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." Please review the 5 short pages of text, send along updates/comments/complaints/'terrific work!' notes to this thread, so the authors can be aprised and we can plan to send this document in the proper direction. Thanks! -chris morrow co-chair From nobody Fri Mar 31 14:54:38 2017 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 7693A12951B; Fri, 31 Mar 2017 14:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forthnet.gr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvP9Vk5Fxw14; Fri, 31 Mar 2017 14:54:33 -0700 (PDT) Received: from zm-out-01.forthnet.gr (zm-out-01.forthnet.gr [194.219.0.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A3B012943C; Fri, 31 Mar 2017 14:54:33 -0700 (PDT) Received: from zm-in-01.cloud.forthnet.prv (zm-in-01.cloud.forthnet.prv [10.24.31.15]) by zm-out-01.forthnet.gr (Postfix) with ESMTP id C4A8E121CA5; Sat, 1 Apr 2017 00:54:28 +0300 (EEST) Received: from localhost (localhost6.localdomain6 [IPv6:::1]) by zm-in-01.cloud.forthnet.prv (Postfix) with ESMTP id AB36A120209; Sat, 1 Apr 2017 00:54:28 +0300 (EEST) X-DSPAM-Result: Spam Authentication-Results: zm-in-01.cloud.forthnet.prv (amavisd-new); dkim=pass (1024-bit key) header.d=forthnet.gr Received: from zm-in-01.cloud.forthnet.prv ([IPv6:::1]) by localhost (zm-in-01.cloud.forthnet.prv [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id UBsWsPkdkCCv; Sat, 1 Apr 2017 00:54:28 +0300 (EEST) Received: from localhost (localhost6.localdomain6 [IPv6:::1]) by zm-in-01.cloud.forthnet.prv (Postfix) with ESMTP id 365A212058A; Sat, 1 Apr 2017 00:54:28 +0300 (EEST) DKIM-Filter: OpenDKIM Filter v2.9.2 zm-in-01.cloud.forthnet.prv 365A212058A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forthnet.gr; s=zm; t=1490997268; bh=cvEp0tYuUkw5v22Ej/2CV8X3rygkXC4PjScwQ5mERrw=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=VzPll3/iEi4JK/K8eUc3OveO5fHo8vyLw/oGeTS/VZptUj9sWBPE4KRIa/rFd8mM/ ReTXN1AHtRZR+xxuxhSdkU/jlbSh4UuH6/BgcF6GZnligMfR3cl3FaDW5jZviMwb95 /AZo/zT2/+iGfotsYrOwZy4plR/Kexkfc8i4TR2k= X-Virus-Scanned: amavisd-new at zm-in-01.cloud.forthnet.prv Received: from zm-in-01.cloud.forthnet.prv ([IPv6:::1]) by localhost (zm-in-01.cloud.forthnet.prv [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id nesTS0oujEYy; Sat, 1 Apr 2017 00:54:28 +0300 (EEST) Received: from [IPv6:2a02:2149:8741:de00:c481:7dde:b705:b9e0] (unknown [IPv6:2a02:2149:8741:de00:c481:7dde:b705:b9e0]) by zm-in-01.cloud.forthnet.prv (Postfix) with ESMTPA id B72C2120209; Sat, 1 Apr 2017 00:54:27 +0300 (EEST) Message-ID: <58DED00C.4010708@forthnet.gr> Date: Sat, 01 Apr 2017 00:54:20 +0300 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32.1 MIME-Version: 1.0 To: Randy Bush , Sandra Murphy CC: RFC Errata System , iesg@ietf.org, sidr@ietf.org References: <20170325111712.915D2B80A4D@rfc-editor.org> <1681FB94-57AC-4B58-B8EE-9B5B66DD013C@tislabs.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sidr] [Errata Held for Document Update] RFC7115 (4973) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 21:54:36 -0000 Since RFC's intention is to provide guidance, i believe that saying "a fo= rged origin attack cannot succeed against 10.0.666.0/24" is a little bit = confusing, because this statement is valid even without any RPKI in place= . After all, there is another reference of a non-documentation but valid pr= efix 10.0.42.0/24 already included and imho it wouldn't do any harm to in= clude one more. -- Tassos Randy Bush wrote on 27/3/17 21:34: >> In some cultures, the number 666 is supposed to be the number of =E2=80= =9Cthe >> beast=E2=80=9D, i.e. the devil, and therefore a sign of evil. The tex= t >> chooses this number 666 in the prefix 10.0.666.0/24 with the intent to >> imply that the announcement is deliberately evil, disregarding the >> fact that 666 is not a legitimate ipv4 prefix octet. >> >> Of course, I=E2=80=99m not the author, so I could be wrong. > you are, but no big deal. it could have been anything gt 255, but i > knew 666 would catch the western eye. > > randy >