From nobody Thu Jan 5 11:01:41 2017 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE225129A4E; Thu, 29 Dec 2016 18:27:28 -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.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148306484867.30298.11938346623168784428.idtracker@ietfa.amsl.com> Date: Thu, 29 Dec 2016 18:27:28 -0800 Archived-At: X-Mailman-Approved-At: Thu, 05 Jan 2017 11:01:38 -0800 Cc: sidrops@ietf.org Subject: [Sidrops] I-D Action: draft-ietf-sidrops-lta-use-cases-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 02:27:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations of the IETF. Title : Use Cases for Localized Versions of the RPKI Author : Randy Bush Filename : draft-ietf-sidrops-lta-use-cases-00.txt Pages : 5 Date : 2016-12-29 Abstract: There are a number of critical circumstances where a localized routing domain needs to augment or modify its view of the Global RPKI. This document attempts to outline a few of them. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidrops-lta-use-cases-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 13 10:28:26 2017 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F00129D3F; Fri, 13 Jan 2017 10:28:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> Date: Fri, 13 Jan 2017 10:28:24 -0800 Archived-At: Cc: sidrops@ietf.org Subject: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 18:28:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations of the IETF. Title : Signaling Prefix Origin Validation Results from a Route-Server to Peers Authors : Thomas King Daniel Kopp Aristidis Lambrianidis Arnaud Fenioux Filename : draft-ietf-sidrops-route-server-rpki-light-00.txt Pages : 6 Date : 2017-01-13 Abstract: This document defines the usage of the BGP Prefix Origin Validation State Extended Community [I-D.ietf-sidr-origin-validation-signaling] to signal prefix origin validation results from a route-server to its peers. Upon reception of prefix origin validation results peers can use this information in their local routing decision process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-route-server-rpki-light/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidrops-route-server-rpki-light-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 13 10:40:17 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6B41294BF for ; Fri, 13 Jan 2017 10:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.134 X-Spam-Level: X-Spam-Status: No, score=-5.134 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_SOFTFAIL=0.665] 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 vtODwpNMO_9H for ; Fri, 13 Jan 2017 10:40:14 -0800 (PST) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 EF9C9129C73 for ; Fri, 13 Jan 2017 10:40:13 -0800 (PST) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cS6lo-000AJ9-GY (job@us.ntt.net); Fri, 13 Jan 2017 18:40:13 +0000 Date: Fri, 13 Jan 2017 19:40:09 +0100 From: Job Snijders To: sidrops@ietf.org Message-ID: <20170113184009.GC1055@Vurt.local> References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 18:40:16 -0000 Hi all, I have trouble with the idea proposed in this draft. It reads to me "When the route server receives a hijacked prefix, it will decorate it with an extended community and propagate it to all its peers". This is not a responsible thing to do. Route Server operators should configure there route servers to reject/drop/ignore 'RPKI invalid' announcements, and thats should be the end of it. Kind regards, Job On Fri, Jan 13, 2017 at 10:28:24AM -0800, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the SIDR Operations of the IETF. > > Title : Signaling Prefix Origin Validation Results from a Route-Server to Peers > Authors : Thomas King > Daniel Kopp > Aristidis Lambrianidis > Arnaud Fenioux > Filename : draft-ietf-sidrops-route-server-rpki-light-00.txt > Pages : 6 > Date : 2017-01-13 > > Abstract: > This document defines the usage of the BGP Prefix Origin Validation > State Extended Community [I-D.ietf-sidr-origin-validation-signaling] > to signal prefix origin validation results from a route-server to its > peers. Upon reception of prefix origin validation results peers can > use this information in their local routing decision process. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-route-server-rpki-light/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidrops-route-server-rpki-light-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Jan 13 11:08:37 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F24B129410 for ; Fri, 13 Jan 2017 11:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.134 X-Spam-Level: X-Spam-Status: No, score=-5.134 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_SOFTFAIL=0.665] 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 jokiKkw317oI for ; Fri, 13 Jan 2017 11:08:34 -0800 (PST) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FFCC129D84 for ; Fri, 13 Jan 2017 10:58:55 -0800 (PST) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cS73u-0005vA-5t (job@us.ntt.net); Fri, 13 Jan 2017 18:58:54 +0000 Date: Fri, 13 Jan 2017 19:58:51 +0100 From: Job Snijders To: Tim Bruijnzeels Message-ID: <20170113185851.GD1055@Vurt.local> References: <20161108161154.GV37681@Vurt.lan> <7C119394-504F-478E-8A16-D4C59159B619@ripe.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7C119394-504F-478E-8A16-D4C59159B619@ripe.net> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Cc: sidrops@ietf.org Subject: Re: [Sidrops] MaxLength Considered Harmful to the RPKI? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 19:08:35 -0000 On Thu, Nov 17, 2016 at 02:01:50PM +0900, Tim Bruijnzeels wrote: > First of all: good read. And I actually agree that the MaxLength > attribute should be eliminated. So how do we go about that? Kind regards, Job From nobody Fri Jan 13 11:57:47 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E194B129DB5 for ; Fri, 13 Jan 2017 11:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bCGo1F59Zk8 for ; Fri, 13 Jan 2017 11:57:43 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AAAF129B0A for ; Fri, 13 Jan 2017 11:57:43 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id k15so57271751qtg.3 for ; Fri, 13 Jan 2017 11:57:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=OokL4ZDFRPzJ/WHfpLEf1V8vgV+AamvLXW7HwhEmlFI=; b=ltlpRYIBVJ/SnoPlN79LV+Q8H6OUCKVu4AawROiPiOewPfC4NunXXkY50w+UtIBIiF 3Bumd3AuM9gAMxhN487CKb7P7C6vx6N9UnZl7s//nIxWtJBjOnxOmDr1HODX+wkIgllX HauODj4dyVv8BwnNeH4lNMhf0XPoq0GWPDMSmNpyJOwV5BCxkp70Ftes2Ad9WSSkQs2Q vJqm+wyEyWMuhZGLD2C0aU955WoXDnGkIQ2gGJ5HS6OcCjOn87NSV41N1m/x4t6EG3oG 43/8Utrfk6GrfIFNWJa6puQqIKY0eeIJLI7PpzoRmb7+l8x2LwIeelJnXcR4isQ2CAOV Ex3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=OokL4ZDFRPzJ/WHfpLEf1V8vgV+AamvLXW7HwhEmlFI=; b=oh0TSYbqKjqg6z182YgSCwVXwjbI/sA5JymLdaE1eeIasv4Tc83BjCyx+SSs6BkaTh OMjZuy6KBEEFjllgbsS+kF4S80lRNMR2CPS6hTYWZFZvIbpXKjxzoX85rYudGR4C0zCn +2+u/u0QbD1iaNvtprNnUb8D3Qp2BstNrTaCHu8m+jzzjwqHS+MfY6bvk3mLKMiB7Jom l4AczoL8elajqSiyRUwJLVKLR9d4/fhJP3VhrcXuQiHZr/T6mAnxhfjXOF7nT4tYPmzs vX/OtN3GkKhz5/p6uUnKRYJER5p/yuRjWKociZzxOghC44A32JupmydZayTelgzhidkU LWaQ== X-Gm-Message-State: AIkVDXLAZxOX8nzR88wCvcX5rKENxOuWOgJkHV08ebX1hmuMOKqF9gESPufLc0xHTdn92Q== X-Received: by 10.237.50.66 with SMTP id y60mr19644242qtd.12.1484337462453; Fri, 13 Jan 2017 11:57:42 -0800 (PST) Received: from [192.168.99.1] ([2001:13c7:7001:7000:d8ef:8084:396e:fafa]) by smtp.gmail.com with ESMTPSA id x40sm9962634qtx.12.2017.01.13.11.57.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jan 2017 11:57:41 -0800 (PST) From: "Carlos M. Martinez" To: "Job Snijders" Date: Fri, 13 Jan 2017 16:57:39 -0300 Message-ID: <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> In-Reply-To: <20170113184009.GC1055@Vurt.local> References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: sidrops@ietf.org Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 19:57:46 -0000 Hi Job, I believe what what you propose would be deciding on behalf of people who are not your customers and with whom you only have a loose relationship based on sharing something. I don´t think a route server should in fact drop invalid routes when re-announcing them to the other peers. I understand that this could be different depending on the arrangements among members of the IXP, but, I like to have the option for marking open. Cheers! -Carlos On 13 Jan 2017, at 15:40, Job Snijders wrote: > Hi all, > > I have trouble with the idea proposed in this draft. It reads to me > "When the route server receives a hijacked prefix, it will decorate it > with an extended community and propagate it to all its peers". > > This is not a responsible thing to do. Route Server operators should > configure there route servers to reject/drop/ignore 'RPKI invalid' > announcements, and thats should be the end of it. > > Kind regards, > > Job > > On Fri, Jan 13, 2017 at 10:28:24AM -0800, internet-drafts@ietf.org > wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the SIDR Operations of the IETF. >> >> Title : Signaling Prefix Origin Validation Results >> from a Route-Server to Peers >> Authors : Thomas King >> Daniel Kopp >> Aristidis Lambrianidis >> Arnaud Fenioux >> Filename : draft-ietf-sidrops-route-server-rpki-light-00.txt >> Pages : 6 >> Date : 2017-01-13 >> >> Abstract: >> This document defines the usage of the BGP Prefix Origin >> Validation >> State Extended Community >> [I-D.ietf-sidr-origin-validation-signaling] >> to signal prefix origin validation results from a route-server to >> its >> peers. Upon reception of prefix origin validation results peers >> can >> use this information in their local routing decision process. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sidrops-route-server-rpki-light/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-sidrops-route-server-rpki-light-00 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Jan 13 12:13:20 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6673129DEA for ; Fri, 13 Jan 2017 12:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.133 X-Spam-Level: X-Spam-Status: No, score=-5.133 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_SOFTFAIL=0.665] 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 6Gxcqkkp3baa for ; Fri, 13 Jan 2017 12:13:17 -0800 (PST) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 F3D1E129DF8 for ; Fri, 13 Jan 2017 12:13:16 -0800 (PST) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cS8Dr-00034j-4p (job@us.ntt.net); Fri, 13 Jan 2017 20:13:16 +0000 Date: Fri, 13 Jan 2017 21:13:01 +0100 From: job@ntt.net To: "Carlos M. Martinez" Message-ID: <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> In-Reply-To: <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> X-Readdle-Message-ID: 7f08f967-247e-4060-b643-52bc45d8ab29@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="587934d6_6b8b4567_347" Archived-At: Cc: sidrops@ietf.org Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 20:13:19 -0000 --587934d6_6b8b4567_347 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I am advocating a strong security posture, in which each ASN takes their = responsibility to the best of their abilities in maintaining a healthy gl= obal routing system. KNOWINGLY distributing routes which are considered I= nvalid is the wrong thing to do. If an ASN (read Route Server) doesn't want to participate in keeping the = routing system clean, they should perhaps consider ceasing their BGP oper= ations, but certainly not hide under the guise of =22offering customers a= ll options=22. An autonomous system is an autonomous system. IXP operators do not get a = free pass to propagate garbage, the same garbage we expect the rest of th= e operators to reject. This draft promotes an insecure mode of operation. Kind regards, Job On 13 Jan 2017, 20:57 +0100, Carlos M. Martinez = , wrote: > Hi Job, > > I believe what what you propose would be deciding on behalf of people > who are not your customers and with whom you only have a loose > relationship based on sharing something. I don=C2=B4t think a route ser= ver > should in fact drop invalid routes when re-announcing them to the other= > peers. > > I understand that this could be different depending on the arrangements= > among members of the IXP, but, I like to have the option for marking > open. > > Cheers=21 > > -Carlos > > On 13 Jan 2017, at 15:40, Job Snijders wrote: > > > Hi all, > > > > I have trouble with the idea proposed in this draft. It reads to me > > =22When the route server receives a hijacked prefix, it will decorate= it > > with an extended community and propagate it to all its peers=22. > > > > This is not a responsible thing to do. Route Server operators should > > configure there route servers to reject/drop/ignore 'RPKI invalid' > > announcements, and thats should be the end of it. > > > > Kind regards, > > > > Job > > > > On =46ri, Jan 13, 2017 at 10:28:24AM -0800, internet-drafts=40ietf.or= g > > wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > This draft is a work item of the SIDR Operations of the IET=46. > > > > > > Title : Signaling Prefix Origin Validation Results > > > from a Route-Server to Peers > > > Authors : Thomas King > > > Daniel Kopp > > > Aristidis Lambrianidis > > > Arnaud =46enioux > > > =46ilename : draft-ietf-sidrops-route-server-rpki-light-00.txt > > > Pages : 6 > > > Date : 2017-01-13 > > > > > > Abstract: > > > This document defines the usage of the BGP Prefix Origin > > > Validation > > > State Extended Community > > > =5BI-D.ietf-sidr-origin-validation-signaling=5D > > > to signal prefix origin validation results from a route-server to > > > its > > > peers. Upon reception of prefix origin validation results peers > > > can > > > use this information in their local routing decision process. > > > > > > > > > > > > The IET=46 datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-sidrops-route-server-rp= ki-light/ > > > > > > There's also a htmlized version available at: > > > https://tools.ietf.org/html/draft-ietf-sidrops-route-server-rpki-li= ght-00 > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission > > > until the htmlized version and diff are available at tools.ietf.org= . > > > > > > Internet-Drafts are also available by anonymous =46TP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > > Sidrops mailing list > > > Sidrops=40ietf.org > > > https://www.ietf.org/mailman/listinfo/sidrops > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > Sidrops mailing list > > Sidrops=40ietf.org > > https://www.ietf.org/mailman/listinfo/sidrops > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Sidrops mailing list > Sidrops=40ietf.org > https://www.ietf.org/mailman/listinfo/sidrops --587934d6_6b8b4567_347 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
I am advocating a strong security po= sture, in which each ASN takes their responsibility to the best of their = abilities in maintaining a healthy global routing system. KNOWINGLY distr= ibuting routes which are considered Invalid is the wrong thing to do.

If an ASN (read Route Server) doesn't want to participate in keeping the = routing system clean, they should perhaps consider ceasing their BGP oper= ations, but certainly not hide under the guise of =22offering customers a= ll options=22.

An autonomous system is an autonomous system. IXP operators do not get a = free pass to propagate garbage, the same garbage we expect the rest of th= e operators to reject.

This draft promotes an insecure mode of operation.

Kind regards,

Job



On 13 Jan 2017, 20:57 +0100, Carlos M. Martinez <carlosm3011=40gmail.c= om>, wrote:
Hi Job,

I believe what what you propose would be deciding on behalf of people
who are not your customers and with whom you only have a loose
relationship based on sharing something. I don=C2=B4t think a route serve= r
should in fact drop invalid routes when re-announcing them to the other peers.

I understand that this could be different depending on the arrangements among members of the IXP, but, I like to have the option for marking
open.

Cheers=21

-Carlos

On 13 Jan 2017, at 15:40, Job Snijders wrote:

Hi all,

I have trouble with the idea proposed in this draft. It reads to me
= =22When the route server receives a hijacked prefix, it will decorate it<= br /> with an extended community and propagate it to all its peers=22.

This is not a responsible thing to do. Route Server operators should
configure there route servers to reject/drop/ignore 'RPKI invalid'
announcements, and thats should be the end of it.

Kind regards,

Job

On =46ri, Jan 13, 2017 at 10:28:24AM -0800, internet-drafts=40ietf.org wrote:

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

Title : Signaling Prefix Origin Validation Results
from a Route-Server to Peers
Authors : Thomas King
Daniel Kopp
Aristidis Lambrianidis
Arnaud =46enioux
=46ilename : draft-ietf-sidrops-route-server-rpki-light-00.txt
Pages : 6
Date : 2017-01-13

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



The IET=46 datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-route-server-rpki-lig= ht/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-sidrops-route-server-rpki-light-00=


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

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

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sidrops mailing list
Sidrops=40ietf.org
https://www.ietf.org/mailman/listinfo/sidrops

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sidrops mailing list
Sidrops=40ietf.org
https://www.ietf.org/mailman/listinfo/sidrops

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sidrops mailing list
Sidrops=40ietf.org
https://www.ietf.org/mailman/listinfo/sidrops
--587934d6_6b8b4567_347-- From nobody Fri Jan 13 12:18:56 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8668129C3D for ; Fri, 13 Jan 2017 12:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHFyrBNHrNOk for ; Fri, 13 Jan 2017 12:18:52 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34B60129505 for ; Fri, 13 Jan 2017 12:18:52 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id x49so57655066qtc.2 for ; Fri, 13 Jan 2017 12:18:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:embedded-html; bh=ruGG3xcRDxL42IWvRXmK0UXufH6+Pd/FZKpv6ZCcgOQ=; b=FlFabg9KbcH+vwx/rekaNoMtSzrke/MOvHJLIikjkBRiMvAb6mhvjlUfwCbffXO1wQ jITb34+q2i7Gfo8ld9Yr/taVAxklPWEUvb0qa6Utbw1i3F+N5+g2VDIHWBvy0nWMhZza 6GP3rm3pGWiQFNXVmS7bNglxV+XmbFQilMBCObX0TE8D9XyxA6ZqJ1XqbO14M04BvKBq Cxmnh+7DwFT4mXXc/VhlqhB9DF59CtW+S3UTh4puaWKmTiaMMpOl8K5Qb7j3l/0NnSaq IfVZQNOqaXo1zHIBN2bwQYr1nMviG6Kty7Kqg3oibqfC2Rs5Jo49oYXzlcvny099vUwA iOnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:embedded-html; bh=ruGG3xcRDxL42IWvRXmK0UXufH6+Pd/FZKpv6ZCcgOQ=; b=E4aBg2o2R/6xP8rrBOzE6QvN5DjmXYNy4HE3AwpSb1K12bMPeVHrf0/PTcdPmzAQ38 OgTeB8tjehdhO8AuUSLNRvzHfgD0HO/Z3Kka9rgy5rYg5zXuZEq+cJ1igY5rnRJaFv5b pmg8+ccfXqKsgKvSsW9eCyEEkv0MzmhW6yiiMhLwwFpgxPjGDk9tlVHjbP3gG62ArhmY nYeLqKDA4OHVfYuQtVq1VK3z4DI4/LOkKSGsl89D/u8CQik06CDIZEZD2ye8TcMAW792 zY98u6MrQxNZf+8hhwKCoQ81Jv3j3dP1xSOttdjsWvI1xJe3VO45oKZ3p1YbdB3qgzQa pofA== X-Gm-Message-State: AIkVDXLViFxDFf6zHqkfHz6JDHBrGZJ0CvYN7bfAFEaK5Uwy5Pw151IAr3TSyunbhrRIeA== X-Received: by 10.200.52.27 with SMTP id u27mr21041406qtb.26.1484338731226; Fri, 13 Jan 2017 12:18:51 -0800 (PST) Received: from [192.168.99.1] ([2001:13c7:7001:7000:d8ef:8084:396e:fafa]) by smtp.gmail.com with ESMTPSA id g130sm9904966qkb.35.2017.01.13.12.18.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jan 2017 12:18:50 -0800 (PST) From: "Carlos M. Martinez" To: job@ntt.net Date: Fri, 13 Jan 2017 17:18:48 -0300 Message-ID: <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> In-Reply-To: <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_9B752D6F-FE6C-44EF-8DBD-2809E282E12E_=" Embedded-HTML: [{"HTML":[1607, 4304], "plain":[292, 3808], "uuid":"0379D2DD-FC35-4880-892D-CC86B4334798"}] X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: sidrops@ietf.org Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 20:18:55 -0000 --=_MailMate_9B752D6F-FE6C-44EF-8DBD-2809E282E12E_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable We agree to disagree then. I strongly believe the Internet strives to = delegate decision making and doesn=E2=80=99t like hierarchies very much. I=E2=80=99d prefer these decisions to be delegated as far away from the = network=C2=B4s core as possible. -Carlos On 13 Jan 2017, at 17:13, job@ntt.net wrote: > I am advocating a strong security posture, in which each ASN takes = > their responsibility to the best of their abilities in maintaining a = > healthy global routing system. KNOWINGLY distributing routes which are = > considered Invalid is the wrong thing to do. > > If an ASN (read Route Server) doesn't want to participate in keeping = > the routing system clean, they should perhaps consider ceasing their = > BGP operations, but certainly not hide under the guise of "offering = > customers all options". > > An autonomous system is an autonomous system. IXP operators do not get = > a free pass to propagate garbage, the same garbage we expect the rest = > of the operators to reject. > > This draft promotes an insecure mode of operation. > > Kind regards, > > Job > > On 13 Jan 2017, 20:57 +0100, Carlos M. Martinez = > , wrote: >> Hi Job, >> >> I believe what what you propose would be deciding on behalf of people >> who are not your customers and with whom you only have a loose >> relationship based on sharing something. I don=C2=B4t think a route = >> server >> should in fact drop invalid routes when re-announcing them to the = >> other >> peers. >> >> I understand that this could be different depending on the = >> arrangements >> among members of the IXP, but, I like to have the option for marking >> open. >> >> Cheers! >> >> -Carlos >> >> On 13 Jan 2017, at 15:40, Job Snijders wrote: >> >>> Hi all, >>> >>> I have trouble with the idea proposed in this draft. It reads to me >>> "When the route server receives a hijacked prefix, it will decorate = >>> it >>> with an extended community and propagate it to all its peers". >>> >>> This is not a responsible thing to do. Route Server operators should >>> configure there route servers to reject/drop/ignore 'RPKI invalid' >>> announcements, and thats should be the end of it. >>> >>> Kind regards, >>> >>> Job >>> >>> On Fri, Jan 13, 2017 at 10:28:24AM -0800, internet-drafts@ietf.org >>> wrote: >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the SIDR Operations of the IETF. >>>> >>>> Title : Signaling Prefix Origin Validation Results >>>> from a Route-Server to Peers >>>> Authors : Thomas King >>>> Daniel Kopp >>>> Aristidis Lambrianidis >>>> Arnaud Fenioux >>>> Filename : draft-ietf-sidrops-route-server-rpki-light-00.txt >>>> Pages : 6 >>>> Date : 2017-01-13 >>>> >>>> Abstract: >>>> This document defines the usage of the BGP Prefix Origin >>>> Validation >>>> State Extended Community >>>> [I-D.ietf-sidr-origin-validation-signaling] >>>> to signal prefix origin validation results from a route-server to >>>> its >>>> peers. Upon reception of prefix origin validation results peers >>>> can >>>> use this information in their local routing decision process. >>>> >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-sidrops-route-server-rpk= i-light/ >>>> >>>> There's also a htmlized version available at: >>>> https://tools.ietf.org/html/draft-ietf-sidrops-route-server-rpki-lig= ht-00 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at = >>>> tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> Sidrops mailing list >>>> Sidrops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sidrops >>> >>> _______________________________________________ >>> Sidrops mailing list >>> Sidrops@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidrops >> >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops --=_MailMate_9B752D6F-FE6C-44EF-8DBD-2809E282E12E_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

We agree to disagree then. I str= ongly believe the Internet strives to delegate decision making and doesn=E2= =80=99t like hierarchies very much.

I=E2=80=99d prefer these decisions to be delegated as far= away from the network=C2=B4s core as possible.

-Carlos

On 13 Jan 2017, at 17:13, job@ntt.net wrote:

I am advocating a strong security postur= e, in which each ASN takes their responsibility to the best of their abil= ities in maintaining a healthy global routing system. KNOWINGLY distribut= ing routes which are considered Invalid is the wrong thing to do.

If an ASN (read Route Server) doesn't want to participate in keeping the = routing system clean, they should perhaps consider ceasing their BGP oper= ations, but certainly not hide under the guise of "offering customers all= options".

An autonomous system is an autonomous system. IXP operators do not get a = free pass to propagate garbage, the same garbage we expect the rest of th= e operators to reject.

This draft promotes an insecure mode of operation.

Kind regards,

Job



On 13 Jan 2017, 20:57 +0100, Carlos M. Martinez <carlosm3011@gmail.com= >, wrote:
Hi Job,

I believe what what you propose would be deciding on behalf of people
who are not your customers and with whom you only have a loose
relationship based on sharing something. I don=C2=B4t think a route serve= r
should in fact drop invalid routes when re-announcing them to the other peers.

I understand that this could be different depending on the arrangements among members of the IXP, but, I like to have the option for marking
open.

Cheers!

-Carlos

On 13 Jan 2017, at 15:40, Job Snijders wrote:

Hi all,

I have trouble with the idea proposed in this draft. It reads to me
= "When the route server receives a hijacked prefix, it will decorate it with an extended community and propagate it to all its peers".

This is not a responsible thing to do. Route Server operators should
configure there route servers to reject/drop/ignore 'RPKI invalid'
announcements, and thats should be the end of it.

Kind regards,

Job

On Fri, Jan 13, 2017 at 10:28:24AM -0800, internet-drafts@ietf.org
wrote:

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

Title : Signaling Prefix Origin Validation Results
from a Route-Server to Peers
Authors : Thomas King
Daniel Kopp
Aristidis Lambrianidis
Arnaud Fenioux
Filename : draft-ietf-sidrops-route-server-rpki-light-00.txt
Pages : 6
Date : 2017-01-13

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



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-route-server-rpki-lig= ht/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-sidrops-route-server-rpki-light-00=


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

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

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

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

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops
--=_MailMate_9B752D6F-FE6C-44EF-8DBD-2809E282E12E_=-- From nobody Fri Jan 13 12:28:38 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87FFF129453 for ; Fri, 13 Jan 2017 12:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.133 X-Spam-Level: X-Spam-Status: No, score=-5.133 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_SOFTFAIL=0.665] 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 ahvlGhWo3zkv for ; Fri, 13 Jan 2017 12:28:35 -0800 (PST) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8680C129445 for ; Fri, 13 Jan 2017 12:28:35 -0800 (PST) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cS8Sf-000G1x-3U (job@us.ntt.net); Fri, 13 Jan 2017 20:28:35 +0000 Date: Fri, 13 Jan 2017 21:28:08 +0100 From: job@ntt.net To: "Carlos M. Martinez" Message-ID: In-Reply-To: <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> X-Readdle-Message-ID: e7bc58c8-33b3-4d27-a028-759b5435e685@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5879386c_643c9869_347" Archived-At: Cc: sidrops@ietf.org Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 20:28:37 -0000 --5879386c_643c9869_347 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline That is just lazy=21 =22someone else will fix it, this is not my problem=22= . Owners of Autonomous Systems (including Route server operators) should be= encouraged to take responsibility, not delegate it=21 Kind regards, Job On 13 Jan 2017, 21:18 +0100, Carlos M. Martinez = , wrote: > > We agree to disagree then. I strongly believe the Internet strives to d= elegate decision making and doesn=E2=80=99t like hierarchies very much. > > > I=E2=80=99d prefer these decisions to be delegated as far away from the= network=C2=B4s core as possible. > > > -Carlos > > > On 13 Jan 2017, at 17:13, job=40ntt.net wrote: > > > > I am advocating a strong security posture, in which each ASN takes th= eir responsibility to the best of their abilities in maintaining a health= y global routing system. KNOWINGLY distributing routes which are consider= ed Invalid is the wrong thing to do. > > > > If an ASN (read Route Server) doesn't want to participate in keeping = the routing system clean, they should perhaps consider ceasing their BGP = operations, but certainly not hide under the guise of =22offering custome= rs all options=22. > > > > An autonomous system is an autonomous system. IXP operators do not ge= t a free pass to propagate garbage, the same garbage we expect the rest o= f the operators to reject. > > > > This draft promotes an insecure mode of operation. > > > > Kind regards, > > > > Job > > > > > > > > On 13 Jan 2017, 20:57 +0100, Carlos M. Martinez , wrote: > > > Hi Job, > > > > > > I believe what what you propose would be deciding on behalf of peop= le > > > who are not your customers and with whom you only have a loose > > > relationship based on sharing something. I don=C2=B4t think a route= server > > > should in fact drop invalid routes when re-announcing them to the o= ther > > > peers. > > > > > > I understand that this could be different depending on the arrangem= ents > > > among members of the IXP, but, I like to have the option for markin= g > > > open. > > > > > > Cheers=21 > > > > > > -Carlos > > > > > > On 13 Jan 2017, at 15:40, Job Snijders wrote: > > > > > > > Hi all, > > > > > > > > I have trouble with the idea proposed in this draft. It reads to = me > > > > =22When the route server receives a hijacked prefix, it will deco= rate it > > > > with an extended community and propagate it to all its peers=22. > > > > > > > > This is not a responsible thing to do. Route Server operators sho= uld > > > > configure there route servers to reject/drop/ignore 'RPKI invalid= ' > > > > announcements, and thats should be the end of it. > > > > > > > > Kind regards, > > > > > > > > Job > > > > > > > > On =46ri, Jan 13, 2017 at 10:28:24AM -0800, internet-drafts=40iet= f.org > > > > wrote: > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Dra= fts > > > > > directories. > > > > > This draft is a work item of the SIDR Operations of the IET=46.= > > > > > > > > > > Title : Signaling Prefix Origin Validation Results > > > > > from a Route-Server to Peers > > > > > Authors : Thomas King > > > > > Daniel Kopp > > > > > Aristidis Lambrianidis > > > > > Arnaud =46enioux > > > > > =46ilename : draft-ietf-sidrops-route-server-rpki-light-00.txt > > > > > Pages : 6 > > > > > Date : 2017-01-13 > > > > > > > > > > Abstract: > > > > > This document defines the usage of the BGP Prefix Origin > > > > > Validation > > > > > State Extended Community > > > > > =5BI-D.ietf-sidr-origin-validation-signaling=5D > > > > > to signal prefix origin validation results from a route-server = to > > > > > its > > > > > peers. Upon reception of prefix origin validation results peers= > > > > > can > > > > > use this information in their local routing decision process. > > > > > > > > > > > > > > > > > > > > The IET=46 datatracker status page for this draft is: > > > > > https://datatracker.ietf.org/doc/draft-ietf-sidrops-route-serve= r-rpki-light/ > > > > > > > > > > There's also a htmlized version available at: > > > > > https://tools.ietf.org/html/draft-ietf-sidrops-route-server-rpk= i-light-00 > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time = of > > > > > submission > > > > > until the htmlized version and diff are available at tools.ietf= .org. > > > > > > > > > > Internet-Drafts are also available by anonymous =46TP at: > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > > > > > Sidrops mailing list > > > > > Sidrops=40ietf.org > > > > > https://www.ietf.org/mailman/listinfo/sidrops > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > > > > Sidrops mailing list > > > > Sidrops=40ietf.org > > > > https://www.ietf.org/mailman/listinfo/sidrops > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > > Sidrops mailing list > > > Sidrops=40ietf.org > > > https://www.ietf.org/mailman/listinfo/sidrops --5879386c_643c9869_347 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
That is just lazy=21 =22someone else= will fix it, this is not my problem=22.

Owners of Autonomous Systems (including Route server operators) should be= encouraged to take responsibility, not delegate it=21

Kind regards,

Job



On 13 Jan 2017, 21:18 +0100, Carlos M. Martinez <carlosm3011=40gmail.c= om>, wrote:

We agree to disagree then. I strongly believe the Int= ernet strives to delegate decision making and doesn=E2=80=99t like hierar= chies very much.

I=E2=80=99d prefer these decisions to be delegated as= far away from the network=C2=B4s core as possible.

-Carlos

On 13 Jan 2017, at 17:13, job=40ntt.net wrote:

I am advocating a strong security po= sture, in which each ASN takes their responsibility to the best of their = abilities in maintaining a healthy global routing system. KNOWINGLY distr= ibuting routes which are considered Invalid is the wrong thing to do.

If an ASN (read Route Server) doesn't want to participate in keeping the = routing system clean, they should perhaps consider ceasing their BGP oper= ations, but certainly not hide under the guise of =22offering customers a= ll options=22.

An autonomous system is an autonomous system. IXP operators do not get a = free pass to propagate garbage, the same garbage we expect the rest of th= e operators to reject.

This draft promotes an insecure mode of operation.

Kind regards,

Job



On 13 Jan 2017, 20:57 +0100, Carlos M. Martinez <carlosm3011=40gmail.c= om>, wrote:
Hi Job,

I believe what what you propose would be deciding on behalf of people
who are not your customers and with whom you only have a loose
relationship based on sharing something. I don=C2=B4t think a route serve= r
should in fact drop invalid routes when re-announcing them to the other peers.

I understand that this could be different depending on the arrangements among members of the IXP, but, I like to have the option for marking
open.

Cheers=21

-Carlos

On 13 Jan 2017, at 15:40, Job Snijders wrote:

Hi all,

I have trouble with the idea proposed in this draft. It reads to me
= =22When the route server receives a hijacked prefix, it will decorate it<= br /> with an extended community and propagate it to all its peers=22.

This is not a responsible thing to do. Route Server operators should
configure there route servers to reject/drop/ignore 'RPKI invalid'
announcements, and thats should be the end of it.

Kind regards,

Job

On =46ri, Jan 13, 2017 at 10:28:24AM -0800, internet-drafts=40ietf.org wrote:

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

Title : Signaling Prefix Origin Validation Results
from a Route-Server to Peers
Authors : Thomas King
Daniel Kopp
Aristidis Lambrianidis
Arnaud =46enioux
=46ilename : draft-ietf-sidrops-route-server-rpki-light-00.txt
Pages : 6
Date : 2017-01-13

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



The IET=46 datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-route-server-rpki-lig= ht/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-sidrops-route-server-rpki-light-00=


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

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

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sidrops mailing list
Sidrops=40ietf.org
https://www.ietf.org/mailman/listinfo/sidrops

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sidrops mailing list
Sidrops=40ietf.org
https://www.ietf.org/mailman/listinfo/sidrops

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sidrops mailing list
Sidrops=40ietf.org
https://www.ietf.org/mailman/listinfo/sidrops
--5879386c_643c9869_347-- From nobody Fri Jan 13 12:53:17 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A473129E46; Fri, 13 Jan 2017 12:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.133 X-Spam-Level: X-Spam-Status: No, score=-5.133 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_SOFTFAIL=0.665] 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 ahkssnuexStP; Fri, 13 Jan 2017 12:53:10 -0800 (PST) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 F0F4E129E40; Fri, 13 Jan 2017 12:53:09 -0800 (PST) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cS8qS-0007Fd-32 (job@us.ntt.net); Fri, 13 Jan 2017 20:53:09 +0000 Date: Fri, 13 Jan 2017 21:52:54 +0100 From: job@ntt.net To: "Carlos M. Martinez" Message-ID: In-Reply-To: <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> X-Readdle-Message-ID: c55845cc-ca06-45c8-9b2e-075421d0447c@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="58793e2f_6b8b4567_108" Archived-At: Cc: sidrops@ietf.org, GMO Crops Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 20:53:12 -0000 --58793e2f_6b8b4567_108 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Adding grow=40ietf.org for reality check. On 13 Jan 2017, 21:19 +0100, Carlos M. Martinez = , wrote: > > We agree to disagree then. I strongly believe the Internet strives to d= elegate decision making and doesn=E2=80=99t like hierarchies very much. > > > I=E2=80=99d prefer these decisions to be delegated as far away from the= network=C2=B4s core as possible. > > > -Carlos > > > On 13 Jan 2017, at 17:13, job=40ntt.net wrote: > > > > I am advocating a strong security posture, in which each ASN takes th= eir responsibility to the best of their abilities in maintaining a health= y global routing system. KNOWINGLY distributing routes which are consider= ed Invalid is the wrong thing to do. > > > > If an ASN (read Route Server) doesn't want to participate in keeping = the routing system clean, they should perhaps consider ceasing their BGP = operations, but certainly not hide under the guise of =22offering custome= rs all options=22. > > > > An autonomous system is an autonomous system. IXP operators do not ge= t a free pass to propagate garbage, the same garbage we expect the rest o= f the operators to reject. > > > > This draft promotes an insecure mode of operation. > > > > Kind regards, > > > > Job > > > > > > > > On 13 Jan 2017, 20:57 +0100, Carlos M. Martinez , wrote: > > > Hi Job, > > > > > > I believe what what you propose would be deciding on behalf of peop= le > > > who are not your customers and with whom you only have a loose > > > relationship based on sharing something. I don=C2=B4t think a route= server > > > should in fact drop invalid routes when re-announcing them to the o= ther > > > peers. > > > > > > I understand that this could be different depending on the arrangem= ents > > > among members of the IXP, but, I like to have the option for markin= g > > > open. > > > > > > Cheers=21 > > > > > > -Carlos > > > > > > On 13 Jan 2017, at 15:40, Job Snijders wrote: > > > > > > > Hi all, > > > > > > > > I have trouble with the idea proposed in this draft. It reads to = me > > > > =22When the route server receives a hijacked prefix, it will deco= rate it > > > > with an extended community and propagate it to all its peers=22. > > > > > > > > This is not a responsible thing to do. Route Server operators sho= uld > > > > configure there route servers to reject/drop/ignore 'RPKI invalid= ' > > > > announcements, and thats should be the end of it. > > > > > > > > Kind regards, > > > > > > > > Job > > > > > > > > On =46ri, Jan 13, 2017 at 10:28:24AM -0800, internet-drafts=40iet= f.org > > > > wrote: > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Dra= fts > > > > > directories. > > > > > This draft is a work item of the SIDR Operations of the IET=46.= > > > > > > > > > > Title : Signaling Prefix Origin Validation Results > > > > > from a Route-Server to Peers > > > > > Authors : Thomas King > > > > > Daniel Kopp > > > > > Aristidis Lambrianidis > > > > > Arnaud =46enioux > > > > > =46ilename : draft-ietf-sidrops-route-server-rpki-light-00.txt > > > > > Pages : 6 > > > > > Date : 2017-01-13 > > > > > > > > > > Abstract: > > > > > This document defines the usage of the BGP Prefix Origin > > > > > Validation > > > > > State Extended Community > > > > > =5BI-D.ietf-sidr-origin-validation-signaling=5D > > > > > to signal prefix origin validation results from a route-server = to > > > > > its > > > > > peers. Upon reception of prefix origin validation results peers= > > > > > can > > > > > use this information in their local routing decision process. > > > > > > > > > > > > > > > > > > > > The IET=46 datatracker status page for this draft is: > > > > > https://datatracker.ietf.org/doc/draft-ietf-sidrops-route-serve= r-rpki-light/ > > > > > > > > > > There's also a htmlized version available at: > > > > > https://tools.ietf.org/html/draft-ietf-sidrops-route-server-rpk= i-light-00 > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time = of > > > > > submission > > > > > until the htmlized version and diff are available at tools.ietf= .org. > > > > > > > > > > Internet-Drafts are also available by anonymous =46TP at: > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > > > > > Sidrops mailing list > > > > > Sidrops=40ietf.org > > > > > https://www.ietf.org/mailman/listinfo/sidrops > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > > > > Sidrops mailing list > > > > Sidrops=40ietf.org > > > > https://www.ietf.org/mailman/listinfo/sidrops > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > > Sidrops mailing list > > > Sidrops=40ietf.org > > > https://www.ietf.org/mailman/listinfo/sidrops > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Sidrops mailing list > Sidrops=40ietf.org > https://www.ietf.org/mailman/listinfo/sidrops --58793e2f_6b8b4567_108 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Adding grow=40ietf.org for reality c= heck.


On 13 Jan 2017, 21:19 +0100, Carlos M. Martinez <carlosm3011=40gmail.c= om>, wrote:

We agree to disagree then. I strongly believe the Int= ernet strives to delegate decision making and doesn=E2=80=99t like hierar= chies very much.

I=E2=80=99d prefer these decisions to be delegated as= far away from the network=C2=B4s core as possible.

-Carlos

On 13 Jan 2017, at 17:13, job=40ntt.net wrote:

I am advocating a strong security po= sture, in which each ASN takes their responsibility to the best of their = abilities in maintaining a healthy global routing system. KNOWINGLY distr= ibuting routes which are considered Invalid is the wrong thing to do.

If an ASN (read Route Server) doesn't want to participate in keeping the = routing system clean, they should perhaps consider ceasing their BGP oper= ations, but certainly not hide under the guise of =22offering customers a= ll options=22.

An autonomous system is an autonomous system. IXP operators do not get a = free pass to propagate garbage, the same garbage we expect the rest of th= e operators to reject.

This draft promotes an insecure mode of operation.

Kind regards,

Job



On 13 Jan 2017, 20:57 +0100, Carlos M. Martinez <carlosm3011=40gmail.c= om>, wrote:
Hi Job,

I believe what what you propose would be deciding on behalf of people
who are not your customers and with whom you only have a loose
relationship based on sharing something. I don=C2=B4t think a route serve= r
should in fact drop invalid routes when re-announcing them to the other peers.

I understand that this could be different depending on the arrangements among members of the IXP, but, I like to have the option for marking
open.

Cheers=21

-Carlos

On 13 Jan 2017, at 15:40, Job Snijders wrote:

Hi all,

I have trouble with the idea proposed in this draft. It reads to me
= =22When the route server receives a hijacked prefix, it will decorate it<= br /> with an extended community and propagate it to all its peers=22.

This is not a responsible thing to do. Route Server operators should
configure there route servers to reject/drop/ignore 'RPKI invalid'
announcements, and thats should be the end of it.

Kind regards,

Job

On =46ri, Jan 13, 2017 at 10:28:24AM -0800, internet-drafts=40ietf.org wrote:

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

Title : Signaling Prefix Origin Validation Results
from a Route-Server to Peers
Authors : Thomas King
Daniel Kopp
Aristidis Lambrianidis
Arnaud =46enioux
=46ilename : draft-ietf-sidrops-route-server-rpki-light-00.txt
Pages : 6
Date : 2017-01-13

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



The IET=46 datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-route-server-rpki-lig= ht/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-sidrops-route-server-rpki-light-00=


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

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

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sidrops mailing list
Sidrops=40ietf.org
https://www.ietf.org/mailman/listinfo/sidrops

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sidrops mailing list
Sidrops=40ietf.org
https://www.ietf.org/mailman/listinfo/sidrops

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sidrops mailing list
Sidrops=40ietf.org
https://www.ietf.org/mailman/listinfo/sidrops
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sidrops mailing list
Sidrops=40ietf.org
https://www.ietf.org/mailman/listinfo/sidrops
--58793e2f_6b8b4567_108-- From nobody Fri Jan 13 13:20:26 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7A8129B60; Fri, 13 Jan 2017 13:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 5BpxLwQTwAsQ; Fri, 13 Jan 2017 13:20: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 C9B13129451; Fri, 13 Jan 2017 13:20:23 -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 1cS9Gl-0000v5-BB; Fri, 13 Jan 2017 21:20:19 +0000 Date: Sat, 14 Jan 2017 06:20:16 +0900 Message-ID: From: Randy Bush To: Job Snijders In-Reply-To: References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: "Carlos M. Martinez" , sidrops@ietf.org, GMO Crops Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 21:20:25 -0000 > Adding grow@ietf.org for reality check. no comment :) when you choose to use a route server [0], you have out-sourced much of your policy and operational responsibilities. seems to me that whether this includes security decisions is a contract between the user and the route server. so i might tell the server to drop invalids. if i do not take that (configurable, i presume) option, having the server mark them seems helpful. randy -- 0 - i suspect none of job, carlos, or i do. so this is the experts telling other people what they should do. :) From nobody Fri Jan 13 14:07:00 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27FA129C87 for ; Fri, 13 Jan 2017 13:54: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lamehost-it.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Olh-fMbnswrO for ; Fri, 13 Jan 2017 13:54:57 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C1CC1295CD for ; Fri, 13 Jan 2017 13:54:56 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id y9so46532317uae.2 for ; Fri, 13 Jan 2017 13:54:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lamehost-it.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b1SQid4I+lhzk6h/iTsOap/gvAkTGfc81B7ukGxnIEE=; b=NWItIxVdHkCFfp2r+KPUqVQDItokdewUspt4B7V7S1NNOhs85spZyyaB1DSeBh4UJH aM+hezonf8+8U2pjAkC5N1mS2La5DvwlCSK+ZwEawOVWQ5s7tsOHHz6AGvaTvRcsXbtZ MEM98iDEXOWihj4r20NPZezVJLsPFts+6Do4TFdaxq5fZO5xIxLJ4LqgUX6afQo2GTid nQ4Hjo6QBIzDjEEqKlc2AZzAi19kGEEGJl1TNzc8mcNViFd/74nuUzkhWZiPeMShPVUG ZwHKWRfEfxEa/lhVSHwTDl3+MFyAQshKprkC2wrm+0cq60VU0snyMdTswoI3R2zmJuWY l97w== 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=b1SQid4I+lhzk6h/iTsOap/gvAkTGfc81B7ukGxnIEE=; b=LRKFNVYfSma+13n/urXGv3z7Nm42ase60J13cEjqb1diyDeEqcwruxUmBHfI2kEWG4 yvjzYwPVjrxWHD4lhvPGQEZ7XaKEcI7kk4rLlK0iNuj2rsw2KB9F9HnrkrhFn6WOcB7p KF6gz2HjhUrCSEkAlaOCA0blYSoVT1ZyEkVNJZkBOdEsGixO982jPqTWyh15qq2cbBux j3J48yGllfbGPCT6ernvjJzvwycfdt8zBvqqghpOvHogKtYOupB1ToIzYc71yLh4gBnP 1Di1zEar3q+pVOFMtpzc+C7DLFF6pu1a1exevD4UHSpBT4zStNazK1InbrvMoRx4Hfjx 7o0A== X-Gm-Message-State: AIkVDXLAG7+0hXv4xoOH1Wed3rvzxbgmjjEW4aFVS+wAPropPt/I4oDUFcN158rvXLfxb1G5cxYhiQ+w7UX7KA== X-Received: by 10.176.75.149 with SMTP id v21mr11616889uaf.94.1484344495841; Fri, 13 Jan 2017 13:54:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.214 with HTTP; Fri, 13 Jan 2017 13:54:55 -0800 (PST) X-Originating-IP: [95.252.41.226] In-Reply-To: References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> From: Marco Marzetti Date: Fri, 13 Jan 2017 22:54:55 +0100 Message-ID: To: Randy Bush Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Fri, 13 Jan 2017 14:06:59 -0800 Cc: sidrops@ietf.org, GMO Crops , Job Snijders Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 21:55:00 -0000 Every time one suggests a change related to the IXPs world we spend days arguing if it affects the neutrality and how. Do we really need that? Anyway, i can't see why IXPs can blackhole traffic (if the destination requests it), but cannot do the same with prefixes. After all if a prefix is invalid the owner requested it to be verified by the other parties. I suggest to default to drop and, if possible, to switch to announce with community if the peer requests it (for instance someone may want to collect invalid routes for analysis). On Fri, Jan 13, 2017 at 10:20 PM, Randy Bush wrote: >> Adding grow@ietf.org for reality check. > > no comment :) > > when you choose to use a route server [0], you have out-sourced much of > your policy and operational responsibilities. seems to me that whether > this includes security decisions is a contract between the user and the > route server. > > so i might tell the server to drop invalids. if i do not take that > (configurable, i presume) option, having the server mark them seems > helpful. > > randy > > -- > > 0 - i suspect none of job, carlos, or i do. so this is the experts > telling other people what they should do. :) > > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow -- Marco From nobody Fri Jan 13 14:13:42 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1903E129EAD; Fri, 13 Jan 2017 14:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 v-ocHTpWlOOV; Fri, 13 Jan 2017 14:13:34 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3899129E9D; Fri, 13 Jan 2017 14:05:10 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id v23so60069556qtb.0; Fri, 13 Jan 2017 14:05:10 -0800 (PST) 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=uAbm2AJHk85Qgjh6m1qGd+g7F7aPOTS65GiSBhdiSgw=; b=afHB5IBtmst99SZeEUWs6S+Kj57+cDihP3l0dDls5SL2MR1JSLKRcmZEaPF7jdsddw B1ViE7QlVMzMYku3YC7u8zqL0Wp5KyjEv45mx0AqELbbb6cCZHA/KKDbuLPEgtws+E9I 7uztRGsRJQDBiJtEe3kUwYvi85KwOYvGG8g+OVI5g6l4zSP+eIXJ+dBjqUVYyAvTmYRE 1qKLpMgtIVuzSepawN0GpBJvD0Gy33bqRiZJkOdPfEcsuFZ1fVFcRboLN4YatRIYjTQc JKb1cCqtH3eLDRVo6HXiWE2hTGXejy8EUXie98oIyN0hakWr0EMyqxXSLQBnQPxW5I5S lVMw== 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=uAbm2AJHk85Qgjh6m1qGd+g7F7aPOTS65GiSBhdiSgw=; b=aJNNZH4KNbKfocF1B/nchDGcA6wFnBnHEBwUA7zdm8TJRQnYspgH2CpuqNytJ9tvAi wbIEPrgCCRwxsUEFWIt83t9mpEi5RGTGGV6sQs3FY5W1yD5Zgc5IGC24wllWpCAes2eE pDbaYdFgCaWqIomJxn0R4Z+He4r64Xut71mDmH+mgeKN4NnrWXjx99kzNTJHuibvQ5Ys /KDXFQoAQBamqimLhPWcxK33VkjTn0qTlXmPHE8kqsRZhrnTlnrt1TzR2CYxCgzb6Gcw 3niMX/kHPjF034x68U/Ayooq8QkpQWSWVRODbHxn/uhmvZXuEbWI29BvjzNkBkvbvrgN RYkg== X-Gm-Message-State: AIkVDXIByQXhOQr8M8/TdRW8rt44GCCb/9oj7nR69QWZ/uX0BqpY554EwgPRtRHEi1cWJMst+OVt6ZjIUAgrLA== X-Received: by 10.200.47.100 with SMTP id k33mr18793560qta.241.1484345109931; Fri, 13 Jan 2017 14:05:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.23.228 with HTTP; Fri, 13 Jan 2017 14:05:09 -0800 (PST) In-Reply-To: References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> From: Christopher Morrow Date: Fri, 13 Jan 2017 17:05:09 -0500 Message-ID: To: Marco Marzetti Content-Type: multipart/alternative; boundary=001a11358744006b160546010700 Archived-At: Cc: Randy Bush , sidrops@ietf.org, GMO Crops , Job Snijders Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 22:13:37 -0000 --001a11358744006b160546010700 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 13, 2017 at 4:54 PM, Marco Marzetti wrote: > > Every time one suggests a change related to the IXPs world we spend > days arguing if it affects the neutrality and how. > Do we really need that? > > > Anyway, i can't see why IXPs can blackhole traffic (if the destination > requests it), but cannot do the same with prefixes. > After all if a prefix is invalid the owner requested it to be verified > by the other parties. > > I think part of job's point (and randy's in a way) is that you actually don't know if: 192.168.0.0/23 AS1 AS3 AS8 is valid, even if you see a ROA: 192.168.0.0/16 AS8 max-len /23 ... because there's nothing that keeps AS-ME from sending AS-JOB a route with AS8 prepended on the as-path. > I suggest to default to drop and, if possible, to switch to announce > with community if the peer requests it (for instance someone may want > to collect invalid routes for analysis). > > i think you are describing implementations that the IXP may choose... I don't know that this draft needs to specify that at all. -chris > On Fri, Jan 13, 2017 at 10:20 PM, Randy Bush wrote: > >> Adding grow@ietf.org for reality check. > > > > no comment :) > > > > when you choose to use a route server [0], you have out-sourced much of > > your policy and operational responsibilities. seems to me that whether > > this includes security decisions is a contract between the user and the > > route server. > > > > so i might tell the server to drop invalids. if i do not take that > > (configurable, i presume) option, having the server mark them seems > > helpful. > > > > randy > > > > -- > > > > 0 - i suspect none of job, carlos, or i do. so this is the experts > > telling other people what they should do. :) > > > > _______________________________________________ > > GROW mailing list > > GROW@ietf.org > > https://www.ietf.org/mailman/listinfo/grow > > > > -- > Marco > > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > --001a11358744006b160546010700 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jan 13, 2017 at 4:54 PM, Marco Marzetti <<= a href=3D"mailto:marco@lamehost.it" target=3D"_blank">marco@lamehost.it= > wrote:
<rant>
Every time one suggests a change related to the IXPs world we spend
days arguing if it affects the neutrality and how.
Do we really need that?
</rant>

Anyway, i can't see why IXPs can blackhole traffic (if the destination<= br> requests it), but cannot do the same with prefixes.
After all if a prefix is invalid the owner requested it to be verified
by the other parties.


I think part of job's point (and r= andy's in a way) is that you actually don't know if:
=C2=A0 192.168.0.0/23 AS1 AS3 AS8

=
is valid, even if you see a ROA:
192.168.0.0/16 AS8 max-len /23

... becau= se there's nothing that keeps AS-ME from sending AS-JOB a route with AS= 8 prepended on the as-path.
=C2=A0
I suggest to default to drop and, if possible, to switch to announce
with community if the peer requests it (for instance someone may want
to collect invalid routes for analysis).


i think you ar= e describing implementations that the IXP may choose... I don't know th= at this draft needs to specify that at all.
=C2=A0
-chr= is


On Fri, Jan 13, 2017 at 10:20 PM, Randy Bush <randy@psg.com> wrote:
>> Adding grow@ietf.org for real= ity check.
>
> no comment :)
>
> when you choose to use a route server [0], you have out-sourced much o= f
> your policy and operational responsibilities.=C2=A0 seems to me that w= hether
> this includes security decisions is a contract between the user and th= e
> route server.
>
> so i might tell the server to drop invalids.=C2=A0 if i do not take th= at
> (configurable, i presume) option, having the server mark them seems > helpful.
>
> randy
>
> --
>
> 0 - i suspect none of job, carlos, or i do.=C2=A0 so this is the exper= ts
>=C2=A0 =C2=A0 =C2=A0telling other people what they should do. :)
>
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow


--
Marco

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

--001a11358744006b160546010700-- From nobody Fri Jan 13 14:30:20 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01CAA129EC0 for ; Fri, 13 Jan 2017 14:22:41 -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, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lamehost-it.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlTfwRvjHG_L for ; Fri, 13 Jan 2017 14:22:38 -0800 (PST) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46278129EC3 for ; Fri, 13 Jan 2017 14:22:38 -0800 (PST) Received: by mail-vk0-x234.google.com with SMTP id 137so42543967vkl.0 for ; Fri, 13 Jan 2017 14:22:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lamehost-it.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NhAZYJvToDu+SCdkLkbdH9tY0VZo1rrvSer/UtRZNpw=; b=SeLccSylducEefuE8o8YDN35Q4aNop3LfqpccNGwdIAMXCjMn7rnzdb6q0yaCqYaw3 2pdZm4XY2DVMAAK489IRbEb/deR1XRc63SL7ttay3X+LkEiRjlGcM6mXiTiqsT7+wMSS O63UBCwEWCQ2NTMpx51GvhSs+UR+sggxqp4OKMfYh9hxMqFYyVjY+LOsW4fghEehi/aa +LScaRK4SzCUE0A0ghTw90OJ+L38b53g+nSdyZpCVApYz13d+VGOJtPRk4swv4QH3tLm UpZU/QwJz5MnD5u3j2koWmH9Svwwj3POIrni/Y5yMgWD/ZtXmLxj8/z/KSSQN3dgaMUy QysQ== 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=NhAZYJvToDu+SCdkLkbdH9tY0VZo1rrvSer/UtRZNpw=; b=aeteB9GB4upNklHjloMkhLXHnMsmltocA6GvoGNRqEH8l2yk99m7Tql2q1JOYfBalc oMGiKLZTTS1KxQAw/Y31DTLkBfhR5CYrbHE73JmmFnwv3WhUW8K8t2og4SJygo4suuYj s9QRz3L3i9UOiIlijp38a52lPPMSM2nGriw8kuGBuqDdZRMbXFHulEDxQRrq+cJOW/tH ct7YZmbLIplRELRHSfqiE+uuqtpq3E6wBCVU3ewlCv/HR83q9BG4ZW3tDM3WKU5odfRZ PjnzmfNoGu8FT6AjMFZIOkGi8mUPoULLfOkNjM97n+4cJM7ahZqKp4Gr7AIEqgGNVuCn CnnQ== X-Gm-Message-State: AIkVDXLyHCncTGza447F+cfMO2yFsb/ryghKUYD4ZyZYRhXjoK8BENIxpuHHlL7wD6NhfMdYqzWth0kQpCzu2Q== X-Received: by 10.31.183.144 with SMTP id h138mr9207460vkf.48.1484346157297; Fri, 13 Jan 2017 14:22:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.214 with HTTP; Fri, 13 Jan 2017 14:22:36 -0800 (PST) X-Originating-IP: [95.252.41.226] In-Reply-To: References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> From: Marco Marzetti Date: Fri, 13 Jan 2017 23:22:36 +0100 Message-ID: To: Christopher Morrow Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Fri, 13 Jan 2017 14:30:19 -0800 Cc: Randy Bush , sidrops@ietf.org, GMO Crops , Job Snijders Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 22:22:41 -0000 Christopher, I have to admit that i am not aware of the ongoing work on sidrops, so i may lack the needed background, but this draft only suggests to re-advertise all the prefixes. No matter what. Am i wrong? In that case i apologize. About the forged AS_PATHs: why is this important only when it comes to IXPs? Regards On Fri, Jan 13, 2017 at 11:05 PM, Christopher Morrow wrote: > > > On Fri, Jan 13, 2017 at 4:54 PM, Marco Marzetti wrote: >> >> >> Every time one suggests a change related to the IXPs world we spend >> days arguing if it affects the neutrality and how. >> Do we really need that? >> >> >> Anyway, i can't see why IXPs can blackhole traffic (if the destination >> requests it), but cannot do the same with prefixes. >> After all if a prefix is invalid the owner requested it to be verified >> by the other parties. >> > > I think part of job's point (and randy's in a way) is that you actually > don't know if: > 192.168.0.0/23 AS1 AS3 AS8 > > is valid, even if you see a ROA: > 192.168.0.0/16 AS8 max-len /23 > > ... because there's nothing that keeps AS-ME from sending AS-JOB a route > with AS8 prepended on the as-path. > >> >> I suggest to default to drop and, if possible, to switch to announce >> with community if the peer requests it (for instance someone may want >> to collect invalid routes for analysis). >> > > i think you are describing implementations that the IXP may choose... I > don't know that this draft needs to specify that at all. > > -chris > >> >> On Fri, Jan 13, 2017 at 10:20 PM, Randy Bush wrote: >> >> Adding grow@ietf.org for reality check. >> > >> > no comment :) >> > >> > when you choose to use a route server [0], you have out-sourced much of >> > your policy and operational responsibilities. seems to me that whether >> > this includes security decisions is a contract between the user and the >> > route server. >> > >> > so i might tell the server to drop invalids. if i do not take that >> > (configurable, i presume) option, having the server mark them seems >> > helpful. >> > >> > randy >> > >> > -- >> > >> > 0 - i suspect none of job, carlos, or i do. so this is the experts >> > telling other people what they should do. :) >> > >> > _______________________________________________ >> > GROW mailing list >> > GROW@ietf.org >> > https://www.ietf.org/mailman/listinfo/grow >> >> >> >> -- >> Marco >> >> _______________________________________________ >> GROW mailing list >> GROW@ietf.org >> https://www.ietf.org/mailman/listinfo/grow > > -- Marco From nobody Fri Jan 13 14:30:23 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22D1129ED2; Fri, 13 Jan 2017 14:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] 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 4w_gWSaOwBKQ; Fri, 13 Jan 2017 14:28:26 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 082F9129ED6; Fri, 13 Jan 2017 14:28:26 -0800 (PST) Received: from mbp-4.local ([IPv6:2601:647:4201:9e61:7174:5d8c:98d:5336]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v0DMSOeq079391 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 13 Jan 2017 22:28:24 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:9e61:7174:5d8c:98d:5336] claimed to be mbp-4.local To: Marco Marzetti , Randy Bush References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> From: joel jaeggli Message-ID: <20a8eefe-06e5-e1c9-04f8-3c4a66bc38f1@bogus.com> Date: Fri, 13 Jan 2017 14:28:23 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Thunderbird/50.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4q5N955THCtkdDxUqodjkswKHvw53QKC6" Archived-At: X-Mailman-Approved-At: Fri, 13 Jan 2017 14:30:19 -0800 Cc: sidrops@ietf.org, GMO Crops , Job Snijders Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 22:28:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4q5N955THCtkdDxUqodjkswKHvw53QKC6 Content-Type: multipart/mixed; boundary="eLdp6FHGOa8Im1k0xWVNpNSHAhLB0lN0C"; protected-headers="v1" From: joel jaeggli To: Marco Marzetti , Randy Bush Cc: sidrops@ietf.org, GMO Crops , Job Snijders Message-ID: <20a8eefe-06e5-e1c9-04f8-3c4a66bc38f1@bogus.com> Subject: Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> In-Reply-To: --eLdp6FHGOa8Im1k0xWVNpNSHAhLB0lN0C Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 1/13/17 1:54 PM, Marco Marzetti wrote: > > Every time one suggests a change related to the IXPs world we spend > days arguing if it affects the neutrality and how. > Do we really need that? > > > Anyway, i can't see why IXPs can blackhole traffic (if the destination > requests it), but cannot do the same with prefixes. > After all if a prefix is invalid the owner requested it to be verified > by the other parties. In general the consequences for IX operator that either allows it customers to attack each other over the exchange route-server or does so itself seems severe. Loss of confidence in the disposition of one's own routes seems like immediate grounds for depeering. If the routes remain afterwards with the short as path; the operator is engaged in prefix hijakcing. I personally find it dubious that I would choose to honor a third parties efforts at origin validation if I did not myself validate them but a signal from the exchange that it did validate the origin or that there an invalid roa floating around is at a minimum very interesting. > I suggest to default to drop and, if possible, to switch to announce > with community if the peer requests it (for instance someone may want > to collect invalid routes for analysis). > > > On Fri, Jan 13, 2017 at 10:20 PM, Randy Bush wrote: >>> Adding grow@ietf.org for reality check. >> no comment :) >> >> when you choose to use a route server [0], you have out-sourced much o= f >> your policy and operational responsibilities. seems to me that whethe= r >> this includes security decisions is a contract between the user and th= e >> route server. >> >> so i might tell the server to drop invalids. if i do not take that >> (configurable, i presume) option, having the server mark them seems >> helpful. >> >> randy >> >> -- >> >> 0 - i suspect none of job, carlos, or i do. so this is the experts >> telling other people what they should do. :) >> >> _______________________________________________ >> GROW mailing list >> GROW@ietf.org >> https://www.ietf.org/mailman/listinfo/grow > > --eLdp6FHGOa8Im1k0xWVNpNSHAhLB0lN0C-- --4q5N955THCtkdDxUqodjkswKHvw53QKC6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlh5VIgACgkQ8AA1q7Z/VrIh5wCfaC7kbFT4fuuJe+BHOSpvFCor yh8An2BHbCvUZYzaCUgYUu335RefRqql =1E91 -----END PGP SIGNATURE----- --4q5N955THCtkdDxUqodjkswKHvw53QKC6-- From nobody Fri Jan 13 14:52:09 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FAB129EF6; Fri, 13 Jan 2017 14:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxY3kgvTJDpa; Fri, 13 Jan 2017 14:52:01 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE5D71299A6; Fri, 13 Jan 2017 14:52:00 -0800 (PST) X-Envelope-To: grow@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v0DMpvHi095798 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jan 2017 22:51:57 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <58795A0B.6000009@foobar.org> Date: Fri, 13 Jan 2017 22:51:55 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.9 (Macintosh/20161202) MIME-Version: 1.0 To: job@ntt.net References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "Carlos M. Martinez" , sidrops@ietf.org, GMO Crops Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 22:52:03 -0000 job@ntt.net wrote: > Adding grow@ietf.org for reality check. We live in a post-truth world. On a more serious note, this draft is the wrong way around and this probably means it's not operationally useful in most cases. Let's say there's a route server R with clients A, B and C. Clients A and B announce a prefix, the intention being that the route server will propagate this to C. The route server will inject both prefixes into client C's Loc-RIB, and will then run the routing decision engine on that Loc-RIB. The best path will be computed and the result will be sent to C. If this draft is implemented the way it's stated, and client A injects a prefix which is has a valid rpki signature, and client B illegitimately injects the same prefix with an attribute set which ensures that it's the preferred prefix (doesn't matter whether it's signed or not), then the RDE will run and will unilaterally prefer the prefix from client B, ignoring the signed prefix from client A. Client C will receive the hijacked prefix. Not good. Or assume that client A injects a prefix which has an invalid rpki signature, and client B legitimately injects the same prefix with an attribute set which ensures that it's not the preferred prefix (again, it doesn't matter whether it's signed or not), the prefix from client A will be preferred in client C's Loc-RIB. If client C drops invalid prefixes, then the route server R has contributed to path hiding (see rfc7947). In both these cases, and some other easily identifiable situations, the draft as stated contributes to topologically surprising results which wouldn't necessarily be what any of clients A, B or particularly C might expect or want. There are two ways to fix this: 1. either this draft should mandate that add-path must be used for tx from the point of view of the route server. This is not operationally very useful because most clients and many route servers don't support ebgp add path, either due to policy or technical limitations. 2. by far the easiest and best way to solve this particular problem would be for the IXP operator to allow the IXP participants to specify how to handle rpki-signed prefixes for their route server configs. You would need two binary tickboxes in the IXP's provisioning system: drop or don't drop notfound, and drop or don't drop invalid. I would assume that there's no requirement for the same sort of tickbox for valid prefixes. If the IXP operator implemented this, then the Adj-RIB-In to Loc-RIB-out prefix filter would be able to make a decision about whether to accept or drop the RPKI notfound/invalid prefixes on a per client basis, which is what IXP route server client operators would want and expect. Obviously, this is a local IXP provisioning system issue, and it would be up to the IXP as to how to implement it, i.e. allow the customer to modify this themselves using a portal, or raise a ticket with the IXP support desk. Consequently, as this is not an problem which would be best solved by the IETF, I'd suggest it would be better for this draft not to progress further. Nick From nobody Fri Jan 13 14:54:01 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9961294CE; Fri, 13 Jan 2017 14:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUEH_bUSqOWj; Fri, 13 Jan 2017 14:53:53 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD99F129972; Fri, 13 Jan 2017 14:53:52 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id l7so61066724qtd.1; Fri, 13 Jan 2017 14:53:52 -0800 (PST) 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=ehIKHlk9GwSJ9U+EGAcDA/2/8S8fe/SrHCrfgsBrLAU=; b=kNCrryMEsGhyg4yTogbRQ9uiwPf6H0uKOetgeg1dAu//9k1G0v+aqCvnrDC/wB1Nm8 debEYB8pFfRP29y5nNDbkWZ/JoYNgi4EWufU3Fs4wTsKZPXLdTegYd+zAqZfP+mugenY kxl4wBpPWvrrjNJhujO40jCjschJt6EqVTmd2BppqwfSy13RsvJi0vPrup/X8Y49fsgL 0o4kSHMW3jsqgEmo0WmyDitxqumKc/FqYydDtvwAzKasifWdtxGTf7x6jdZYaSrVarzL O1lUt6H6c6jPbdAPSSef8EX68CKUlodXcxM1zDM1R41bHH5+YhvgV11azRQPJh8Buge3 OjSg== 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=ehIKHlk9GwSJ9U+EGAcDA/2/8S8fe/SrHCrfgsBrLAU=; b=frIRU4vgipqHMa8YN2evK3o3LhDFBZ1q8Zq4yfvDuCPoxQZYcPa6BIWWG8FfE8S/jy BL282oINpE5iQix4g9D8XKWtC3GhaKFVW+QnQ5SneuKnyHCEfJ/pKghoAN98CHTkxEQo o6IJHvUpyB4qekmkUfJx4Mfl92n1H6vz3FTHYspg4lljcXnN6QmgXIp+iPobz0PD8rfm gPAZKB4mQ8vMY7sWB3YNTMUqnLYwlmvPMXr6FL+fLD3wuUsr7qJClyfDMkAex+ZaESRU WKAPp4JOnsHf12vejzwGmyxOv0ZDVyWJKB9A3dxvSS5ftcracNt72OD9L6NaTfDDnodT 7jJg== X-Gm-Message-State: AIkVDXLXaO+cLiQ6ULdswtpVWrIE6fyrEX8EksoWwkHyA3p6+vUjlHOitU+c8bYbyWtJB2oJAYjoIhRIepLAIA== X-Received: by 10.237.52.199 with SMTP id x65mr19242570qtd.152.1484348031698; Fri, 13 Jan 2017 14:53:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.23.228 with HTTP; Fri, 13 Jan 2017 14:53:51 -0800 (PST) In-Reply-To: References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> From: Christopher Morrow Date: Fri, 13 Jan 2017 17:53:51 -0500 Message-ID: To: Marco Marzetti Content-Type: multipart/alternative; boundary=94eb2c0b68e8270e61054601b589 Archived-At: Cc: Randy Bush , sidrops@ietf.org, GMO Crops , Job Snijders Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 22:53:55 -0000 --94eb2c0b68e8270e61054601b589 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 13, 2017 at 5:22 PM, Marco Marzetti wrote: > Christopher, > > I have to admit that i am not aware of the ongoing work on sidrops, so > i may lack the needed background, but this draft only suggests to > re-advertise all the prefixes. No matter what. > Am i wrong? In that case i apologize. > it actually, I think , just says: "put a community that can be interpreted as valid/invalid/etc" I don't know that you'd want an RS keeping information from you, as a downstream of that RS, would you? I'd rather see the things so I can decide what's best for me. I think because this seems like a 'per network' or 'per ixp' concept, let's let the document not define the implementation, but just the capability. > > About the forged AS_PATHs: why is this important only when it comes to > IXPs? > > I don't think it is. > Regards > > > On Fri, Jan 13, 2017 at 11:05 PM, Christopher Morrow > wrote: > > > > > > On Fri, Jan 13, 2017 at 4:54 PM, Marco Marzetti > wrote: > >> > >> > >> Every time one suggests a change related to the IXPs world we spend > >> days arguing if it affects the neutrality and how. > >> Do we really need that? > >> > >> > >> Anyway, i can't see why IXPs can blackhole traffic (if the destination > >> requests it), but cannot do the same with prefixes. > >> After all if a prefix is invalid the owner requested it to be verified > >> by the other parties. > >> > > > > I think part of job's point (and randy's in a way) is that you actually > > don't know if: > > 192.168.0.0/23 AS1 AS3 AS8 > > > > is valid, even if you see a ROA: > > 192.168.0.0/16 AS8 max-len /23 > > > > ... because there's nothing that keeps AS-ME from sending AS-JOB a route > > with AS8 prepended on the as-path. > > > >> > >> I suggest to default to drop and, if possible, to switch to announce > >> with community if the peer requests it (for instance someone may want > >> to collect invalid routes for analysis). > >> > > > > i think you are describing implementations that the IXP may choose... I > > don't know that this draft needs to specify that at all. > > > > -chris > > > >> > >> On Fri, Jan 13, 2017 at 10:20 PM, Randy Bush wrote: > >> >> Adding grow@ietf.org for reality check. > >> > > >> > no comment :) > >> > > >> > when you choose to use a route server [0], you have out-sourced much > of > >> > your policy and operational responsibilities. seems to me that > whether > >> > this includes security decisions is a contract between the user and > the > >> > route server. > >> > > >> > so i might tell the server to drop invalids. if i do not take that > >> > (configurable, i presume) option, having the server mark them seems > >> > helpful. > >> > > >> > randy > >> > > >> > -- > >> > > >> > 0 - i suspect none of job, carlos, or i do. so this is the experts > >> > telling other people what they should do. :) > >> > > >> > _______________________________________________ > >> > GROW mailing list > >> > GROW@ietf.org > >> > https://www.ietf.org/mailman/listinfo/grow > >> > >> > >> > >> -- > >> Marco > >> > >> _______________________________________________ > >> GROW mailing list > >> GROW@ietf.org > >> https://www.ietf.org/mailman/listinfo/grow > > > > > > > > -- > Marco > --94eb2c0b68e8270e61054601b589 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jan 13, 2017 at 5:22 PM, Marco Marzetti <<= a href=3D"mailto:marco@lamehost.it" target=3D"_blank">marco@lamehost.it= > wrote:
Christopher,

I have to admit that i am not aware of the ongoing work on sidrops, so
i may lack the needed background, but this draft only suggests to
re-advertise all the prefixes. No matter what.
Am i wrong? In that case i apologize.

i= t actually, I think , just says: "put a community that can be interpre= ted as valid/invalid/etc"

I don't know th= at you'd want an RS keeping information from you, as a downstream of th= at RS, would you? I'd rather see the things so I can decide what's = best for me.

I think because this seems like a = 9;per network' or 'per ixp' concept, let's let the document= not define the implementation, but just the capability.
=C2=A0

About the forged AS_PATHs: why is this important only when it comes to IXPs= ?


I don't think it is.
=C2= =A0
Regards


On Fri, Jan 13, 2017 at 11:05 PM, Christopher Morrow
<christopher.morrow@gmai= l.com> wrote:
>
>
> On Fri, Jan 13, 2017 at 4:54 PM, Marco Marzetti <marco@lamehost.it> wrote:
>>
>> <rant>
>> Every time one suggests a change related to the IXPs world we spen= d
>> days arguing if it affects the neutrality and how.
>> Do we really need that?
>> </rant>
>>
>> Anyway, i can't see why IXPs can blackhole traffic (if the des= tination
>> requests it), but cannot do the same with prefixes.
>> After all if a prefix is invalid the owner requested it to be veri= fied
>> by the other parties.
>>
>
> I think part of job's point (and randy's in a way) is that you= actually
> don't know if:
>=C2=A0 =C2=A0192.168.0.0/23 AS1 AS3 AS8
>
> is valid, even if you see a ROA:
> 192.168.0.0/16 AS8 max-len /23
>
> ... because there's nothing that keeps AS-ME from sending AS-JOB a= route
> with AS8 prepended on the as-path.
>
>>
>> I suggest to default to drop and, if possible, to switch to announ= ce
>> with community if the peer requests it (for instance someone may w= ant
>> to collect invalid routes for analysis).
>>
>
> i think you are describing implementations that the IXP may choose... = I
> don't know that this draft needs to specify that at all.
>
> -chris
>
>>
>> On Fri, Jan 13, 2017 at 10:20 PM, Randy Bush <randy@psg.com> wrote:
>> >> Adding grow@ietf.org= for reality check.
>> >
>> > no comment :)
>> >
>> > when you choose to use a route server [0], you have out-sourc= ed much of
>> > your policy and operational responsibilities.=C2=A0 seems to = me that whether
>> > this includes security decisions is a contract between the us= er and the
>> > route server.
>> >
>> > so i might tell the server to drop invalids.=C2=A0 if i do no= t take that
>> > (configurable, i presume) option, having the server mark them= seems
>> > helpful.
>> >
>> > randy
>> >
>> > --
>> >
>> > 0 - i suspect none of job, carlos, or i do.=C2=A0 so this is = the experts
>> >=C2=A0 =C2=A0 =C2=A0telling other people what they should do. = :)
>> >
>> > _______________________________________________
>> > GROW mailing list
>> > GROW@ietf.org
>> > https://www.ietf.org/mailman/listinfo/g= row
>>
>>
>>
>> --
>> Marco
>>
>> _______________________________________________
>> GROW mailing list
>> GROW@ietf.org
>> https://www.ietf.org/mailman/listinfo/grow
>
>



--
Marco

--94eb2c0b68e8270e61054601b589-- From nobody Fri Jan 13 14:54:26 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB3E1294CE; Fri, 13 Jan 2017 14:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.134 X-Spam-Level: X-Spam-Status: No, score=-5.134 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_SOFTFAIL=0.665] 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 cuGBYB3cFm_W; Fri, 13 Jan 2017 14:54:05 -0800 (PST) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 2759C129EFB; Fri, 13 Jan 2017 14:54:05 -0800 (PST) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cSAjS-0002gl-Ua (job@us.ntt.net); Fri, 13 Jan 2017 22:54:04 +0000 Date: Fri, 13 Jan 2017 23:53:58 +0100 From: Job Snijders To: joel jaeggli Message-ID: <20170113225358.GE1055@Vurt.local> References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> <20a8eefe-06e5-e1c9-04f8-3c4a66bc38f1@bogus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20a8eefe-06e5-e1c9-04f8-3c4a66bc38f1@bogus.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Cc: Randy Bush , Marco Marzetti , sidrops@ietf.org, grow@ietf.org Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 22:54:12 -0000 On Fri, Jan 13, 2017 at 02:28:23PM -0800, joel jaeggli wrote: > On 1/13/17 1:54 PM, Marco Marzetti wrote: > > > > Every time one suggests a change related to the IXPs world we spend > > days arguing if it affects the neutrality and how. Do we really > > need that? > > > > > > Anyway, i can't see why IXPs can blackhole traffic (if the > > destination requests it), but cannot do the same with prefixes. > > After all if a prefix is invalid the owner requested it to be > > verified by the other parties. > > In general the consequences for IX operator that either allows it > customers to attack each other over the exchange route-server or does > so itself seems severe. Loss of confidence in the disposition of one's > own routes seems like immediate grounds for depeering. If the routes > remain afterwards with the short as path; the operator is engaged in > prefix hijakcing. > > I personally find it dubious that I would choose to honor a third > parties efforts at origin validation if I did not myself validate them > but a signal from the exchange that it did validate the origin or that > there an invalid roa floating around is at a minimum very interesting. I still don't understand how there can be a justification as to why it would be OK for route servers to redistribute poisonous routes and say "trust me its OK i added a community!", and we expect some different behaviour from 'the rest of the AS's'? In a case like this http://mailman.nanog.org/pipermail/nanog/2017-January/089823.html, assuming a ROA had existed for 206.125.164.0/22, what would've been the appropiate response from any AS involved (including route servers)? A) "its fine, i tagged it with a community and amplified the problem by propagating it to all my peers" B) "the buck stops with me, the invalid route will not be propagated by me" At the very least, i'd prefer the default mode should be a secure mode, not a 'scientifically interesting' mode. Kind regards, Job From nobody Fri Jan 13 19:04:55 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659831296EE; Fri, 13 Jan 2017 19:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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=-3.199, 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 2TT7WcuZu5C1; Fri, 13 Jan 2017 19:04:52 -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 AFD301296AA; Fri, 13 Jan 2017 19:04:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18942; q=dns/txt; s=iport; t=1484363091; x=1485572691; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8WQkhK9uiuUzxctariyGlQ3rJpqFKUJVD+LqA0GS5UQ=; b=evRa+qZqBj6XDkmv00CeErEmQL8Tb0hHsjgAd5+JNi/F5mPlsvX3/5wv 0NFKERehEyhwDBS52SkALzLQKXij/kTVtHeXPSbjbwGDiR9gsNrqGnjrV lKqccub9pQlqJarsvl8YeawldEq3/hd4jWMLfrpZMLjZoKyoWEUYTSwsQ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AtAQAJlHlY/4cNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9KAQEBAQEfX4EJB4NKigeSFYJVjSuFK4IMHwEKhXgCGoF+Pxg?= =?us-ascii?q?BAgEBAQEBAQFjKIRpAQEBBAEBIQofHwMLEAIBCBECAgEBAScDAgICIwILFAkIA?= =?us-ascii?q?gQBDQUIDIhqBQ6wXYIlhA+GBAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GRYRhhDA?= =?us-ascii?q?tH4JQgl4FiWCLSoYIAYZbinSQdoozEIghAQ8QOIFEFTqENRwYgUdzAYYqK4EDA?= =?us-ascii?q?YEMAQEB?= X-IronPort-AV: E=Sophos;i="5.33,225,1477958400"; d="scan'208,217";a="372597347" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jan 2017 03:04:50 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v0E34ooB025790 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 14 Jan 2017 03:04:50 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 13 Jan 2017 21:04:49 -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, 13 Jan 2017 21:04:49 -0600 From: "Jakob Heitz (jheitz)" To: Christopher Morrow , Marco Marzetti Thread-Topic: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt Thread-Index: AQHSbepMT1f5v8w6nUmuoOUog37t16E3A6+Q Date: Sat, 14 Jan 2017 03:04:48 +0000 Message-ID: References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.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: [128.107.151.60] Content-Type: multipart/alternative; boundary="_000_c49c2c2aa1fc4bb7938b4841532646beXCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Randy Bush , "sidrops@ietf.org" , GMO Crops , Job Snijders Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 03:04:54 -0000 --_000_c49c2c2aa1fc4bb7938b4841532646beXCHALN014ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCdzIHBhdGggdmFsaWRhdGlvbi4NCg0KQW55d2F5LCB0aGUgZGlhbWV0ZXIgb2YgdGhlIElu dGVybmV0IGlzIG9ubHkgYWJvdXQgNCB0byA1IEFTIGhvcHMuDQpUaWVyIDEncyBvbmx5IGNhcmUg YWJvdXQgdGhlIHJhZGl1cywgd2hpY2ggaXMgbW9zdGx5IDEsIDIgb3IgMyBBUyBob3BzLg0KDQpH aXZlbiBzdWNoIHNob3J0IEFTIHBhdGhzLCBSUEtJIGNhbiBwcm92aWRlIGEgZ29vZCBsZXZlbCBv ZiBwcm90ZWN0aW9uIGFscmVhZHkuDQpJZiB0aGUgYXR0YWNrZXIgb3JpZ2luYXRlcyBhIHJvdXRl IHByZXBlbmRlZCBieSB0aGUgbGVnaXRpbWF0ZSBBUywgdGhlbiBoaXMgQVMtUEFUSCB3aWxsDQpi ZSBsb25nZXIgdGhhbiB0aGF0IG9mIHRoZSBsZWdpdGltYXRlIHJvdXRlIGluIHRoZSBsYXJnZSBt YWpvcml0eSBvZiB0aGUgSW50ZXJuZXQuDQpCdXQgb25seSBpZiBlYWNoIEFTIHRoYXQgcmVnaXN0 ZXJzIGEgUk9BIGFkdmVydGlzZXMgZXZlcnkgcHJlZml4IG1hdGNoZWQgYnkgdGhlIFJPQS4NCklm IGl0IGRvZXMgbm90LCB0aGVuIGFub3RoZXIgQVMgY2FuIGVhc2lseSBzdGVhbCB0aGUgcHJlZml4 IGxpa2UgeW91IHNhaWQuDQoNCklmIHlvdSBuZWVkIHRvIHByb3RlY3QgYSBwcmVmaXggdGhhdCB5 b3UgZG9uJ3QgYWR2ZXJ0aXNlIHRoZW4gcHV0IEFTTiAwIGludG8gdGhlIFJPQSBmb3IgaXQuDQpU aGVuIG5vYm9keSBjYW4gYWR2ZXJ0aXNlIGl0Lg0KDQpUaGFua3MsDQpKYWtvYi4NCg0KRnJvbTog U2lkcm9wcyBbbWFpbHRvOnNpZHJvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENo cmlzdG9waGVyIE1vcnJvdw0KU2VudDogRnJpZGF5LCBKYW51YXJ5IDEzLCAyMDE3IDI6MDUgUE0N ClRvOiBNYXJjbyBNYXJ6ZXR0aSA8bWFyY29AbGFtZWhvc3QuaXQ+DQpDYzogUmFuZHkgQnVzaCA8 cmFuZHlAcHNnLmNvbT47IHNpZHJvcHNAaWV0Zi5vcmc7IEdNTyBDcm9wcyA8Z3Jvd0BpZXRmLm9y Zz47IEpvYiBTbmlqZGVycyA8am9iQG50dC5uZXQ+DQpTdWJqZWN0OiBSZTogW1NpZHJvcHNdIFtH Uk9XXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNpZHJvcHMtcm91dGUtc2VydmVyLXJwa2ktbGln aHQtMDAudHh0DQoNCg0KDQpPbiBGcmksIEphbiAxMywgMjAxNyBhdCA0OjU0IFBNLCBNYXJjbyBN YXJ6ZXR0aSA8bWFyY29AbGFtZWhvc3QuaXQ8bWFpbHRvOm1hcmNvQGxhbWVob3N0Lml0Pj4gd3Jv dGU6DQo8cmFudD4NCkV2ZXJ5IHRpbWUgb25lIHN1Z2dlc3RzIGEgY2hhbmdlIHJlbGF0ZWQgdG8g dGhlIElYUHMgd29ybGQgd2Ugc3BlbmQNCmRheXMgYXJndWluZyBpZiBpdCBhZmZlY3RzIHRoZSBu ZXV0cmFsaXR5IGFuZCBob3cuDQpEbyB3ZSByZWFsbHkgbmVlZCB0aGF0Pw0KPC9yYW50Pg0KDQpB bnl3YXksIGkgY2FuJ3Qgc2VlIHdoeSBJWFBzIGNhbiBibGFja2hvbGUgdHJhZmZpYyAoaWYgdGhl IGRlc3RpbmF0aW9uDQpyZXF1ZXN0cyBpdCksIGJ1dCBjYW5ub3QgZG8gdGhlIHNhbWUgd2l0aCBw cmVmaXhlcy4NCkFmdGVyIGFsbCBpZiBhIHByZWZpeCBpcyBpbnZhbGlkIHRoZSBvd25lciByZXF1 ZXN0ZWQgaXQgdG8gYmUgdmVyaWZpZWQNCmJ5IHRoZSBvdGhlciBwYXJ0aWVzLg0KDQpJIHRoaW5r IHBhcnQgb2Ygam9iJ3MgcG9pbnQgKGFuZCByYW5keSdzIGluIGEgd2F5KSBpcyB0aGF0IHlvdSBh Y3R1YWxseSBkb24ndCBrbm93IGlmOg0KICAxOTIuMTY4LjAuMC8yMzxodHRwOi8vMTkyLjE2OC4w LjAvMjM+IEFTMSBBUzMgQVM4DQoNCmlzIHZhbGlkLCBldmVuIGlmIHlvdSBzZWUgYSBST0E6DQox OTIuMTY4LjAuMC8xNjxodHRwOi8vMTkyLjE2OC4wLjAvMTY+IEFTOCBtYXgtbGVuIC8yMw0KDQou Li4gYmVjYXVzZSB0aGVyZSdzIG5vdGhpbmcgdGhhdCBrZWVwcyBBUy1NRSBmcm9tIHNlbmRpbmcg QVMtSk9CIGEgcm91dGUgd2l0aCBBUzggcHJlcGVuZGVkIG9uIHRoZSBhcy1wYXRoLg0KDQpJIHN1 Z2dlc3QgdG8gZGVmYXVsdCB0byBkcm9wIGFuZCwgaWYgcG9zc2libGUsIHRvIHN3aXRjaCB0byBh bm5vdW5jZQ0Kd2l0aCBjb21tdW5pdHkgaWYgdGhlIHBlZXIgcmVxdWVzdHMgaXQgKGZvciBpbnN0 YW5jZSBzb21lb25lIG1heSB3YW50DQp0byBjb2xsZWN0IGludmFsaWQgcm91dGVzIGZvciBhbmFs eXNpcykuDQoNCmkgdGhpbmsgeW91IGFyZSBkZXNjcmliaW5nIGltcGxlbWVudGF0aW9ucyB0aGF0 IHRoZSBJWFAgbWF5IGNob29zZS4uLiBJIGRvbid0IGtub3cgdGhhdCB0aGlzIGRyYWZ0IG5lZWRz IHRvIHNwZWNpZnkgdGhhdCBhdCBhbGwuDQoNCi1jaHJpcw0KDQoNCk9uIEZyaSwgSmFuIDEzLCAy MDE3IGF0IDEwOjIwIFBNLCBSYW5keSBCdXNoIDxyYW5keUBwc2cuY29tPG1haWx0bzpyYW5keUBw c2cuY29tPj4gd3JvdGU6DQo+PiBBZGRpbmcgZ3Jvd0BpZXRmLm9yZzxtYWlsdG86Z3Jvd0BpZXRm Lm9yZz4gZm9yIHJlYWxpdHkgY2hlY2suDQo+DQo+IG5vIGNvbW1lbnQgOikNCj4NCj4gd2hlbiB5 b3UgY2hvb3NlIHRvIHVzZSBhIHJvdXRlIHNlcnZlciBbMF0sIHlvdSBoYXZlIG91dC1zb3VyY2Vk IG11Y2ggb2YNCj4geW91ciBwb2xpY3kgYW5kIG9wZXJhdGlvbmFsIHJlc3BvbnNpYmlsaXRpZXMu ICBzZWVtcyB0byBtZSB0aGF0IHdoZXRoZXINCj4gdGhpcyBpbmNsdWRlcyBzZWN1cml0eSBkZWNp c2lvbnMgaXMgYSBjb250cmFjdCBiZXR3ZWVuIHRoZSB1c2VyIGFuZCB0aGUNCj4gcm91dGUgc2Vy dmVyLg0KPg0KPiBzbyBpIG1pZ2h0IHRlbGwgdGhlIHNlcnZlciB0byBkcm9wIGludmFsaWRzLiAg aWYgaSBkbyBub3QgdGFrZSB0aGF0DQo+IChjb25maWd1cmFibGUsIGkgcHJlc3VtZSkgb3B0aW9u LCBoYXZpbmcgdGhlIHNlcnZlciBtYXJrIHRoZW0gc2VlbXMNCj4gaGVscGZ1bC4NCj4NCj4gcmFu ZHkNCj4NCj4gLS0NCj4NCj4gMCAtIGkgc3VzcGVjdCBub25lIG9mIGpvYiwgY2FybG9zLCBvciBp IGRvLiAgc28gdGhpcyBpcyB0aGUgZXhwZXJ0cw0KPiAgICAgdGVsbGluZyBvdGhlciBwZW9wbGUg d2hhdCB0aGV5IHNob3VsZCBkby4gOikNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gR1JPVyBtYWlsaW5nIGxpc3QNCj4gR1JPV0BpZXRmLm9y ZzxtYWlsdG86R1JPV0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9ncm93DQoNCg0KDQotLQ0KTWFyY28NCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkdST1cgbWFpbGluZyBsaXN0DQpHUk9XQGlldGYub3Jn PG1haWx0bzpHUk9XQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9ncm93DQoNCg== --_000_c49c2c2aa1fc4bb7938b4841532646beXCHALN014ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJMdWNpZGEgQ29uc29s ZSI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNCA1IDQgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFt ZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjsNCgljb2xvcjojNzAzMEEw Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29y YXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01h aWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5UaGF0J3MgcGF0aCB2 YWxpZGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5B bnl3YXksIHRoZSBkaWFtZXRlciBvZiB0aGUgSW50ZXJuZXQgaXMgb25seSBhYm91dCA0IHRvIDUg QVMgaG9wcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5UaWVyIDEncyBvbmx5IGNhcmUgYWJvdXQgdGhlIHJh ZGl1cywgd2hpY2ggaXMgbW9zdGx5IDEsIDIgb3IgMyBBUyBob3BzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPkdpdmVuIHN1Y2ggc2hvcnQgQVMgcGF0aHMsIFJQS0kg Y2FuIHByb3ZpZGUgYSBnb29kIGxldmVsIG9mIHByb3RlY3Rpb24gYWxyZWFkeS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjoj NzAzMEEwIj5JZiB0aGUgYXR0YWNrZXIgb3JpZ2luYXRlcyBhIHJvdXRlIHByZXBlbmRlZCBieSB0 aGUgbGVnaXRpbWF0ZSBBUywgdGhlbiBoaXMgQVMtUEFUSCB3aWxsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+ YmUgbG9uZ2VyIHRoYW4gdGhhdCBvZiB0aGUgbGVnaXRpbWF0ZSByb3V0ZSBpbiB0aGUgbGFyZ2Ug bWFqb3JpdHkgb2YgdGhlIEludGVybmV0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPkJ1dCBvbmx5IGlmIGVh Y2ggQVMgdGhhdCByZWdpc3RlcnMgYSBST0EgYWR2ZXJ0aXNlcyBldmVyeSBwcmVmaXggbWF0Y2hl ZCBieSB0aGUgUk9BLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPklmIGl0IGRvZXMgbm90LCB0aGVuIGFub3Ro ZXIgQVMgY2FuIGVhc2lseSBzdGVhbCB0aGUgcHJlZml4IGxpa2UgeW91IHNhaWQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6 IzcwMzBBMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+SWYgeW91IG5lZWQgdG8gcHJvdGVjdCBh IHByZWZpeCB0aGF0IHlvdSBkb24ndCBhZHZlcnRpc2UgdGhlbiBwdXQgQVNOIDAgaW50byB0aGUg Uk9BIGZvciBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5UaGVuIG5vYm9keSBjYW4gYWR2ZXJ0aXNlIGl0 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNl cmlmO2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6IzcwMzBBMCI+VGhhbmtzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6IzcwMzBB MCI+SmFrb2IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiBTaWRyb3BzIFttYWlsdG86c2lkcm9wcy1ib3VuY2VzQGlldGYu b3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DaHJpc3RvcGhlciBNb3Jyb3c8YnI+DQo8Yj5TZW50 OjwvYj4gRnJpZGF5LCBKYW51YXJ5IDEzLCAyMDE3IDI6MDUgUE08YnI+DQo8Yj5Ubzo8L2I+IE1h cmNvIE1hcnpldHRpICZsdDttYXJjb0BsYW1laG9zdC5pdCZndDs8YnI+DQo8Yj5DYzo8L2I+IFJh bmR5IEJ1c2ggJmx0O3JhbmR5QHBzZy5jb20mZ3Q7OyBzaWRyb3BzQGlldGYub3JnOyBHTU8gQ3Jv cHMgJmx0O2dyb3dAaWV0Zi5vcmcmZ3Q7OyBKb2IgU25pamRlcnMgJmx0O2pvYkBudHQubmV0Jmd0 Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1NpZHJvcHNdIFtHUk9XXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLXNpZHJvcHMtcm91dGUtc2VydmVyLXJwa2ktbGlnaHQtMDAudHh0PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgSmFuIDEzLCAyMDE3IGF0 IDQ6NTQgUE0sIE1hcmNvIE1hcnpldHRpICZsdDs8YSBocmVmPSJtYWlsdG86bWFyY29AbGFtZWhv c3QuaXQiIHRhcmdldD0iX2JsYW5rIj5tYXJjb0BsYW1laG9zdC5pdDwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+Jmx0O3JhbnQmZ3Q7PGJyPg0KRXZlcnkgdGltZSBvbmUgc3Vn Z2VzdHMgYSBjaGFuZ2UgcmVsYXRlZCB0byB0aGUgSVhQcyB3b3JsZCB3ZSBzcGVuZDxicj4NCmRh eXMgYXJndWluZyBpZiBpdCBhZmZlY3RzIHRoZSBuZXV0cmFsaXR5IGFuZCBob3cuPGJyPg0KRG8g d2UgcmVhbGx5IG5lZWQgdGhhdD88YnI+DQombHQ7L3JhbnQmZ3Q7PGJyPg0KPGJyPg0KQW55d2F5 LCBpIGNhbid0IHNlZSB3aHkgSVhQcyBjYW4gYmxhY2tob2xlIHRyYWZmaWMgKGlmIHRoZSBkZXN0 aW5hdGlvbjxicj4NCnJlcXVlc3RzIGl0KSwgYnV0IGNhbm5vdCBkbyB0aGUgc2FtZSB3aXRoIHBy ZWZpeGVzLjxicj4NCkFmdGVyIGFsbCBpZiBhIHByZWZpeCBpcyBpbnZhbGlkIHRoZSBvd25lciBy ZXF1ZXN0ZWQgaXQgdG8gYmUgdmVyaWZpZWQ8YnI+DQpieSB0aGUgb3RoZXIgcGFydGllcy48bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgdGhpbmsgcGFydCBvZiBqb2IncyBwb2ludCAoYW5kIHJhbmR5J3MgaW4gYSB3YXkpIGlzIHRo YXQgeW91IGFjdHVhbGx5IGRvbid0IGtub3cgaWY6PGJyPg0KJm5ic3A7IDxhIGhyZWY9Imh0dHA6 Ly8xOTIuMTY4LjAuMC8yMyI+MTkyLjE2OC4wLjAvMjM8L2E+IEFTMSBBUzMgQVM4PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmlzIHZhbGlkLCBl dmVuIGlmIHlvdSBzZWUgYSBST0E6PGJyPg0KPGEgaHJlZj0iaHR0cDovLzE5Mi4xNjguMC4wLzE2 Ij4xOTIuMTY4LjAuMC8xNjwvYT4gQVM4IG1heC1sZW4gLzIzPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi4uLiBiZWNhdXNlIHRoZXJlJ3Mgbm90 aGluZyB0aGF0IGtlZXBzIEFTLU1FIGZyb20gc2VuZGluZyBBUy1KT0IgYSByb3V0ZSB3aXRoIEFT OCBwcmVwZW5kZWQgb24gdGhlIGFzLXBhdGguPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+SSBzdWdnZXN0IHRvIGRlZmF1bHQgdG8gZHJvcCBhbmQsIGlmIHBvc3NpYmxlLCB0byBzd2l0 Y2ggdG8gYW5ub3VuY2U8YnI+DQp3aXRoIGNvbW11bml0eSBpZiB0aGUgcGVlciByZXF1ZXN0cyBp dCAoZm9yIGluc3RhbmNlIHNvbWVvbmUgbWF5IHdhbnQ8YnI+DQp0byBjb2xsZWN0IGludmFsaWQg cm91dGVzIGZvciBhbmFseXNpcykuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pIHRoaW5rIHlvdSBhcmUgZGVzY3JpYmluZyBpbXBs ZW1lbnRhdGlvbnMgdGhhdCB0aGUgSVhQIG1heSBjaG9vc2UuLi4gSSBkb24ndCBrbm93IHRoYXQg dGhpcyBkcmFmdCBuZWVkcyB0byBzcGVjaWZ5IHRoYXQgYXQgYWxsLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tY2hyaXM8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KT24g RnJpLCBKYW4gMTMsIDIwMTcgYXQgMTA6MjAgUE0sIFJhbmR5IEJ1c2ggJmx0OzxhIGhyZWY9Im1h aWx0bzpyYW5keUBwc2cuY29tIj5yYW5keUBwc2cuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0 OyZndDsgQWRkaW5nIDxhIGhyZWY9Im1haWx0bzpncm93QGlldGYub3JnIj5ncm93QGlldGYub3Jn PC9hPiBmb3IgcmVhbGl0eSBjaGVjay48YnI+DQomZ3Q7PGJyPg0KJmd0OyBubyBjb21tZW50IDop PGJyPg0KJmd0Ozxicj4NCiZndDsgd2hlbiB5b3UgY2hvb3NlIHRvIHVzZSBhIHJvdXRlIHNlcnZl ciBbMF0sIHlvdSBoYXZlIG91dC1zb3VyY2VkIG11Y2ggb2Y8YnI+DQomZ3Q7IHlvdXIgcG9saWN5 IGFuZCBvcGVyYXRpb25hbCByZXNwb25zaWJpbGl0aWVzLiZuYnNwOyBzZWVtcyB0byBtZSB0aGF0 IHdoZXRoZXI8YnI+DQomZ3Q7IHRoaXMgaW5jbHVkZXMgc2VjdXJpdHkgZGVjaXNpb25zIGlzIGEg Y29udHJhY3QgYmV0d2VlbiB0aGUgdXNlciBhbmQgdGhlPGJyPg0KJmd0OyByb3V0ZSBzZXJ2ZXIu PGJyPg0KJmd0Ozxicj4NCiZndDsgc28gaSBtaWdodCB0ZWxsIHRoZSBzZXJ2ZXIgdG8gZHJvcCBp bnZhbGlkcy4mbmJzcDsgaWYgaSBkbyBub3QgdGFrZSB0aGF0PGJyPg0KJmd0OyAoY29uZmlndXJh YmxlLCBpIHByZXN1bWUpIG9wdGlvbiwgaGF2aW5nIHRoZSBzZXJ2ZXIgbWFyayB0aGVtIHNlZW1z PGJyPg0KJmd0OyBoZWxwZnVsLjxicj4NCiZndDs8YnI+DQomZ3Q7IHJhbmR5PGJyPg0KJmd0Ozxi cj4NCiZndDsgLS08YnI+DQomZ3Q7PGJyPg0KJmd0OyAwIC0gaSBzdXNwZWN0IG5vbmUgb2Ygam9i LCBjYXJsb3MsIG9yIGkgZG8uJm5ic3A7IHNvIHRoaXMgaXMgdGhlIGV4cGVydHM8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDt0ZWxsaW5nIG90aGVyIHBlb3BsZSB3aGF0IHRoZXkgc2hvdWxk IGRvLiA6KTxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBHUk9XIG1haWxpbmcgbGlzdDxicj4NCiZndDsg PGEgaHJlZj0ibWFpbHRvOkdST1dAaWV0Zi5vcmciPkdST1dAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0 OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dyb3ciIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dyb3c8 L2E+PGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxicj4NCjxicj4NCjxz cGFuIGNsYXNzPSJob2VuemIiPi0tPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPk1h cmNvPC9zcGFuPjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNz PSJob2VuemIiPkdST1cgbWFpbGluZyBsaXN0PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJob2Vu emIiPjxhIGhyZWY9Im1haWx0bzpHUk9XQGlldGYub3JnIj5HUk9XQGlldGYub3JnPC9hPjwvc3Bh bj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2dyb3ciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dyb3c8L2E+PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_c49c2c2aa1fc4bb7938b4841532646beXCHALN014ciscocom_-- From nobody Fri Jan 13 19:08:14 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0451296F5; Fri, 13 Jan 2017 19:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 4dF1NUW2UWgP; Fri, 13 Jan 2017 19:08:08 -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 9EA421296EE; Fri, 13 Jan 2017 19:08:08 -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 1cSEhJ-0002T3-8P; Sat, 14 Jan 2017 03:08:05 +0000 Date: Sat, 14 Jan 2017 12:08:02 +0900 Message-ID: From: Randy Bush To: "Jakob Heitz (jheitz)" In-Reply-To: References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: Marco Marzetti , Christopher Morrow , GMO Crops , "sidrops@ietf.org" , Job Snijders Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 03:08:10 -0000 > If you need to protect a prefix that you don't advertise then put ASN > 0 into the ROA for it. Then nobody can advertise it. not exactly. someone (with credentials) can issue a roa for the same prefix to as 42, and it will validate the origination. there can be many roas which match a single announcement; all it takes is one to be valid. randy From nobody Fri Jan 13 19:15:55 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0B6129428; Fri, 13 Jan 2017 19:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, 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 6uri9qeEMWRq; Fri, 13 Jan 2017 19:15:53 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6A5A1293F9; Fri, 13 Jan 2017 19:15:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1009; q=dns/txt; s=iport; t=1484363752; x=1485573352; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5IQqTXOrQUtBKlO9qRmuJX/T2/g9ZJj3dKmJlGn2tus=; b=AisL3vZRq8e1dXjIQb+pyzqoGtMft6Dne4niSu3Jm4Rayw6EGv4v5JF0 Cg8Zg6r0Bj+3lbcZg5cVW+UV8bal+6iumaHfwv1sbxpQpj2f0xA/KSHUi kSKm1QtHoc9NtKKvN0KnrRRWd9rhQnGUoLV/8PQRb/7Gqu7PjduT5MZPF M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DcAgCQl3lY/5RdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzkBAQEBAR+BaAefZogDixmEG4YiAoIYQhUBAgEBAQEBAQFjKIR?= =?us-ascii?q?pAQEBBDo/DAQCAQgRBAEBHwkHIREUCQgCBA4FCIhgAxizCoc6DYJMAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHYZFhGGCToFeBIV6BZp6OAGNVYN6kHaKEYhTATUigUQ?= =?us-ascii?q?VhSOBR3OGKyuBAwGBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,225,1477958400"; d="scan'208";a="192915868" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jan 2017 03:15:51 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v0E3Fp1B028977 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 14 Jan 2017 03:15:51 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 13 Jan 2017 21:15:49 -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, 13 Jan 2017 21:15:50 -0600 From: "Jakob Heitz (jheitz)" To: Randy Bush Thread-Topic: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt Thread-Index: AQHSbepMT1f5v8w6nUmuoOUog37t16E3A6+QgACr5gD//5znMA== Date: Sat, 14 Jan 2017 03:15:49 +0000 Message-ID: <46a12ee1e96a4d6382898c9be31ea6a2@XCH-ALN-014.cisco.com> References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.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: [128.107.151.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Marco Marzetti , Christopher Morrow , GMO Crops , "sidrops@ietf.org" , Job Snijders Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 03:15:54 -0000 With credentials. Surely if you own the prefix, then you have power over those with credentia= ls and the ability to remove all ROAs for it that point to as 42. Thanks, Jakob. > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Friday, January 13, 2017 7:08 PM > To: Jakob Heitz (jheitz) > Cc: Christopher Morrow ; Marco Marzetti ; sidrops@ietf.org; GMO > Crops ; Job Snijders > Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server= -rpki-light-00.txt >=20 > > If you need to protect a prefix that you don't advertise then put ASN > > 0 into the ROA for it. Then nobody can advertise it. >=20 > not exactly. someone (with credentials) can issue a roa for the same > prefix to as 42, and it will validate the origination. there can be > many roas which match a single announcement; all it takes is one to be > valid. >=20 > randy From nobody Sat Jan 14 02:23:05 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92D11295B1; Sat, 14 Jan 2017 02:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, 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 JN84PW774Ks6; Sat, 14 Jan 2017 02:22:57 -0800 (PST) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCA9A1299DC; Sat, 14 Jan 2017 02:22:57 -0800 (PST) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1cSLU3-000vej-39>; Sat, 14 Jan 2017 11:22:51 +0100 Received: from x5ce7e3a4.dyn.telefonica.de ([92.231.227.164] helo=mw-PC.fritz.box) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1:AES256-SHA:256) (envelope-from ) id <1cSLU2-0005BU-P7>; Sat, 14 Jan 2017 11:22:51 +0100 Date: Sat, 14 Jan 2017 11:22:14 +0100 From: Matthias Waehlisch To: Nick Hilliard In-Reply-To: <58795A0B.6000009@foobar.org> Message-ID: References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> <58795A0B.6000009@foobar.org> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) X-X-Sender: waehl@mail.zedat.fu-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Originating-IP: 92.231.227.164 Archived-At: Cc: "Carlos M. Martinez" , sidrops@ietf.org, GMO Crops , job@ntt.net Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 10:23:00 -0000 Hi Nick, interesting. You are arguing who is doing the best path selection for a specific prefix. I think there are two cases: (1) RS client peers only with route server, (2) RS client peers additionally with other BGP speakers that don't peer with the RS. In case (1) (and assuming that the RS selects the best path on behalf of the client), the IXP provisioning system needs to provide all knobs to implement potential policies -- as you mentioned below. Should be s side note. In case (2), route-server-rpki-light would be still helpful. Maybe this should be clarified in route-server-rpki-light. Cheers matthias On Fri, 13 Jan 2017, Nick Hilliard wrote: > job@ntt.net wrote: > > Adding grow@ietf.org for reality check. > > We live in a post-truth world. > > On a more serious note, this draft is the wrong way around and this > probably means it's not operationally useful in most cases. > > Let's say there's a route server R with clients A, B and C. Clients A > and B announce a prefix, the intention being that the route server will > propagate this to C. The route server will inject both prefixes into > client C's Loc-RIB, and will then run the routing decision engine on > that Loc-RIB. The best path will be computed and the result will be > sent to C. > > If this draft is implemented the way it's stated, and client A injects a > prefix which is has a valid rpki signature, and client B illegitimately > injects the same prefix with an attribute set which ensures that it's > the preferred prefix (doesn't matter whether it's signed or not), then > the RDE will run and will unilaterally prefer the prefix from client B, > ignoring the signed prefix from client A. Client C will receive the > hijacked prefix. Not good. > > Or assume that client A injects a prefix which has an invalid rpki > signature, and client B legitimately injects the same prefix with an > attribute set which ensures that it's not the preferred prefix (again, > it doesn't matter whether it's signed or not), the prefix from client A > will be preferred in client C's Loc-RIB. If client C drops invalid > prefixes, then the route server R has contributed to path hiding (see > rfc7947). > > In both these cases, and some other easily identifiable situations, the > draft as stated contributes to topologically surprising results which > wouldn't necessarily be what any of clients A, B or particularly C might > expect or want. > > There are two ways to fix this: > > 1. either this draft should mandate that add-path must be used for tx > from the point of view of the route server. This is not operationally > very useful because most clients and many route servers don't support > ebgp add path, either due to policy or technical limitations. > > 2. by far the easiest and best way to solve this particular problem > would be for the IXP operator to allow the IXP participants to specify > how to handle rpki-signed prefixes for their route server configs. You > would need two binary tickboxes in the IXP's provisioning system: drop > or don't drop notfound, and drop or don't drop invalid. I would assume > that there's no requirement for the same sort of tickbox for valid > prefixes. If the IXP operator implemented this, then the Adj-RIB-In to > Loc-RIB-out prefix filter would be able to make a decision about whether > to accept or drop the RPKI notfound/invalid prefixes on a per client > basis, which is what IXP route server client operators would want and > expect. > > Obviously, this is a local IXP provisioning system issue, and it would > be up to the IXP as to how to implement it, i.e. allow the customer to > modify this themselves using a portal, or raise a ticket with the IXP > support desk. Consequently, as this is not an problem which would be > best solved by the IETF, I'd suggest it would be better for this draft > not to progress further. > > Nick > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl From nobody Sat Jan 14 02:42:40 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDBF41299E2; Sat, 14 Jan 2017 02:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqU8lOt4dCiK; Sat, 14 Jan 2017 02:42:32 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98EB31299E0; Sat, 14 Jan 2017 02:42:32 -0800 (PST) X-Envelope-To: grow@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v0EAgTtU017239 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jan 2017 10:42:29 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <587A0094.6030302@foobar.org> Date: Sat, 14 Jan 2017 10:42:28 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.9 (Macintosh/20161202) MIME-Version: 1.0 To: Christopher Morrow References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Marco Marzetti , sidrops@ietf.org, GMO Crops , Job Snijders Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 10:42:35 -0000 Christopher Morrow wrote: > I don't know that you'd want an RS keeping information from you, as a > downstream of that RS, would you? I'd rather see the things so I can > decide what's best for me. Chris, this is not how route servers work. What you're suggesting will only work if the route server implements add-path tx, allowing the client to receive all the candidate prefixes for a particular route, not just the calculated best path. In practice, what happens is that the route server calculates the best path on a per-client basis and sends the best path to the client rather than all the candidate paths. In order to do this, the route server needs to be configured so that the BGP decision process knows whether to take the rpki-invalid or rpki-unknown prefixes into account when calculating the best path for each client's Loc-RIB. This configuration needs to be done on the route server in advance, and on a per-client basis, and can only be handled properly by config flags in the IXP provisioning system. > I think because this seems like a 'per network' or 'per ixp' concept, > let's let the document not define the implementation, but just the > capability. This is the wrong way to solve this particular problem. It's a local IXP provisioning system flag, not an ietf issue. Nick From nobody Sat Jan 14 02:56:28 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFDF1299C1; Sat, 14 Jan 2017 02:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5s55Km0gR8p; Sat, 14 Jan 2017 02:56:22 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D916C1294CD; Sat, 14 Jan 2017 02:56:21 -0800 (PST) X-Envelope-To: grow@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v0EAuGNP017663 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jan 2017 10:56:16 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <587A03CF.3010001@foobar.org> Date: Sat, 14 Jan 2017 10:56:15 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.9 (Macintosh/20161202) MIME-Version: 1.0 To: Matthias Waehlisch References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> <58795A0B.6000009@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "Carlos M. Martinez" , sidrops@ietf.org, GMO Crops , job@ntt.net Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 10:56:24 -0000 Matthias Waehlisch wrote: > I think there are two cases: (1) RS client peers only with route > server, (2) RS client peers additionally with other BGP speakers that > don't peer with the RS. > > In case (1) (and assuming that the RS selects the best path on behalf > of the client), the IXP provisioning system needs to provide all knobs > to implement potential policies -- as you mentioned below. Should be s > side note. > > In case (2), route-server-rpki-light would be still helpful. Case (1) is not an ietf problem. Case (2) is already documented in draft-ietf-sidr-origin-validation-signaling, which proposes a generic BGP signaling mechanism, i.e. nothing particularly to do with route servers. In fact, if the -sidr- draft progresses, it should probably be mentioned somewhere that the proposed mechanism is likely to cause unexpected behaviour on route servers unless add-path tx is enabled on the route server. Nick From nobody Sat Jan 14 07:06:27 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C9012957C; Sat, 14 Jan 2017 07:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XkBOMg5hCeE; Sat, 14 Jan 2017 07:06:23 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE68812007C; Sat, 14 Jan 2017 07:06:22 -0800 (PST) X-Envelope-To: grow@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v0EF6HFd025708 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jan 2017 15:06:18 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <587A3E68.9040805@foobar.org> Date: Sat, 14 Jan 2017 15:06:16 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.9 (Macintosh/20161202) MIME-Version: 1.0 To: Marco Marzetti References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Christopher Morrow , GMO Crops , sidrops@ietf.org, Job Snijders Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 15:06:25 -0000 Marco Marzetti wrote: > Why RPKI can't be part of that? tl;dr: route servers and rpki are an uncomfortable fit. rpki can be part of that, but it's problematic because the route server is running the routing decision engine on the part of the client. RPKI is a relatively fine-grained tool in the list of things that are taken into account for the best path calculation, which means that there is a genuine difficulty in providing enough fine-grained levers so that the route server can handle this in a way that works well for clients. As others have pointed out, the control mechanisms that rpki allows are much easier to handle on bilateral bgp sessions than multilateral. These problems mostly disappear if the route server and client use add-path, because that shifts the burden of handling the policy application fully to the client. Where add-path is used, there is no requirement to mark routes with communities firstly because no routing policy action has been taken by the route server and secondly because the client can check the ROA themselves. The usual caveats about add-path apply. Stepping back a bit, most organisations who use route servers are sufficiently small that they don't need anything more than highly simplistic exterior routing policies, where almost everything is handled by the default bgp decision process documented in rfc4271, and final tweaks are handled by applying a single med or localpref for all peers or all transits or whatever. This is the category of ASNs that route servers work best for. Once an organisation grows beyond a certain size, it's quite usual to move away from using route servers - and at a later stage still, to move away from using IXPs in favour of PNIs. If an organisation's routing policies are more complicated than most, then route servers are generally unsuitable anyway. RPKI will reduce that boundary of suitability, but not by much. I'd hazard a guess that if an IXP were to provide a primitive facility in their provisioning system to allow clients to specify whether they wanted rpki-invalid or rpki-notfound dropped or used in the decision engine, that would satisfy most route server client organisations' policy requirements. Obviously this is not going to work for all organisations, but adding in more fine-grained controls runs into diminishing returns very quickly indeed, as has been implicitly noted in the ixp industry by the scarcity of generally accepted policy controls outside the usual "redistribute or don't redistribute my prefixes to ASN X" community tags. If AS path validation ever happens, then this probably not work with route servers at all, but that's a different thing, outside the scope of this conversation. Nick From nobody Sat Jan 14 07:30:58 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61D412A028; Sat, 14 Jan 2017 07:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, 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 85h3sDbhyekq; Sat, 14 Jan 2017 07:30:48 -0800 (PST) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 102D312A01F; Sat, 14 Jan 2017 07:30:48 -0800 (PST) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1cSQI1-0023pl-Tp>; Sat, 14 Jan 2017 16:30:45 +0100 Received: from x5ce7e3a4.dyn.telefonica.de ([92.231.227.164] helo=mw-PC.fritz.box) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1:AES256-SHA:256) (envelope-from ) id <1cSQI1-000Sas-K4>; Sat, 14 Jan 2017 16:30:45 +0100 Date: Sat, 14 Jan 2017 16:30:09 +0100 From: Matthias Waehlisch To: Nick Hilliard In-Reply-To: <587A03CF.3010001@foobar.org> Message-ID: References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> <58795A0B.6000009@foobar.org> <587A03CF.3010001@foobar.org> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) X-X-Sender: waehl@mail.zedat.fu-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Originating-IP: 92.231.227.164 Archived-At: Cc: "Carlos M. Martinez" , sidrops@ietf.org, GMO Crops , job@ntt.net Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 15:30:50 -0000 On Sat, 14 Jan 2017, Nick Hilliard wrote: > Matthias Waehlisch wrote: > > I think there are two cases: (1) RS client peers only with route > > server, (2) RS client peers additionally with other BGP speakers that > > don't peer with the RS. > > > > In case (1) (and assuming that the RS selects the best path on behalf > > of the client), the IXP provisioning system needs to provide all knobs > > to implement potential policies -- as you mentioned below. Should be s > > side note. > > > > In case (2), route-server-rpki-light would be still helpful. > > Case (1) is not an ietf problem. > > Case (2) is already documented in > draft-ietf-sidr-origin-validation-signaling, which proposes a generic > BGP signaling mechanism, i.e. nothing particularly to do with route > servers. In fact, if the -sidr- draft progresses, it should probably be > mentioned somewhere that the proposed mechanism is likely to cause > unexpected behaviour on route servers unless add-path tx is enabled on > the route server. > the current discussion makes clear that documentation of origin-validation-signaling in IXP context is needed, either in sidr-origin-validation-signaling or in a separate document such as route-server-rpki-light. Personally, I tend to a separate doc (informational or best practice). Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl From nobody Sat Jan 14 09:19:26 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B553129C5B; Sat, 14 Jan 2017 09:19:18 -0800 (PST) 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, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OCIKXchH688; Sat, 14 Jan 2017 09:19:09 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F7AA129C5F; Sat, 14 Jan 2017 09:19:02 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id s140so83933113qke.0; Sat, 14 Jan 2017 09:19:02 -0800 (PST) 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=ATuLprx0pGRMGno84Nu4z6O616h+gHM/YnYGsuXHGjM=; b=aVuARJkWto5dW0sCiFYWCyVddPItvWIy/yaR5EnoHm84IRcpBv3i0sApgYTrsCIa1K gHx3uGK+i7y0iMHaHjluafHLX3oxpg4AgDgBUspKanlf+P1NwvyBKg/GU2E3o2xHr+Dk wIuPVcYBRqA4n1EhXpZyRSZCCepYnoNIDuO0FfWwiugRmKLNlg0x+6Fd6UrZ7Hc+FOpb Zh5ijP2ReLcrSBDDlGTwh2HgOR1CFqFVgBSB2Mc6ZuqVNQhiiD1LiC9TGPkpJh7GHdpT Uw28kcEuZWhcLTRmLhrqUWCswvJBPxd0n+O/SamuiwC8JuRKIxM6EbgpXBH9wf7kt8Fp LQ8A== 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=ATuLprx0pGRMGno84Nu4z6O616h+gHM/YnYGsuXHGjM=; b=Z/ltaCxYMWdvZ+HUnudIeGlQvz4WzHqtiOieadBnH+FnI9bgbuZs0DtQBKWsmIV2kI lFrEoVnnraRHBKm6LdiHjGjX82w1kWV3h+yXNAVCueXV7N4mnEn8MCFm1+6qFqlB+i5o c85vzQnOutkgzwyF/7N0X059s0TP0xBXY4T11vQEI0bRWMN1XbtKgm+bucBgHC33McvL 6xeSo+QSrvKQR3047ezzGZ12HbhhgyCr05vqVQ+/5goi9pZUk0OyeE0vYyJsv/cZ0ToH o+9B2Id9E9fkIycx9RpgDDaPeCLZKIVExdApMqQNVa4uEmN1mWrO/jppoeTjO8AInrwZ +5dg== X-Gm-Message-State: AIkVDXLWFqVdR9HNU7J0hG63025GSqXKkNlsHZY0vw53I4FYX3eLAspVCCtqIZM9l8im/ylhWSsL8Pop28f3jg== X-Received: by 10.55.7.2 with SMTP id 2mr27058170qkh.228.1484414341654; Sat, 14 Jan 2017 09:19:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.23.228 with HTTP; Sat, 14 Jan 2017 09:19:00 -0800 (PST) In-Reply-To: References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> From: Christopher Morrow Date: Sat, 14 Jan 2017 12:19:00 -0500 Message-ID: To: Marco Marzetti Content-Type: multipart/alternative; boundary=001a114c877c88b08705461125a4 Archived-At: Cc: Randy Bush , sidrops@ietf.org, GMO Crops , Job Snijders Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 17:19:18 -0000 --001a114c877c88b08705461125a4 Content-Type: text/plain; charset=UTF-8 backup up a tad... somehow *(probably late-work-night clicking) I added joel/marco to the 'reject mail' list :( (note that both are now subscribed to the list.. if you do not want that you should go unsubscribe) I'm sorry there were 4 messages, copied here, which didn't make it to sidrops@ ---------------- msg 1 -------------------- On 1/13/17 2:53 PM, Job Snijders wrote: > On Fri, Jan 13, 2017 at 02:28:23PM -0800, joel jaeggli wrote: >> On 1/13/17 1:54 PM, Marco Marzetti wrote: >>> >>> Every time one suggests a change related to the IXPs world we spend >>> days arguing if it affects the neutrality and how. Do we really >>> need that? >>> >>> >>> Anyway, i can't see why IXPs can blackhole traffic (if the >>> destination requests it), but cannot do the same with prefixes. >>> After all if a prefix is invalid the owner requested it to be >>> verified by the other parties. >> In general the consequences for IX operator that either allows it >> customers to attack each other over the exchange route-server or does >> so itself seems severe. Loss of confidence in the disposition of one's >> own routes seems like immediate grounds for depeering. If the routes >> remain afterwards with the short as path; the operator is engaged in >> prefix hijakcing. >> >> I personally find it dubious that I would choose to honor a third >> parties efforts at origin validation if I did not myself validate them >> but a signal from the exchange that it did validate the origin or that >> there an invalid roa floating around is at a minimum very interesting. > I still don't understand how there can be a justification as to why it > would be OK for route servers to redistribute poisonous routes and say > "trust me its OK i added a community!", and we expect some different > behaviour from 'the rest of the AS's'? > > In a case like this http://mailman.nanog.org/pipermail/nanog/2017-January/089823.html, > assuming a ROA had existed for 206.125.164.0/22, what would've been the > appropiate response from any AS involved (including route servers)? > > A) "its fine, i tagged it with a community and amplified the problem > by propagating it to all my peers" > > B) "the buck stops with me, the invalid route will not be propagated by me" > > At the very least, i'd prefer the default mode should be a secure mode, > not a 'scientifically interesting' mode. I do wonder about the rational for saying "this is invalid, but here you go" if I'm validating ROAs and my posture is that I don't accept routes with invalid ROAS then I'm not taking any action on the basis of this community. If I don't validate, I'm not taking any action on the basis of this community. > Kind regards, > > Job > ---------------- end msg 1 ----------------------- ---------------- msg 2 ----------------------------- From: Marco Marzetti Subject: Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt To: joel jaeggli Cc: Randy Bush , sidrops@ietf.org, GMO Crops , Job Snijders Date: Sat, 14 Jan 2017 12:58:14 +0100 Joel, So you don't want your upstreams to honor RPKI just because they're 3rd parties between you and the other end? In the context of IXPs: instead of peering with the RS you should setup direct sessions with your partners if you really want to do prefix/path validation by yourself. Regards --------------- end msg 2 ---------------------- -------------- msg 3 ----------------------------- From: Marco Marzetti Subject: Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt To: Christopher Morrow Cc: Randy Bush , sidrops@ietf.org, GMO Crops , Job Snijders Date: Sat, 14 Jan 2017 13:03:56 +0100 Christopher, As Nick has already pointed out as soon as you peer with the RS you've already delegated some part of the decision process to the IXP. Why RPKI can't be part of that? After all there are IXPs that filter advertisements not covered by IRR route objects. Regards --------------- end msg 3 --------------------- --------------- msg 4 --------------------------- From: Marco Marzetti Subject: Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt To: Nick Hilliard Cc: Christopher Morrow , sidrops@ietf.org, GMO Crops , Job Snijders Date: Sat, 14 Jan 2017 16:49:02 +0100 Nick, You know the IXPs's world better then me so i take your analysis as valid. But there's something that i would like to point out. The concept of IXP has changed and we cannot longer consider them as simple LANs run on top of a bunch of switches. Of course there are small entities that fit into the original definition, but there are also *very* large networks that move your packets between distant locations over MPLS. And that's much like what transit networks do. So i can't understand why we should not encourage (in a very strong way) RSs to run RPKI. That doesn't mean the RS MUST drop the prefixes: They should lower the LOCAL_PREF and as Joel has suggested add a prepend (or 2 or 3). Regards ------------------ end msg 4 ---------------------- On Fri, Jan 13, 2017 at 5:22 PM, Marco Marzetti wrote: > Christopher, > > I have to admit that i am not aware of the ongoing work on sidrops, so > i may lack the needed background, but this draft only suggests to > re-advertise all the prefixes. No matter what. > Am i wrong? In that case i apologize. > > About the forged AS_PATHs: why is this important only when it comes to > IXPs? > > Regards > > > On Fri, Jan 13, 2017 at 11:05 PM, Christopher Morrow > wrote: > > > > > > On Fri, Jan 13, 2017 at 4:54 PM, Marco Marzetti > wrote: > >> > >> > >> Every time one suggests a change related to the IXPs world we spend > >> days arguing if it affects the neutrality and how. > >> Do we really need that? > >> > >> > >> Anyway, i can't see why IXPs can blackhole traffic (if the destination > >> requests it), but cannot do the same with prefixes. > >> After all if a prefix is invalid the owner requested it to be verified > >> by the other parties. > >> > > > > I think part of job's point (and randy's in a way) is that you actually > > don't know if: > > 192.168.0.0/23 AS1 AS3 AS8 > > > > is valid, even if you see a ROA: > > 192.168.0.0/16 AS8 max-len /23 > > > > ... because there's nothing that keeps AS-ME from sending AS-JOB a route > > with AS8 prepended on the as-path. > > > >> > >> I suggest to default to drop and, if possible, to switch to announce > >> with community if the peer requests it (for instance someone may want > >> to collect invalid routes for analysis). > >> > > > > i think you are describing implementations that the IXP may choose... I > > don't know that this draft needs to specify that at all. > > > > -chris > > > >> > >> On Fri, Jan 13, 2017 at 10:20 PM, Randy Bush wrote: > >> >> Adding grow@ietf.org for reality check. > >> > > >> > no comment :) > >> > > >> > when you choose to use a route server [0], you have out-sourced much > of > >> > your policy and operational responsibilities. seems to me that > whether > >> > this includes security decisions is a contract between the user and > the > >> > route server. > >> > > >> > so i might tell the server to drop invalids. if i do not take that > >> > (configurable, i presume) option, having the server mark them seems > >> > helpful. > >> > > >> > randy > >> > > >> > -- > >> > > >> > 0 - i suspect none of job, carlos, or i do. so this is the experts > >> > telling other people what they should do. :) > >> > > >> > _______________________________________________ > >> > GROW mailing list > >> > GROW@ietf.org > >> > https://www.ietf.org/mailman/listinfo/grow > >> > >> > >> > >> -- > >> Marco > >> > >> _______________________________________________ > >> GROW mailing list > >> GROW@ietf.org > >> https://www.ietf.org/mailman/listinfo/grow > > > > > > > > -- > Marco > --001a114c877c88b08705461125a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
backup up a tad... somehow *(probably late-work-night clic= king) I added joel/marco to the 'reject mail' list :( (note that bo= th are now subscribed to the list.. if you do not want that you should go u= nsubscribe)

I'm sorry there were 4 messages, copied = here, which didn't make it to sidrops@

--= -------------- msg 1 --------------------

On 1/13/= 17 2:53 PM, Job Snijders wrote:
> On Fri, Jan 13, 2017 at 02:2= 8:23PM -0800, joel jaeggli wrote:
>> On 1/13/17 1:54 PM, Ma= rco Marzetti wrote:
>>> <rant>
>>&= gt; Every time one suggests a change related to the IXPs world we spend
>>> days arguing if it affects the neutrality and how. Do w= e really
>>> need that?
>>> </rant= >
>>>
>>> Anyway, i can't see = why IXPs can blackhole traffic (if the
>>> destination r= equests it), but cannot do the same with prefixes.
>>> A= fter all if a prefix is invalid the owner requested it to be
>= >> verified by the other parties.
>> In general the c= onsequences for IX operator that either allows it
>> custom= ers to attack each other over the exchange route-server or does
&= gt;> so itself seems severe. Loss of confidence in the disposition of on= e's
>> own routes seems like immediate grounds for depe= ering. If the routes
>> remain afterwards with the short as= path; the operator is engaged in
>> prefix hijakcing.
>>
>> I personally find it dubious that I would= choose to honor a third
>> parties efforts at origin valid= ation if I did not myself validate them
>> but a signal fro= m the exchange that it did validate the origin or that
>> t= here an invalid roa floating around is at a minimum very interesting.
=
> I still don't understand how there can be a justification as = to why it
> would be OK for route servers to redistribute pois= onous routes and say
> "trust me its OK i added a communi= ty!", and we expect some different
> behaviour from '= the rest of the AS's'?
>
>= appropiate response from any AS involved (including route servers)?
<= div>>
> =C2=A0 =C2=A0 A) "its fine, i tagged it with a= community and amplified the problem
> =C2=A0 =C2=A0 by propag= ating it to all my peers"
>
> =C2=A0 =C2=A0 = B) "the buck stops with me, the invalid route will not be propagated b= y me"
>
> At the very least, i'd prefer = the default mode should be a secure mode,
> not a 'scienti= fically interesting' mode.
I do wonder about the rational for= saying "this is invalid, but here you go"

if I'm validating ROAs and my posture is that I don't accept rou= tes with
invalid ROAS then I'm not taking any action on the b= asis of this
community. If I don't =C2=A0validate, I'm no= t taking any action on the basis
of this community.
>= ; Kind regards,
>
> Job
>

---------------- end msg 1 -----------------------
---------------- msg 2 -----------------------------

<= /div>
From: Marco Marzetti <marco@lamehost.it>
Subject: Re: [GROW] [Sidrops] I-D Act= ion: draft-ietf-sidrops-route-server-rpki-light-00.txt
To: joel j= aeggli <joelja@bogus.com>
Cc: Randy Bush <randy@psg.com>, sidrops@ietf.org, GMO Crops = <grow@ietf.org>,
=C2= =A0Job Snijders <job@ntt.net>
Date: Sat, 14 Jan 2017 12:58:14 +0100

Joel,<= /div>

So you don't want your upstreams to honor RPKI= just because they're
3rd parties between you and the other e= nd?
In the context of IXPs: instead of peering with the RS you sh= ould
setup direct sessions with your partners if you really want = to do
prefix/path validation by yourself.

Regards

--------------- end msg 2 --------= --------------
-------------- msg 3 -----------------------------=
From: Marco Marzetti <marco@lamehost.it>
Subject: Re: [GROW] [Sidrops] I-D Ac= tion: draft-ietf-sidrops-route-server-rpki-light-00.txt
To: Chris= topher Morrow <christoph= er.morrow@gmail.com>
Cc: Randy Bush <randy@psg.com>, s= idrops@ietf.org, GMO Crops <grow@ie= tf.org>,
=C2=A0Job Snijders <job@ntt.net>
Date: Sat, 14 Jan 2017 13:03:56 +0100

Christopher,

As Nick has al= ready pointed out as soon as you peer with the RS you've
alre= ady delegated some part of the decision process to the IXP.
Why R= PKI can't be part of that?

After all there are= IXPs that filter advertisements not covered by IRR
route objects= .

Regards

---------= ------ end msg 3 ---------------------
--------------- msg 4 ----= -----------------------
From: Marco Marzetti <marco@lamehost.it>
Subject: Re: = [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.= txt
To: Nick Hilliard <nick= @foobar.org>
=C2=A0GMO Crop= s <grow@ietf.org>, Job Snijders = <job@ntt.net>
Date: Sat,= 14 Jan 2017 16:49:02 +0100

Nick,

You know the IXPs's world better then me so i take your analys= is as valid.

But there's something that i woul= d like to point out.
The concept of IXP has changed and we cannot= longer consider them as
simple LANs run on top of a bunch of swi= tches.
Of course there are small entities that fit into the origi= nal
definition, but there are also *very* large networks that mov= e your
packets between distant locations over MPLS.
And= that's much like what transit networks do.

So= i can't understand why we should not encourage (in a very strong
=
way) RSs to run RPKI.
That doesn't mean the RS MUST drop= the prefixes: They should lower the
LOCAL_PREF and as Joel has s= uggested add a prepend (or 2 or 3).

Regards
<= /div>

------------------ end msg 4 ---------------------= -


On Fri, Jan 13, 2017 at 5:22 PM, Marco Marzetti <marco@lamehost= .it> wrote:
Christopher,
I have to admit that i am not aware of the ongoing work on sidrops, so
i may lack the needed background, but this draft only suggests to
re-advertise all the prefixes. No matter what.
Am i wrong? In that case i apologize.

About the forged AS_PATHs: why is this important only when it comes to IXPs= ?

Regards


On Fri, Jan 13, 2017 at 11:05 PM, Christopher Morrow
<christopher.morrow@gmai= l.com> wrote:
>
>
> On Fri, Jan 13, 2017 at 4:54 PM, Marco Marzetti <marco@lamehost.it> wrote:
>>
>> <rant>
>> Every time one suggests a change related to the IXPs world we spen= d
>> days arguing if it affects the neutrality and how.
>> Do we really need that?
>> </rant>
>>
>> Anyway, i can't see why IXPs can blackhole traffic (if the des= tination
>> requests it), but cannot do the same with prefixes.
>> After all if a prefix is invalid the owner requested it to be veri= fied
>> by the other parties.
>>
>
> I think part of job's point (and randy's in a way) is that you= actually
> don't know if:
>=C2=A0 =C2=A0192.168.0.0/23 AS1 AS3 AS8
>
> is valid, even if you see a ROA:
> 192.168.0.0/16 AS8 max-len /23
>
> ... because there's nothing that keeps AS-ME from sending AS-JOB a= route
> with AS8 prepended on the as-path.
>
>>
>> I suggest to default to drop and, if possible, to switch to announ= ce
>> with community if the peer requests it (for instance someone may w= ant
>> to collect invalid routes for analysis).
>>
>
> i think you are describing implementations that the IXP may choose... = I
> don't know that this draft needs to specify that at all.
>
> -chris
>
>>
>> On Fri, Jan 13, 2017 at 10:20 PM, Randy Bush <randy@psg.com> wrote:
>> >> Adding grow@ietf.org= for reality check.
>> >
>> > no comment :)
>> >
>> > when you choose to use a route server [0], you have out-sourc= ed much of
>> > your policy and operational responsibilities.=C2=A0 seems to = me that whether
>> > this includes security decisions is a contract between the us= er and the
>> > route server.
>> >
>> > so i might tell the server to drop invalids.=C2=A0 if i do no= t take that
>> > (configurable, i presume) option, having the server mark them= seems
>> > helpful.
>> >
>> > randy
>> >
>> > --
>> >
>> > 0 - i suspect none of job, carlos, or i do.=C2=A0 so this is = the experts
>> >=C2=A0 =C2=A0 =C2=A0telling other people what they should do. = :)
>> >
>> > _______________________________________________
>> > GROW mailing list
>> > GROW@ietf.org
>> > https://www.ietf.org/mailman/listinfo/g= row
>>
>>
>>
>> --
>> Marco
>>
>> _______________________________________________
>> GROW mailing list
>> GROW@ietf.org
>> https://www.ietf.org/mailman/listinfo/grow
>
>



--
Marco

--001a114c877c88b08705461125a4-- From nobody Sat Jan 14 09:48:51 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D889129C9E; Sat, 14 Jan 2017 09:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.133 X-Spam-Level: X-Spam-Status: No, score=-5.133 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_SOFTFAIL=0.665] 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 4wMzHXSrZaQT; Sat, 14 Jan 2017 09:48:49 -0800 (PST) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 54757129C89; Sat, 14 Jan 2017 09:48:49 -0800 (PST) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cSSRc-000A2f-Qj (job@us.ntt.net); Sat, 14 Jan 2017 17:48:49 +0000 Resent-From: Job Snijders Resent-Date: Sat, 14 Jan 2017 18:48:46 +0100 Resent-Message-ID: <20170114174846.GK1055@Vurt.local> Resent-To: sidrops@ietf.org, grow@ietf.org Delivered-To: Received: from mail3.dllstx09.us.to.gin.ntt.net ([2001:418:3ff:5::26]) by mbox3.dllstx09.us.to.gin.ntt.net (Dovecot) with LMTP id +vw+Kd9ZeVhzfwAAflkRfg for ; Fri, 13 Jan 2017 23:09:53 +0000 Received: from [2001:218:2000:b::120] (helo=mail2.tokyjp05.jp.to.gin.ntt.net) by mail3.dllstx09.us.to.gin.ntt.net with esmtp (Exim 4.84_2) (envelope-from ) id 1cSAym-000G26-Dj for job@us.ntt.net; Fri, 13 Jan 2017 23:09:53 +0000 Received: from nagasaki.bogus.com ([2001:418:1::81]) by mail2.tokyjp05.jp.to.gin.ntt.net with esmtp (Exim 4.72) (envelope-from ) id 1cSAyl-0007Xw-1M for job@ntt.net; Fri, 13 Jan 2017 23:09:51 +0000 Received: from mbp-4.local ([IPv6:2601:647:4201:9e61:7174:5d8c:98d:5336]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v0DN9lZa079595 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 13 Jan 2017 23:09:48 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:9e61:7174:5d8c:98d:5336] claimed to be mbp-4.local To: Job Snijders References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> <20a8eefe-06e5-e1c9-04f8-3c4a66bc38f1@bogus.com> <20170113225358.GE1055@Vurt.local> From: joel jaeggli Message-ID: <0d3ceafa-15e6-85a8-3f2f-d760fd83a891@bogus.com> Date: Fri, 13 Jan 2017 15:09:47 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Thunderbird/50.0 MIME-Version: 1.0 In-Reply-To: <20170113225358.GE1055@Vurt.local> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ErqV8b9ShxI6VjCEmbeP2BIT4He4B7qV0" Archived-At: Cc: Randy Bush , Marco Marzetti , sidrops@ietf.org, grow@ietf.org Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 17:48:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ErqV8b9ShxI6VjCEmbeP2BIT4He4B7qV0 Content-Type: multipart/mixed; boundary="vkhnRLiu6vnRJ9G3kEEkF4bGNCTceK24k"; protected-headers="v1" From: joel jaeggli To: Job Snijders Cc: Marco Marzetti , Randy Bush , sidrops@ietf.org, grow@ietf.org Message-ID: <0d3ceafa-15e6-85a8-3f2f-d760fd83a891@bogus.com> Subject: Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> <20a8eefe-06e5-e1c9-04f8-3c4a66bc38f1@bogus.com> <20170113225358.GE1055@Vurt.local> In-Reply-To: <20170113225358.GE1055@Vurt.local> --vkhnRLiu6vnRJ9G3kEEkF4bGNCTceK24k Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 1/13/17 2:53 PM, Job Snijders wrote: > On Fri, Jan 13, 2017 at 02:28:23PM -0800, joel jaeggli wrote: >> On 1/13/17 1:54 PM, Marco Marzetti wrote: >>> >>> Every time one suggests a change related to the IXPs world we spend >>> days arguing if it affects the neutrality and how. Do we really >>> need that? >>> >>> >>> Anyway, i can't see why IXPs can blackhole traffic (if the >>> destination requests it), but cannot do the same with prefixes. >>> After all if a prefix is invalid the owner requested it to be >>> verified by the other parties. >> In general the consequences for IX operator that either allows it >> customers to attack each other over the exchange route-server or does >> so itself seems severe. Loss of confidence in the disposition of one's= >> own routes seems like immediate grounds for depeering. If the routes >> remain afterwards with the short as path; the operator is engaged in >> prefix hijakcing. >> >> I personally find it dubious that I would choose to honor a third >> parties efforts at origin validation if I did not myself validate them= >> but a signal from the exchange that it did validate the origin or that= >> there an invalid roa floating around is at a minimum very interesting.= > I still don't understand how there can be a justification as to why it > would be OK for route servers to redistribute poisonous routes and say > "trust me its OK i added a community!", and we expect some different > behaviour from 'the rest of the AS's'? > > In a case like this http://mailman.nanog.org/pipermail/nanog/2017-Janua= ry/089823.html, > assuming a ROA had existed for 206.125.164.0/22, what would've been the= > appropiate response from any AS involved (including route servers)? > > A) "its fine, i tagged it with a community and amplified the proble= m > by propagating it to all my peers" > > B) "the buck stops with me, the invalid route will not be propagate= d by me" > > At the very least, i'd prefer the default mode should be a secure mode,= > not a 'scientifically interesting' mode. I do wonder about the rational for saying "this is invalid, but here you = go" if I'm validating ROAs and my posture is that I don't accept routes with invalid ROAS then I'm not taking any action on the basis of this community. If I don't validate, I'm not taking any action on the basis of this community. > Kind regards, > > Job > --vkhnRLiu6vnRJ9G3kEEkF4bGNCTceK24k-- --ErqV8b9ShxI6VjCEmbeP2BIT4He4B7qV0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlh5XjsACgkQ8AA1q7Z/VrLmuQCfYM4AlqcGR1gqRajJr8cZZ7Rx PA0AoICQNNH4iIz/zvXGl+KRSaH64HTU =MmPk -----END PGP SIGNATURE----- --ErqV8b9ShxI6VjCEmbeP2BIT4He4B7qV0-- From nobody Sat Jan 14 09:50:32 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41B4129CCE for ; Sat, 14 Jan 2017 09:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.133 X-Spam-Level: X-Spam-Status: No, score=-5.133 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_SOFTFAIL=0.665] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lamehost-it.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3yWAvYbE5ps for ; Sat, 14 Jan 2017 09:50:29 -0800 (PST) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 B2AB0129C89 for ; Sat, 14 Jan 2017 09:50:28 -0800 (PST) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cSSTE-000AD9-0A (job@us.ntt.net) for sidrops@ietf.org; Sat, 14 Jan 2017 17:50:28 +0000 Resent-From: Job Snijders Resent-Date: Sat, 14 Jan 2017 18:50:25 +0100 Resent-Message-ID: <20170114175025.GL1055@Vurt.local> Resent-To: sidrops@ietf.org Delivered-To: Received: from mail3.dllstx09.us.to.gin.ntt.net ([2001:418:3ff:5::26]) by mbox3.dllstx09.us.to.gin.ntt.net (Dovecot) with LMTP id LD/5NxISelgVNQAAflkRfg for ; Sat, 14 Jan 2017 11:58:20 +0000 Received: from [2001:218:2000:b::119] (helo=mail1.tokyjp05.jp.to.gin.ntt.net) by mail3.dllstx09.us.to.gin.ntt.net with esmtp (Exim 4.84_2) (envelope-from ) id 1cSMyQ-000AcR-6s for job@us.ntt.net; Sat, 14 Jan 2017 11:58:20 +0000 Received: from mail-vk0-x231.google.com ([2607:f8b0:400c:c05::231]) by mail1.tokyjp05.jp.to.gin.ntt.net with esmtp (Exim 4.72) (envelope-from ) id 1cSMyO-0000MY-FD for job@ntt.net; Sat, 14 Jan 2017 11:58:17 +0000 Received: by mail-vk0-x231.google.com with SMTP id r136so48978633vke.1 for ; Sat, 14 Jan 2017 03:58:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lamehost-it.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kLh0rznwMigBj7G1vK3YMogLg9+BKuocFnrLvpN9Eeo=; b=NxKIit/WGgv3bEW8KIOvM13O/Lapgv9anH411xZJxy3umcRhaA+gnoqi0v+EwDBumb OrSCP5/ED8LHtGcsHei/TIiNuiCuDizFN1uDp3XnPjpsO4hzWgT2Lmm/oidJjl4H3JIB MIrKHu1mhw4Er4rvFHnZLzKZqCLpqHUiBzqUy3lhcTyYhsHy/O0US1te67DmyuETYxBc mtMLgYDta6XTLQjkfoJQuW+wv3Oq+5/jz4MHQMSONS6eK9G1dqeMSuY9B9qph3flPDjx IYPLrsZs5oRSjpSrQ0w3zQj94f9bQ6ANR2kOOHv4Iuof4gr5+82Fjx/6FOylCDO7HrWo iaqg== 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=kLh0rznwMigBj7G1vK3YMogLg9+BKuocFnrLvpN9Eeo=; b=eWuS1nvzZzI1BeriMPUkwr9krj/JeETIf/H7W1W/2Vo8r14Jf2WQWApQqks1ueUs1c Tpn1j81q7AZc2pRZNq2yrrrMTN++2bPA6kAdwJZTMMwNsmARM/3URXtd6+7TgKFyhXN3 /j3xcAcVJCruLmuSoE1J/uFzt8W2RtcioswaVX7tsZbHYZoDPmhy74galNG3QOAi0P2e I4oMaY5pgwIud2HMDrDsWKj9nVPBXhI0WkYD3F+3POBxl51HR5u+6EJM572UD3JyYUXj PECfGckNjzt086gkoC266A8uXyK1+8g63TUlpOwgJmz9LiBnJNmCmTLluqNNmrR8MydW yVPA== X-Gm-Message-State: AIkVDXK4LHUUVBuAT5zAtzCyknP5u1VRITwvLD0zvdymXtpbXqAQDdKE1AgT0pUDHNI9WLIUX7V42GadtZMPsQ== X-Received: by 10.31.8.141 with SMTP id 135mr11896939vki.71.1484395095003; Sat, 14 Jan 2017 03:58:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.214 with HTTP; Sat, 14 Jan 2017 03:58:14 -0800 (PST) X-Originating-IP: [95.252.41.226] In-Reply-To: <20a8eefe-06e5-e1c9-04f8-3c4a66bc38f1@bogus.com> References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> <20a8eefe-06e5-e1c9-04f8-3c4a66bc38f1@bogus.com> From: Marco Marzetti Date: Sat, 14 Jan 2017 12:58:14 +0100 Message-ID: To: joel jaeggli Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Randy Bush , sidrops@ietf.org, GMO Crops , Job Snijders Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 17:50:31 -0000 Joel, So you don't want your upstreams to honor RPKI just because they're 3rd parties between you and the other end? In the context of IXPs: instead of peering with the RS you should setup direct sessions with your partners if you really want to do prefix/path validation by yourself. Regards On Fri, Jan 13, 2017 at 11:28 PM, joel jaeggli wrote: > On 1/13/17 1:54 PM, Marco Marzetti wrote: >> >> Every time one suggests a change related to the IXPs world we spend >> days arguing if it affects the neutrality and how. >> Do we really need that? >> >> >> Anyway, i can't see why IXPs can blackhole traffic (if the destination >> requests it), but cannot do the same with prefixes. >> After all if a prefix is invalid the owner requested it to be verified >> by the other parties. > In general the consequences for IX operator that either allows it > customers to attack each other over the exchange route-server or does so > itself seems severe. Loss of confidence in the disposition of one's own > routes seems like immediate grounds for depeering. If the routes remain > afterwards with the short as path; the operator is engaged in prefix > hijakcing. > > I personally find it dubious that I would choose to honor a third > parties efforts at origin validation if I did not myself validate them > but a signal from the exchange that it did validate the origin or that > there an invalid roa floating around is at a minimum very interesting. >> I suggest to default to drop and, if possible, to switch to announce >> with community if the peer requests it (for instance someone may want >> to collect invalid routes for analysis). >> >> >> On Fri, Jan 13, 2017 at 10:20 PM, Randy Bush wrote: >>>> Adding grow@ietf.org for reality check. >>> no comment :) >>> >>> when you choose to use a route server [0], you have out-sourced much of >>> your policy and operational responsibilities. seems to me that whether >>> this includes security decisions is a contract between the user and the >>> route server. >>> >>> so i might tell the server to drop invalids. if i do not take that >>> (configurable, i presume) option, having the server mark them seems >>> helpful. >>> >>> randy >>> >>> -- >>> >>> 0 - i suspect none of job, carlos, or i do. so this is the experts >>> telling other people what they should do. :) >>> >>> _______________________________________________ >>> GROW mailing list >>> GROW@ietf.org >>> https://www.ietf.org/mailman/listinfo/grow >> >> > > -- Marco From nobody Sat Jan 14 09:50:44 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB3C129CDE for ; Sat, 14 Jan 2017 09:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.133 X-Spam-Level: X-Spam-Status: No, score=-5.133 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_SOFTFAIL=0.665] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lamehost-it.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZsoVP8tPsuB for ; Sat, 14 Jan 2017 09:50:32 -0800 (PST) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 8E770129CD6 for ; Sat, 14 Jan 2017 09:50:32 -0800 (PST) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cSSTH-000ADD-Pl (job@us.ntt.net) for sidrops@ietf.org; Sat, 14 Jan 2017 17:50:32 +0000 Resent-From: Job Snijders Resent-Date: Sat, 14 Jan 2017 18:50:28 +0100 Resent-Message-ID: <20170114175028.GM1055@Vurt.local> Resent-To: sidrops@ietf.org Delivered-To: Received: from mail3.mlpsca01.us.to.gin.ntt.net ([2001:418:3ff:3::22]) by mbox3.dllstx09.us.to.gin.ntt.net (Dovecot) with LMTP id QK1BHrETelh5PAAAflkRfg for ; Sat, 14 Jan 2017 12:04:01 +0000 Received: from [2001:218:2000:b::120] (helo=mail2.tokyjp05.jp.to.gin.ntt.net) by mail3.mlpsca01.us.to.gin.ntt.net with esmtp (Exim 4.84_2) (envelope-from ) id 1cSN3w-000CJ8-7o for job@us.ntt.net; Sat, 14 Jan 2017 12:04:01 +0000 Received: from mail-ua0-x231.google.com ([2607:f8b0:400c:c08::231]) by mail2.tokyjp05.jp.to.gin.ntt.net with esmtp (Exim 4.72) (envelope-from ) id 1cSN3u-0001yw-Pw for job@ntt.net; Sat, 14 Jan 2017 12:03:59 +0000 Received: by mail-ua0-x231.google.com with SMTP id i68so54025744uad.0 for ; Sat, 14 Jan 2017 04:03:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lamehost-it.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yFZTZIDXXJNviU3OaJ84e9G6UpQWEMb99I6kRGfg1+o=; b=Oshlxc5UW8l1vycpwdghavzgMjlSj/UPfpGiHnsdXDNrikP/5gn8vM1MvubZdvQ3RI GE7oaLBSxGkBIpBxbLkuwEtmiMelBryVdEVmfpvNEWggacSCeFTfnovg1ZkT34nt5vHk S6xIpeXhcxawCN/t7TGNdvOPxr4j5fMD3MSCNOtNXXR/QauBF857uzNyFsmBLYyFCKmS Us0NoW1ElwmDU5d4nOYcTUoJQ6D3lOfvIuWJzBbxf6BOf+A2RPMufWF2Zxbe/bsJfkhI KB1O3jzpWijflOuezjFNsRIB6XgP68UjDde4iiMrIom8yz/FeAni7wQliQ5zmmZGs8pq JeCg== 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=yFZTZIDXXJNviU3OaJ84e9G6UpQWEMb99I6kRGfg1+o=; b=h8dgw+Gi64lkbR2FoAsMo3EjEWPG8sJk66xddJ4yVdolrCMa7hJpTMHdgY4gkDk6eU CkuE7/iYeeBMfQIp/5yFUbInJArDr3QFq8WwysKtFA84kWR/OoLN1HvfbGbR76j96xwI LjMg6nRAgO+v4hGtAbQh9diKzeRYipndYjXa/T6w/amLwdMOFDhu+liIjEYHPF8uogIc wcO6qyueUlym9wJ7IU5UGnHy+zd2ugkqrhGWJasLV3H91TguDCNKQfglfnWAAJ1JPn93 BY28di+jCQFStGDz1qOwAR+6iGSDe2m3jBzo3l6J7/ptt0FHg0PLy58RHenjFN4avtfu 4dRQ== X-Gm-Message-State: AIkVDXKNge1A1GCW5Jq1iprz5VL4iREBxRWQdcwhNrUZPdjPwI/llfgMddJLhqA5nwRtO2XfUeExWTiTGHYfjw== X-Received: by 10.176.91.72 with SMTP id v8mr13098565uae.23.1484395437413; Sat, 14 Jan 2017 04:03:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.214 with HTTP; Sat, 14 Jan 2017 04:03:56 -0800 (PST) X-Originating-IP: [95.252.41.226] In-Reply-To: References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> From: Marco Marzetti Date: Sat, 14 Jan 2017 13:03:56 +0100 Message-ID: To: Christopher Morrow Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Randy Bush , sidrops@ietf.org, GMO Crops , Job Snijders Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 17:50:33 -0000 Christopher, As Nick has already pointed out as soon as you peer with the RS you've already delegated some part of the decision process to the IXP. Why RPKI can't be part of that? After all there are IXPs that filter advertisements not covered by IRR route objects. Regards On Fri, Jan 13, 2017 at 11:53 PM, Christopher Morrow wrote: > > > On Fri, Jan 13, 2017 at 5:22 PM, Marco Marzetti wrote: >> >> Christopher, >> >> I have to admit that i am not aware of the ongoing work on sidrops, so >> i may lack the needed background, but this draft only suggests to >> re-advertise all the prefixes. No matter what. >> Am i wrong? In that case i apologize. > > > it actually, I think , just says: "put a community that can be interpreted > as valid/invalid/etc" > > I don't know that you'd want an RS keeping information from you, as a > downstream of that RS, would you? I'd rather see the things so I can decide > what's best for me. > > I think because this seems like a 'per network' or 'per ixp' concept, let's > let the document not define the implementation, but just the capability. > >> >> >> About the forged AS_PATHs: why is this important only when it comes to >> IXPs? >> > > I don't think it is. > >> >> Regards >> >> >> On Fri, Jan 13, 2017 at 11:05 PM, Christopher Morrow >> wrote: >> > >> > >> > On Fri, Jan 13, 2017 at 4:54 PM, Marco Marzetti >> > wrote: >> >> >> >> >> >> Every time one suggests a change related to the IXPs world we spend >> >> days arguing if it affects the neutrality and how. >> >> Do we really need that? >> >> >> >> >> >> Anyway, i can't see why IXPs can blackhole traffic (if the destination >> >> requests it), but cannot do the same with prefixes. >> >> After all if a prefix is invalid the owner requested it to be verified >> >> by the other parties. >> >> >> > >> > I think part of job's point (and randy's in a way) is that you actually >> > don't know if: >> > 192.168.0.0/23 AS1 AS3 AS8 >> > >> > is valid, even if you see a ROA: >> > 192.168.0.0/16 AS8 max-len /23 >> > >> > ... because there's nothing that keeps AS-ME from sending AS-JOB a route >> > with AS8 prepended on the as-path. >> > >> >> >> >> I suggest to default to drop and, if possible, to switch to announce >> >> with community if the peer requests it (for instance someone may want >> >> to collect invalid routes for analysis). >> >> >> > >> > i think you are describing implementations that the IXP may choose... I >> > don't know that this draft needs to specify that at all. >> > >> > -chris >> > >> >> >> >> On Fri, Jan 13, 2017 at 10:20 PM, Randy Bush wrote: >> >> >> Adding grow@ietf.org for reality check. >> >> > >> >> > no comment :) >> >> > >> >> > when you choose to use a route server [0], you have out-sourced much >> >> > of >> >> > your policy and operational responsibilities. seems to me that >> >> > whether >> >> > this includes security decisions is a contract between the user and >> >> > the >> >> > route server. >> >> > >> >> > so i might tell the server to drop invalids. if i do not take that >> >> > (configurable, i presume) option, having the server mark them seems >> >> > helpful. >> >> > >> >> > randy >> >> > >> >> > -- >> >> > >> >> > 0 - i suspect none of job, carlos, or i do. so this is the experts >> >> > telling other people what they should do. :) >> >> > >> >> > _______________________________________________ >> >> > GROW mailing list >> >> > GROW@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/grow >> >> >> >> >> >> >> >> -- >> >> Marco >> >> >> >> _______________________________________________ >> >> GROW mailing list >> >> GROW@ietf.org >> >> https://www.ietf.org/mailman/listinfo/grow >> > >> > >> >> >> >> -- >> Marco > > -- Marco From nobody Sat Jan 14 09:50:47 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255F2129CCE for ; Sat, 14 Jan 2017 09:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.133 X-Spam-Level: X-Spam-Status: No, score=-5.133 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_SOFTFAIL=0.665] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lamehost-it.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrIuhXVfV0aK for ; Sat, 14 Jan 2017 09:50:44 -0800 (PST) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [129.250.38.22]) (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 63F7A129CD6 for ; Sat, 14 Jan 2017 09:50:36 -0800 (PST) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cSSTL-000ADK-T0 (job@us.ntt.net) for sidrops@ietf.org; Sat, 14 Jan 2017 17:50:36 +0000 Resent-From: Job Snijders Resent-Date: Sat, 14 Jan 2017 18:50:30 +0100 Resent-Message-ID: <20170114175030.GN1055@Vurt.local> Resent-To: sidrops@ietf.org Delivered-To: Received: from mail3.mlpsca01.us.to.gin.ntt.net ([2001:418:3ff:3::22]) by mbox3.dllstx09.us.to.gin.ntt.net (Dovecot) with LMTP id aWSQGWlIelh1KwAAflkRfg for ; Sat, 14 Jan 2017 15:49:09 +0000 Received: from [2001:218:2000:b::120] (helo=mail2.tokyjp05.jp.to.gin.ntt.net) by mail3.mlpsca01.us.to.gin.ntt.net with esmtp (Exim 4.84_2) (envelope-from ) id 1cSQZm-000FFZ-HN for job@us.ntt.net; Sat, 14 Jan 2017 15:49:08 +0000 Received: from mail-ua0-x230.google.com ([2607:f8b0:400c:c08::230]) by mail2.tokyjp05.jp.to.gin.ntt.net with esmtp (Exim 4.72) (envelope-from ) id 1cSQZk-0005Kd-V3 for job@ntt.net; Sat, 14 Jan 2017 15:49:06 +0000 Received: by mail-ua0-x230.google.com with SMTP id y9so56407294uae.2 for ; Sat, 14 Jan 2017 07:49:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lamehost-it.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sWMRQiUagGCdTOKQ4QaHWBwERatq+RSCKgxEeEWpXEU=; b=Ru4bBcdegph98Z+hCK1RJpAV+aQ5teUdCI2HgNpZF/wwK0xMlbxIExC/5LH5h5ivIo TE7v5I7e88BBorkmSSETye/DdiW79HURJbcQJRBybAnN0nso+Zu5br8lBRVjgE/gLOea Py37Fad4JDRsfb1DsVax7vvUrEs65d1AQP8rsEX3u+s/r4aqJKwD+C60PzJESv8LTwLk STasHB08FJHdtu2fSUEYTpQHHeJp7tnEQpg9SmigSRiFHqDqDRO7CQRMgH60JgwGxSuM RpYEL7MWGwcUw9LZFQGO8aP1HH1NKOzGos8a/3vQJMfdt2CKZ6cfepWEcWpG6aOiF8Ix HeHA== 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=sWMRQiUagGCdTOKQ4QaHWBwERatq+RSCKgxEeEWpXEU=; b=jSKje6+Nzn4YP4nWnmMruYrjg84DmG/Y49AESiNps+WBId6jmuqauSRcr1Kc0GY6bX RObwfdHeBHKI/nmyG7rXvcHEjCoCOI4Co5qwa8BmSNiXrWAJPtdnTFyABi8GJaSiIJMr jSE2/xPxYvqN7FNtuF9Qk9okUBFgB6HtadOaPW6pbyLCC8Ifym6V3sFzQjDrlGjdsax5 nCQCdTTPaEGXkEtEQIRKWWFM2XuLT7YqjUFqdovkTeACHKwlcZh7gIQaa1a/4TSb1aai jmI6yN+zdmhtNLkL7PLRfZ9KwsCLtvmpaKUHwqAQ+cBK4b52hv4i0YQ26n0wy0B2XOo/ nnOA== X-Gm-Message-State: AIkVDXIH5C6YMJuBaux/yXIOTP/5nKiEaMFYg25UyDJD0gAV6ORbZkxTmND+sWTk8bSRCblbaKbrCViAby5amA== X-Received: by 10.176.84.157 with SMTP id p29mr578041uaa.129.1484408943411; Sat, 14 Jan 2017 07:49:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.214 with HTTP; Sat, 14 Jan 2017 07:49:02 -0800 (PST) X-Originating-IP: [95.252.41.226] In-Reply-To: <587A3E68.9040805@foobar.org> References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> <587A3E68.9040805@foobar.org> From: Marco Marzetti Date: Sat, 14 Jan 2017 16:49:02 +0100 Message-ID: To: Nick Hilliard Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Christopher Morrow , GMO Crops , sidrops@ietf.org, Job Snijders Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 17:50:45 -0000 Nick, You know the IXPs's world better then me so i take your analysis as valid. But there's something that i would like to point out. The concept of IXP has changed and we cannot longer consider them as simple LANs run on top of a bunch of switches. Of course there are small entities that fit into the original definition, but there are also *very* large networks that move your packets between distant locations over MPLS. And that's much like what transit networks do. So i can't understand why we should not encourage (in a very strong way) RSs to run RPKI. That doesn't mean the RS MUST drop the prefixes: They should lower the LOCAL_PREF and as Joel has suggested add a prepend (or 2 or 3). Regards On Sat, Jan 14, 2017 at 4:06 PM, Nick Hilliard wrote: > Marco Marzetti wrote: >> Why RPKI can't be part of that? > > tl;dr: route servers and rpki are an uncomfortable fit. > > rpki can be part of that, but it's problematic because the route server > is running the routing decision engine on the part of the client. RPKI > is a relatively fine-grained tool in the list of things that are taken > into account for the best path calculation, which means that there is a > genuine difficulty in providing enough fine-grained levers so that the > route server can handle this in a way that works well for clients. > > As others have pointed out, the control mechanisms that rpki allows are > much easier to handle on bilateral bgp sessions than multilateral. > > These problems mostly disappear if the route server and client use > add-path, because that shifts the burden of handling the policy > application fully to the client. Where add-path is used, there is no > requirement to mark routes with communities firstly because no routing > policy action has been taken by the route server and secondly because > the client can check the ROA themselves. The usual caveats about > add-path apply. > > Stepping back a bit, most organisations who use route servers are > sufficiently small that they don't need anything more than highly > simplistic exterior routing policies, where almost everything is handled > by the default bgp decision process documented in rfc4271, and final > tweaks are handled by applying a single med or localpref for all peers > or all transits or whatever. This is the category of ASNs that route > servers work best for. Once an organisation grows beyond a certain size, > it's quite usual to move away from using route servers - and at a later > stage still, to move away from using IXPs in favour of PNIs. > > If an organisation's routing policies are more complicated than most, > then route servers are generally unsuitable anyway. RPKI will reduce > that boundary of suitability, but not by much. I'd hazard a guess that > if an IXP were to provide a primitive facility in their provisioning > system to allow clients to specify whether they wanted rpki-invalid or > rpki-notfound dropped or used in the decision engine, that would satisfy > most route server client organisations' policy requirements. Obviously > this is not going to work for all organisations, but adding in more > fine-grained controls runs into diminishing returns very quickly indeed, > as has been implicitly noted in the ixp industry by the scarcity of > generally accepted policy controls outside the usual "redistribute or > don't redistribute my prefixes to ASN X" community tags. > > If AS path validation ever happens, then this probably not work with > route servers at all, but that's a different thing, outside the scope of > this conversation. > > Nick -- Marco From nobody Sat Jan 14 11:53:36 2017 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E84129D68; Sat, 14 Jan 2017 11:53:30 -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.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148442361061.24153.11398200809305398174.idtracker@ietfa.amsl.com> Date: Sat, 14 Jan 2017 11:53:30 -0800 Archived-At: Cc: sidrops@ietf.org Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-tree-validation-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 19:53:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations of the IETF. Title : RPKI Certificate Tree Validation by the RIPE NCC RPKI Validator Authors : Oleg Muravskiy Tim Bruijnzeels Filename : draft-ietf-sidrops-rpki-tree-validation-00.txt Pages : 15 Date : 2017-01-14 Abstract: This document describes the approach to validate the content of the RPKI certificate tree, as used by the RIPE NCC RPKI Validator. This approach is independent of a particular object retrieval mechanism. This allows it to be used with repositories available over the rsync protocol, the RPKI Repository Delta Protocol, and repositories that use a mix of both. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-tree-validation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidrops-rpki-tree-validation-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jan 14 12:10:43 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13BE129D82; Sat, 14 Jan 2017 12:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] 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 ztM4jY_YoFwI; Sat, 14 Jan 2017 12:10:41 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 2F8D2129D79; Sat, 14 Jan 2017 12:10:41 -0800 (PST) Received: from mb-3.local ([IPv6:2601:647:4201:9e61:957b:b20e:5e52:b92d]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v0EKAcjF086074 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sat, 14 Jan 2017 20:10:39 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:9e61:957b:b20e:5e52:b92d] claimed to be mb-3.local To: Marco Marzetti References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> <20a8eefe-06e5-e1c9-04f8-3c4a66bc38f1@bogus.com> From: joel jaeggli Message-ID: <44b83365-8ada-4e35-e485-885caa150f44@bogus.com> Date: Sat, 14 Jan 2017 12:10:37 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Thunderbird/50.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Aj8TsbEHlXN5ISBT6qVLG3J9tWKSWXBlN" Archived-At: Cc: Randy Bush , sidrops@ietf.org, GMO Crops , Job Snijders Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 20:10:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Aj8TsbEHlXN5ISBT6qVLG3J9tWKSWXBlN Content-Type: multipart/mixed; boundary="n3qePpVquGrE9oQHcvbjIE5WNHwXErmUP"; protected-headers="v1" From: joel jaeggli To: Marco Marzetti Cc: Randy Bush , sidrops@ietf.org, GMO Crops , Job Snijders Message-ID: <44b83365-8ada-4e35-e485-885caa150f44@bogus.com> Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> <20a8eefe-06e5-e1c9-04f8-3c4a66bc38f1@bogus.com> In-Reply-To: --n3qePpVquGrE9oQHcvbjIE5WNHwXErmUP Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 1/14/17 3:58 AM, Marco Marzetti wrote: > Joel, >=20 > So you don't want your upstreams to honor RPKI just because they're > 3rd parties between you and the other end? An ixp route-server is not a transit provider, all of the nexthops exposed are in fact peers. So no I do not consider such a device an "upstream" it exists to service the policy needs of the peers on the fabric rather than that of the exchange operator. I would expect that a ixp route server that had a state policy of validating rpki would not propagate invalid routes. > In the context of IXPs: instead of peering with the RS you should > setup direct sessions with your partners if you really want to do > prefix/path validation by yourself. No, I setup bilateral peering arrangements because they actually load balance to my multiple ports, because the loci of control is unambiguous, because it facilitates greatly build per session prefix filters, and because they converge the control and forwarding path, which has a tendency to fail much more gracefully in the face of l2 failures in distributed exchange fabric designs then does the route-serve= r. > Regards >=20 >=20 > On Fri, Jan 13, 2017 at 11:28 PM, joel jaeggli wrote= : >> On 1/13/17 1:54 PM, Marco Marzetti wrote: >>> >>> Every time one suggests a change related to the IXPs world we spend >>> days arguing if it affects the neutrality and how. >>> Do we really need that? >>> >>> >>> Anyway, i can't see why IXPs can blackhole traffic (if the destinatio= n >>> requests it), but cannot do the same with prefixes. >>> After all if a prefix is invalid the owner requested it to be verifie= d >>> by the other parties. >> In general the consequences for IX operator that either allows it >> customers to attack each other over the exchange route-server or does = so >> itself seems severe. Loss of confidence in the disposition of one's ow= n >> routes seems like immediate grounds for depeering. If the routes remai= n >> afterwards with the short as path; the operator is engaged in prefix >> hijakcing. >> >> I personally find it dubious that I would choose to honor a third >> parties efforts at origin validation if I did not myself validate them= >> but a signal from the exchange that it did validate the origin or that= >> there an invalid roa floating around is at a minimum very interesting.= >>> I suggest to default to drop and, if possible, to switch to announce >>> with community if the peer requests it (for instance someone may want= >>> to collect invalid routes for analysis). >>> >>> >>> On Fri, Jan 13, 2017 at 10:20 PM, Randy Bush wrote: >>>>> Adding grow@ietf.org for reality check. >>>> no comment :) >>>> >>>> when you choose to use a route server [0], you have out-sourced much= of >>>> your policy and operational responsibilities. seems to me that whet= her >>>> this includes security decisions is a contract between the user and = the >>>> route server. >>>> >>>> so i might tell the server to drop invalids. if i do not take that >>>> (configurable, i presume) option, having the server mark them seems >>>> helpful. >>>> >>>> randy >>>> >>>> -- >>>> >>>> 0 - i suspect none of job, carlos, or i do. so this is the experts >>>> telling other people what they should do. :) >>>> >>>> _______________________________________________ >>>> GROW mailing list >>>> GROW@ietf.org >>>> https://www.ietf.org/mailman/listinfo/grow >>> >>> >> >> >=20 >=20 >=20 --n3qePpVquGrE9oQHcvbjIE5WNHwXErmUP-- --Aj8TsbEHlXN5ISBT6qVLG3J9tWKSWXBlN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlh6hb4ACgkQ8AA1q7Z/VrLA1gCeIiv8GsBinuOnRHl5CkZc8u4K EwgAnRwhc+sUw9MFoYqbNcP+MssGt0Hr =sBLi -----END PGP SIGNATURE----- --Aj8TsbEHlXN5ISBT6qVLG3J9tWKSWXBlN-- From nobody Sat Jan 14 13:53:55 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07C2129408; Sat, 14 Jan 2017 13:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hj6vk12gtNkc; Sat, 14 Jan 2017 13:53:52 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2DBB126579; Sat, 14 Jan 2017 13:53:51 -0800 (PST) X-Envelope-To: grow@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v0ELrkXl037108 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jan 2017 21:53:46 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <587A9DE9.1000608@foobar.org> Date: Sat, 14 Jan 2017 21:53:45 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.9 (Macintosh/20161202) MIME-Version: 1.0 To: Matthias Waehlisch References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> <58795A0B.6000009@foobar.org> <587A03CF.3010001@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "Carlos M. Martinez" , sidrops@ietf.org, GMO Crops , job@ntt.net Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 21:53:54 -0000 Matthias Waehlisch wrote: > the current discussion makes clear that documentation of > origin-validation-signaling in IXP context is needed rpki is conceptually no different to any other type of signaling mechanism: it's simply another input into the BGP decision engine process, just like communities or meds or as-path. What we're losing sight of here is that it's the route server which calculates the best path for each route using the routing decision engine, and then sends a _single_ best path to the client. Conceptually, it doesn't matter whether the tie-breaker on the route server is communities, meds, as-path or rpki: the point is that the policy decision mechanism needs to be configured on the route server itself, because the route server is the device which is calculating the best path. If the route server operator doesn't do this, the clients will end up with path hiding (see 2.3.1 in rfc7947). I.e. it's nothing specific to rpki. This is already extensively documented in rfc7947 and rfc7948. Nick From nobody Sat Jan 14 16:32:29 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B44129E99; Sat, 14 Jan 2017 16:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 9W6rmX_XP4lz; Sat, 14 Jan 2017 16:32:26 -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 C14341294CE; Sat, 14 Jan 2017 16:32:26 -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 1cSYkC-0007zz-Kc; Sun, 15 Jan 2017 00:32:24 +0000 Date: Sun, 15 Jan 2017 09:32:22 +0900 Message-ID: From: Randy Bush To: joel jaeggli In-Reply-To: <44b83365-8ada-4e35-e485-885caa150f44@bogus.com> References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> <20a8eefe-06e5-e1c9-04f8-3c4a66bc38f1@bogus.com> <44b83365-8ada-4e35-e485-885caa150f44@bogus.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: sidrops@ietf.org, GMO Crops Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 00:32:28 -0000 [ first, i do not use route serves (because of the data/control non- congruence), so my opinion here is worth even less than it normally is. ] > An ixp route-server is not a transit provider, all of the nexthops > exposed are in fact peers. So no I do not consider such a device an > "upstream" it exists to service the policy needs of the peers on the > fabric rather than that of the exchange operator. to repeat my previous; those policy needs might vary across ix members. some may want the ix to enforce origin validation for them, some may not. those exchanges which offer validation today offer the choice. i think that is the right thing; let the member make the choice at set-up with the route server. > No, I setup bilateral peering arrangements because they actually load > balance to my multiple ports, because the loci of control is > unambiguous, because it facilitates greatly build per session prefix > filters, and because they converge the control and forwarding path, > which has a tendency to fail much more gracefully in the face of l2 > failures in distributed exchange fabric designs then does the > route-server. there's a draft for that :) randy From nobody Sun Jan 15 06:36:03 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7360012959E for ; Sun, 15 Jan 2017 06:36:01 -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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lamehost-it.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0y6oGWBhECy for ; Sun, 15 Jan 2017 06:35:59 -0800 (PST) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE49612957F for ; Sun, 15 Jan 2017 06:35:58 -0800 (PST) Received: by mail-ua0-x232.google.com with SMTP id y9so66762430uae.2 for ; Sun, 15 Jan 2017 06:35:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lamehost-it.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S2SLIRk2j/rjLIiATEOCZuBlB0q4gcwvECWNZNRPCJw=; b=jzG99fZ0N1PQxh7smoDSkXKI0SVzI/6aqDcjueq1o/bZZ8nEnC0Hy8DK8VJ9ySE7Tu bMV2OUjFLiCvdCQ53F5JXGlhYb2mtgD5kW27dNInSEDNIgiJeVt+qeGAzky+xy5u0ptK Suwj1Bh31KLwfspwJNXBtWIS68d2JEd+YoNzAMzqGZVfcB44u3htgWDhtugPcjTNzaaa jCsXj+llpi9gC2Mztyi8q6d3mtkfAAN8tJH/Ka0Bue3icpYRJG8cbFCplkbikqZheQ0n aVkxPFOm2TwDvpfS2nMPUR92Uuln4INANR6t3hf5n0NZhUD7/qCq5KGkstK44HTK96O9 ovAA== 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=S2SLIRk2j/rjLIiATEOCZuBlB0q4gcwvECWNZNRPCJw=; b=kLG9mt3NgLPxdrcjLvy3JMo8kPSfQZzFYz3px2DgBL3ypBqifh15OxMahz+fE5H1Qr 6IHunoyjuXl2GnKVTTO5tD7d/8Yq8P7ZGQa4fIydY00T8akVm3wlR0Muxn57tteAAdzS mBR8zaQcNDy4AfhiGQoOeMDNGvGzBiVWKjGfnv9ji8FYiMiXUg4W8sVuLjzkeXljq28V eayGvuBUhdNN7q/ijoNRoH/lmjGfYKilhT3tzwxsxsF+h6WyGcLhPo3ktSEkbgVZoOe8 OH1Z17ittLSY5R31R12kZxiHgeKQwX5jyTWFfAR5B7+FLE+zEP2HFTBEwcipJmyXrZ8v 5yBA== X-Gm-Message-State: AIkVDXLK282UdAVa2pfDzAEye2XuEixkmU+YRYwYFsplWhO7rrl8LrpMgFPMfdjT9F1N537tp5FCaa4Tde8VjA== X-Received: by 10.176.81.215 with SMTP id h23mr16239780uaa.21.1484490957392; Sun, 15 Jan 2017 06:35:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.214 with HTTP; Sun, 15 Jan 2017 06:35:56 -0800 (PST) X-Originating-IP: [95.252.41.226] In-Reply-To: <44b83365-8ada-4e35-e485-885caa150f44@bogus.com> References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> <20a8eefe-06e5-e1c9-04f8-3c4a66bc38f1@bogus.com> <44b83365-8ada-4e35-e485-885caa150f44@bogus.com> From: Marco Marzetti Date: Sun, 15 Jan 2017 15:35:56 +0100 Message-ID: To: joel jaeggli Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Randy Bush , sidrops@ietf.org, GMO Crops , Job Snijders Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 14:36:01 -0000 On Sat, Jan 14, 2017 at 9:10 PM, joel jaeggli wrote: > On 1/14/17 3:58 AM, Marco Marzetti wrote: >> Joel, >> >> So you don't want your upstreams to honor RPKI just because they're >> 3rd parties between you and the other end? > > An ixp route-server is not a transit provider, all of the nexthops > exposed are in fact peers. So no I do not consider such a device an > "upstream" it exists to service the policy needs of the peers on the > fabric rather than that of the exchange operator. > You can easily do the same in transit providers by disabling next-hop-self. > I would expect that a ixp route server that had a state policy of > validating rpki would not propagate invalid routes. > >> In the context of IXPs: instead of peering with the RS you should >> setup direct sessions with your partners if you really want to do >> prefix/path validation by yourself. > > No, I setup bilateral peering arrangements because they actually load > balance to my multiple ports, because the loci of control is > unambiguous, because it facilitates greatly build per session prefix > filters, and because they converge the control and forwarding path, > which has a tendency to fail much more gracefully in the face of l2 > failures in distributed exchange fabric designs then does the route-server. > Aren't we saying the same thing? Bilateral peering brings more control over what you send and receive. I just take an additional step and say that RPKI should be part of the default decision process of RSs Regards. >> Regards >> >> >> On Fri, Jan 13, 2017 at 11:28 PM, joel jaeggli wrote: >>> On 1/13/17 1:54 PM, Marco Marzetti wrote: >>>> >>>> Every time one suggests a change related to the IXPs world we spend >>>> days arguing if it affects the neutrality and how. >>>> Do we really need that? >>>> >>>> >>>> Anyway, i can't see why IXPs can blackhole traffic (if the destination >>>> requests it), but cannot do the same with prefixes. >>>> After all if a prefix is invalid the owner requested it to be verified >>>> by the other parties. >>> In general the consequences for IX operator that either allows it >>> customers to attack each other over the exchange route-server or does so >>> itself seems severe. Loss of confidence in the disposition of one's own >>> routes seems like immediate grounds for depeering. If the routes remain >>> afterwards with the short as path; the operator is engaged in prefix >>> hijakcing. >>> >>> I personally find it dubious that I would choose to honor a third >>> parties efforts at origin validation if I did not myself validate them >>> but a signal from the exchange that it did validate the origin or that >>> there an invalid roa floating around is at a minimum very interesting. >>>> I suggest to default to drop and, if possible, to switch to announce >>>> with community if the peer requests it (for instance someone may want >>>> to collect invalid routes for analysis). >>>> >>>> >>>> On Fri, Jan 13, 2017 at 10:20 PM, Randy Bush wrote: >>>>>> Adding grow@ietf.org for reality check. >>>>> no comment :) >>>>> >>>>> when you choose to use a route server [0], you have out-sourced much of >>>>> your policy and operational responsibilities. seems to me that whether >>>>> this includes security decisions is a contract between the user and the >>>>> route server. >>>>> >>>>> so i might tell the server to drop invalids. if i do not take that >>>>> (configurable, i presume) option, having the server mark them seems >>>>> helpful. >>>>> >>>>> randy >>>>> >>>>> -- >>>>> >>>>> 0 - i suspect none of job, carlos, or i do. so this is the experts >>>>> telling other people what they should do. :) >>>>> >>>>> _______________________________________________ >>>>> GROW mailing list >>>>> GROW@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/grow >>>> >>>> >>> >>> >> >> >> > > -- Marco From nobody Sun Jan 15 06:39:42 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E52212959E for ; Sun, 15 Jan 2017 06:39: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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lamehost-it.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUhI2lvFuejI for ; Sun, 15 Jan 2017 06:39:39 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::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 EDBA212959D for ; Sun, 15 Jan 2017 06:39:38 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id t8so60046884vke.3 for ; Sun, 15 Jan 2017 06:39:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lamehost-it.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=efSIcAbfewzUheaqd9z4D3PFYaJLuQaMcgDlhDsN5GA=; b=WzrzVBT6QXjf7Rsi68TLjDUjM6H+b0ZFZyooOfd4ByzA42NclcByHDPMcq53TKkPNE 3yliDL15np7k0hxi+0y9V0l8WjCO3KKolcUMZYEKN7tbWsRZzqrFNUg5pXURH7kZzLiW BTNWewwAuA7x4pP61vfytu9/03Xb7NjvJ22DcYD1kNW5J2BAsFGXpUPwA5aOC60HEpfW wr39d/LrRu84FjNgzAu1jwixEQqhIqjSv7kO2agz9Nbgfp+wYGX2E3Q4WNJzc8Z8lXJW rdAvaSlxKYbtiy+j/hamNCo24l80YLk4NUdFWxna4chfkMxpfs8XHYyJV+9+fZOvfSsm Kh2g== 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=efSIcAbfewzUheaqd9z4D3PFYaJLuQaMcgDlhDsN5GA=; b=ooM6fyM+3d7GY3DbMX57oGnxAyIpKW6AvOdnTDkJOGkJeNezsZeVDTZc7rRzPHHxuH ikMAI7pGekrzj2lELoJ1nox+VEMJpx0IbsU9o7vY85gW5ubBeXVvSuP4LQQ64ddL5g5V 0it88Q99K/ZnXtjPXBO8un3qQcl0P8T8/KsN8CFVt3jBiv2xq7TzG0GBdRRqBlIPdL5M mt9vZ0k52XKF/YlTVWsUe151nWW5qubk1s3IbzLiRht/hMNJmk3VCZaurhAt50u9aOd1 0Ucb3qejDEtU8QQcQwvgtxuMcquNgHVmAQQ8youERqTCVeFnFhi1SOIcJhwvY/DsfbRZ A7YA== X-Gm-Message-State: AIkVDXJdxXhqOzemawK5ghBnm1wjRc5JQk2qp+bV0bmVZo3Pk3LVGxyqluK1z/lc79VmE2e05fGrZ+thDVk6sw== X-Received: by 10.31.230.134 with SMTP id d128mr13898897vkh.118.1484491178092; Sun, 15 Jan 2017 06:39:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.214 with HTTP; Sun, 15 Jan 2017 06:39:37 -0800 (PST) X-Originating-IP: [95.252.41.226] In-Reply-To: References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> <20a8eefe-06e5-e1c9-04f8-3c4a66bc38f1@bogus.com> <44b83365-8ada-4e35-e485-885caa150f44@bogus.com> From: Marco Marzetti Date: Sun, 15 Jan 2017 15:39:37 +0100 Message-ID: To: Randy Bush Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: joel jaeggli , sidrops@ietf.org, GMO Crops Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 14:39:40 -0000 On Sun, Jan 15, 2017 at 1:32 AM, Randy Bush wrote: > [ first, i do not use route serves (because of the data/control non- > congruence), so my opinion here is worth even less than it normally > is. ] > >> An ixp route-server is not a transit provider, all of the nexthops >> exposed are in fact peers. So no I do not consider such a device an >> "upstream" it exists to service the policy needs of the peers on the >> fabric rather than that of the exchange operator. > > to repeat my previous; those policy needs might vary across ix members. > some may want the ix to enforce origin validation for them, some may > not. those exchanges which offer validation today offer the choice. i > think that is the right thing; let the member make the choice at set-up > with the route server. I think RSs should do RPKI by default and allow for two behaviors: 1) Drop (default) 2) Add ext-community as this draft suggests (upon request) Regards -- Marco From nobody Sun Jan 15 07:03:53 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1293912959D for ; Sun, 15 Jan 2017 07:03:52 -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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lamehost-it.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGwiYrNss9mZ for ; Sun, 15 Jan 2017 07:03:50 -0800 (PST) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6026612947A for ; Sun, 15 Jan 2017 07:03:50 -0800 (PST) Received: by mail-ua0-x232.google.com with SMTP id 35so66711116uak.1 for ; Sun, 15 Jan 2017 07:03:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lamehost-it.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HtWKAVrV3NW8eCs8iPZxYEqRMv1fm8l1ybHYJ9SQ2DM=; b=a7ewK+OXBnkGxjNN9W5o8DgITKRoCVIkntSqU5WMGPXnXNE/acXQ1EAQdGDIAhZkXf uj4UO52xONvfUL1ITbCkb3lq0idAciNg3PvZVTRWiIUYD4ztLhfSR1gf+7LNM4cKFnCQ dfpmkzpUJJE03XqsROxyRXAJSREhfh/OWP/4Z9CTM8GOpjo65LubFjYY9sA7dRlxq2o4 iBJ6VjZQ0222lNERER4fQW9GcbLLQYgR0ZUM6rZmOCUIlZ6r5bUQ1wqfKcRTIQY6vyu6 84Y98OIybFU1Od9lCzq3f4QJEFQZJuvhnlOL6pAn1Xd1oKvMQY/tB7NaCwrC2Sjco8ek U9iQ== 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=HtWKAVrV3NW8eCs8iPZxYEqRMv1fm8l1ybHYJ9SQ2DM=; b=r3Xu7Ou2KGX+1XFqRBmPUk/jw9Et6Cf36buzCma08PB/Ba4cOgINdWrNJkaJySHEyt iAKmP13Gv9XcobhiOTibDhdrQOkN3qbs3ryRii5PGOwQ1XdGNvby1S2SL1HKFW8LftOJ /lgxtTladfv3xLU5mhT33x9yAb7xtNfW6EcHkPaNbQmaEH7NvSuvpfTP9gMI+QkFhdip rquymEMMDNynkHgCa1xYrk52ulZW24gF8p8oPlQcPub8tHxgr1Rs4fuIG4z2QHDB2+X9 QhpP5gbxEtVrk8SyqMls4yMPk4MP9t+RBv1++JSWy7Dz1XOkbQRNTWiXhLn7uGO4PmzN h+OQ== X-Gm-Message-State: AIkVDXKQ0TDnrsR2GHH8HB8478aDqVsn+DC1O43pLaDM8VPXnUE11SKj6KqYfcu2IJfMVfbc/VKlJYdlVNhlkg== X-Received: by 10.176.75.149 with SMTP id v21mr15178074uaf.94.1484492629529; Sun, 15 Jan 2017 07:03:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.214 with HTTP; Sun, 15 Jan 2017 07:03:48 -0800 (PST) X-Originating-IP: [95.252.41.226] In-Reply-To: <20170115144943.GF1062@Vurt.local> References: <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> <20a8eefe-06e5-e1c9-04f8-3c4a66bc38f1@bogus.com> <44b83365-8ada-4e35-e485-885caa150f44@bogus.com> <20170115144943.GF1062@Vurt.local> From: Marco Marzetti Date: Sun, 15 Jan 2017 16:03:48 +0100 Message-ID: To: Job Snijders Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Randy Bush , sidrops@ietf.org, GMO Crops Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 15:03:52 -0000 On Sun, Jan 15, 2017 at 3:49 PM, Job Snijders wrote: > On Sun, Jan 15, 2017 at 03:39:37PM +0100, Marco Marzetti wrote: >> On Sun, Jan 15, 2017 at 1:32 AM, Randy Bush wrote: >> > [ first, i do not use route serves (because of the data/control non- >> > congruence), so my opinion here is worth even less than it normally >> > is. ] >> > >> >> An ixp route-server is not a transit provider, all of the nexthops >> >> exposed are in fact peers. So no I do not consider such a device an >> >> "upstream" it exists to service the policy needs of the peers on the >> >> fabric rather than that of the exchange operator. >> > >> > to repeat my previous; those policy needs might vary across ix members. >> > some may want the ix to enforce origin validation for them, some may >> > not. those exchanges which offer validation today offer the choice. i >> > think that is the right thing; let the member make the choice at set-up >> > with the route server. >> >> I think RSs should do RPKI by default and allow for two behaviors: >> 1) Drop (default) >> 2) Add ext-community as this draft suggests (upon request) > > Or perhaps we consider a Route Server to be "Just Yet Another Autonomous > System"? Why should there be a difference between Autonomous Systems > with regard to routing security recommendations? > I do consider it "another AS". > If the recommendation is to drop/ignore/reject "RPKI Invalid" > announcements, then that applies to Route Servers too, if the > recommendation is to just attach an Extended BGP Community, then that > will apply to all ASNs. What's the current recommendation now? Regards -- Marco From nobody Sun Jan 15 09:08:21 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BDF129547 for ; Sun, 15 Jan 2017 06:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8bmpSRbkWVd for ; Sun, 15 Jan 2017 06:49:49 -0800 (PST) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 4EB7512959D for ; Sun, 15 Jan 2017 06:49:49 -0800 (PST) Received: by mail-wm0-x244.google.com with SMTP id d140so7988158wmd.2 for ; Sun, 15 Jan 2017 06:49:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=bRNcgxHz2WZoD+YlloeSJ2li6WpkppFwtFR+CbmGT1k=; b=UT7bVIXK1sP+e3aeF7j3dVe2XGF78RQnJ7W5n87sQyEeMZ0QrE6DeaI8X5zHyiQGdP LBzu9oP4+S98MYjluFHhMd+pKgxfVUgBkGB23IvprIdJlIaL+TpP7eWN//ZO5YrPDdv9 rsCCAUiu52pP8BxFjRK0zJrf0t9SsoTFlHmAe28oULrF64DgFNRmPq/pQSsP/3gkOQ07 WVg00i1VwlSmv85ULlyy0AHrQM4GTDkUlsEN2Rxa/kcTwTsuMUE/aJ0GVGKemE85seJj 086wwdQ0rN482K9QDpdTomR+PdhPeuffd+PBGpzmy8DDUbKsB8fdzT1MIMtU7EeW2AKg hw3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=bRNcgxHz2WZoD+YlloeSJ2li6WpkppFwtFR+CbmGT1k=; b=EDgYHcIqa5+WlMi7amr6gSunoETEKI7203H8ie3td92Cp1YAv0mXkXaVqul8NLproH 7YE8T5j9KQPYgNSCh83DM9CxrYVTwgam6WT7tEfHh4TSlAzHQbLocOhqdEyxlzMhCpjq YFL905/Lwo6Z7zdGrUFb0Mwi5gClBNmeq1m/pMgjAUrrntbRilklH2DxZbsh4rkDv+JD 6yxZZrqMO0T7Of/f4TbNfBt+UCjn/YCkmtL0NOSmsIA1ey+HC4bdW6bK8s5QbfxHUvqH bwcdNjrEZH08nC4Tmg2h4euh9p6s8TejBb54GpMGsFb84eJeFSzKATWLPQ5wWEvgo+sU E/gA== X-Gm-Message-State: AIkVDXJbYsU2NX9+7hAkDBOJjDcW2rIaBzHtDturKNTycfpgd03yrg7SpxsiOW5acpaC9w== X-Received: by 10.28.126.146 with SMTP id z140mr9933467wmc.84.1484491787565; Sun, 15 Jan 2017 06:49:47 -0800 (PST) Received: from localhost ([2001:67c:208c:10:61ed:4291:8634:b837]) by smtp.gmail.com with ESMTPSA id w7sm21400037wmd.24.2017.01.15.06.49.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Jan 2017 06:49:46 -0800 (PST) Date: Sun, 15 Jan 2017 15:49:43 +0100 From: Job Snijders To: Marco Marzetti Message-ID: <20170115144943.GF1062@Vurt.local> References: <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> <20a8eefe-06e5-e1c9-04f8-3c4a66bc38f1@bogus.com> <44b83365-8ada-4e35-e485-885caa150f44@bogus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: X-Mailman-Approved-At: Sun, 15 Jan 2017 09:08:19 -0800 Cc: Randy Bush , sidrops@ietf.org, GMO Crops Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 14:49:52 -0000 On Sun, Jan 15, 2017 at 03:39:37PM +0100, Marco Marzetti wrote: > On Sun, Jan 15, 2017 at 1:32 AM, Randy Bush wrote: > > [ first, i do not use route serves (because of the data/control non- > > congruence), so my opinion here is worth even less than it normally > > is. ] > > > >> An ixp route-server is not a transit provider, all of the nexthops > >> exposed are in fact peers. So no I do not consider such a device an > >> "upstream" it exists to service the policy needs of the peers on the > >> fabric rather than that of the exchange operator. > > > > to repeat my previous; those policy needs might vary across ix members. > > some may want the ix to enforce origin validation for them, some may > > not. those exchanges which offer validation today offer the choice. i > > think that is the right thing; let the member make the choice at set-up > > with the route server. > > I think RSs should do RPKI by default and allow for two behaviors: > 1) Drop (default) > 2) Add ext-community as this draft suggests (upon request) Or perhaps we consider a Route Server to be "Just Yet Another Autonomous System"? Why should there be a difference between Autonomous Systems with regard to routing security recommendations? If the recommendation is to drop/ignore/reject "RPKI Invalid" announcements, then that applies to Route Servers too, if the recommendation is to just attach an Extended BGP Community, then that will apply to all ASNs. Kind regards, Job From nobody Sun Jan 15 15:04:25 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C94129481; Sun, 15 Jan 2017 15:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.72 X-Spam-Level: X-Spam-Status: No, score=-4.72 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, 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 NDPzBBY7XYh1; Sun, 15 Jan 2017 15:04:23 -0800 (PST) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBE0A1293F0; Sun, 15 Jan 2017 15:04:22 -0800 (PST) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1cStqU-003fL7-VN>; Mon, 16 Jan 2017 00:04:18 +0100 Received: from x5ce7e1b5.dyn.telefonica.de ([92.231.225.181] helo=mw-PC.fritz.box) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1:AES256-SHA:256) (envelope-from ) id <1cStqU-002sKz-K5>; Mon, 16 Jan 2017 00:04:18 +0100 Date: Mon, 16 Jan 2017 00:03:40 +0100 From: Matthias Waehlisch To: Nick Hilliard In-Reply-To: <587A9DE9.1000608@foobar.org> Message-ID: References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> <58795A0B.6000009@foobar.org> <587A03CF.3010001@foobar.org> <587A9DE9.1000608@foobar.org> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) X-X-Sender: waehl@mail.zedat.fu-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Originating-IP: 92.231.225.181 Archived-At: Cc: "Carlos M. Martinez" , sidrops@ietf.org, GMO Crops , job@ntt.net Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 23:04:24 -0000 I don't know if we are losing sight. The argument that RS is doing best path selection was stated several times. However, I still don't buy the argument "route servers and rpki are an uncomfortable fit." I buy the argument that fine-grained policy configuration challenges RS operation. And for sure the principle is indepdent of RPKI. In the most boring case, the decision results in "Prefer the route received from the lowest peer address." Ups, is this the IP address of the peering LAN, given by the IXP. What is specific to RPKI is proxying of security-related meta data (i.e., easier deployment of new protocols via RS). For example, in the case of policy prefer-valid-over-invalid AND there is no valid, RS would announce the (invalid) prefix to peer P. P also established private peering and receives announcement for the invalid prefix. Without deploying RPKI, this BGP speaker could benefit from RS meta data, dropping both. Cheers matthias On Sat, 14 Jan 2017, Nick Hilliard wrote: > Matthias Waehlisch wrote: > > the current discussion makes clear that documentation of > > origin-validation-signaling in IXP context is needed > > rpki is conceptually no different to any other type of signaling > mechanism: it's simply another input into the BGP decision engine > process, just like communities or meds or as-path. > > What we're losing sight of here is that it's the route server which > calculates the best path for each route using the routing decision > engine, and then sends a _single_ best path to the client. Conceptually, > it doesn't matter whether the tie-breaker on the route server is > communities, meds, as-path or rpki: the point is that the policy > decision mechanism needs to be configured on the route server itself, > because the route server is the device which is calculating the best > path. If the route server operator doesn't do this, the clients will > end up with path hiding (see 2.3.1 in rfc7947). I.e. it's nothing > specific to rpki. > > This is already extensively documented in rfc7947 and rfc7948. > > Nick > -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl From nobody Mon Jan 16 02:07:31 2017 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9976D1299B9; Mon, 16 Jan 2017 02:07:30 -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.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148456125062.22532.12814474427952712942.idtracker@ietfa.amsl.com> Date: Mon, 16 Jan 2017 02:07:30 -0800 Archived-At: Cc: sidrops@ietf.org Subject: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 10:07:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations of the IETF. Title : Signaling Prefix Origin Validation Results from a Route-Server to Peers Authors : Thomas King Daniel Kopp Aristidis Lambrianidis Arnaud Fenioux Filename : draft-ietf-sidrops-route-server-rpki-light-01.txt Pages : 6 Date : 2017-01-16 Abstract: This document defines the usage of the BGP Prefix Origin Validation State Extended Community [I-D.ietf-sidr-origin-validation-signaling] to signal prefix origin validation results from a route-server to its peers. Upon reception of prefix origin validation results peers can use this information in their local routing decision process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-route-server-rpki-light/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidrops-route-server-rpki-light-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-route-server-rpki-light-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 16 02:50:30 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D5B129452 for ; Mon, 16 Jan 2017 02:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.134 X-Spam-Level: X-Spam-Status: No, score=-5.134 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_SOFTFAIL=0.665] 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 iCMzgvrlXTwS for ; Mon, 16 Jan 2017 02:50:27 -0800 (PST) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 819EC129447 for ; Mon, 16 Jan 2017 02:50:27 -0800 (PST) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cT4rq-000BYB-6C (job@us.ntt.net); Mon, 16 Jan 2017 10:50:27 +0000 Date: Mon, 16 Jan 2017 11:50:21 +0100 From: Job Snijders To: sidrops@ietf.org Message-ID: <20170116105021.GQ1055@Vurt.local> References: <148456125062.22532.12814474427952712942.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <148456125062.22532.12814474427952712942.idtracker@ietfa.amsl.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 10:50:29 -0000 Hi, This version of the draft does not clarify why there is a difference between a Route Server signalling prefix origin validation results through the communities defined in draft-ietf-sidr-origin-validation-signaling, and any other ASN signalling those communities via an eBGP session. Right now the two documents appear in relation to each other as following: - draft-ietf-sidr-origin-validation-signaling-10.txt "define 3 communities" - draft-ietf-sidrops-route-server-rpki-light "you can attach those 3 communities to a prefix and announce them" So what is the point? Either a generalised mechanism should be defined in which the pro's and con's of outsourcing one's routing security are explicitly highlighted and applies to all networks, or a justification should be provided why a Route Server is different from any other ASN in this specific context. A small note: the draft states: "The introduction of a mechanisms described in this document does not pose a new class of attack vectors to the relationship between route- servers and peers." - however this is not true from an internal consistency point of view. Earlier on in the section this is written: "Therefore, a route-server could be misused to spread malicious prefix origin validation results." .. so which is it? For completeness sake, can the authors (or someone) provide a configuration example on any platform which implements the recommendations mentioned in section 3.4 "Error Handling at Peers"? I'd also like to note that this version still promotes an insecure mode of operation. Kind regards, Job On Mon, Jan 16, 2017 at 02:07:30AM -0800, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the SIDR Operations of the IETF. > > Title : Signaling Prefix Origin Validation Results from a Route-Server to Peers > Authors : Thomas King > Daniel Kopp > Aristidis Lambrianidis > Arnaud Fenioux > Filename : draft-ietf-sidrops-route-server-rpki-light-01.txt > Pages : 6 > Date : 2017-01-16 > > Abstract: > This document defines the usage of the BGP Prefix Origin Validation > State Extended Community [I-D.ietf-sidr-origin-validation-signaling] > to signal prefix origin validation results from a route-server to its > peers. Upon reception of prefix origin validation results peers can > use this information in their local routing decision process. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-route-server-rpki-light/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidrops-route-server-rpki-light-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-route-server-rpki-light-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Mon Jan 16 07:38:58 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BCA127076; Mon, 16 Jan 2017 04:45:40 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 jKQTVwCiL3jW; Mon, 16 Jan 2017 04:45:38 -0800 (PST) Received: from mail.i3d.net (mail.i3d.nl [213.163.77.240]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59C481294C0; Mon, 16 Jan 2017 04:42:20 -0800 (PST) X-Footer: aTNkLm5s Received: from localhost ([127.0.0.1]) by mail.i3d.net with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)); Mon, 16 Jan 2017 13:42:07 +0100 To: Matthias Waehlisch , Nick Hilliard References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> <58795A0B.6000009@foobar.org> <587A03CF.3010001@foobar.org> <587A9DE9.1000608@foobar.org> From: "i3D.net - Martijn Schmidt" Organization: i3D.net Message-ID: <85dbabda-3381-84fe-8ee2-961ce381a204@i3d.net> Date: Mon, 16 Jan 2017 13:42:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Mon, 16 Jan 2017 07:38:57 -0800 Cc: sidrops@ietf.org, GMO Crops , job@ntt.net Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 12:45:40 -0000 Hi all, Invalid is invalid: it means that someone is hijacking the prefix, because the owner of the resource is telling us through RPKI that the route should be originated by a different ASN. If your BGP implementation is able to detect that it should not propagate the hijacked route. If your BGP implementation is not able to understand RPKI (hi Brocade), then it would be nice to receive at least some form of protection via the route-server if you choose to use it. The argument that it should just be another parameter for the best path election on the route-server is weak at best, many networks wouldn't advertise their valid prefix with correct origin to that specific route-server - or not to any route-server at all. And that'd automatically mean that the invalid prefix is going to be propagated by the route-server.. which is undesirable. Best regards, Martijn Schmidt On 01/16/2017 12:03 AM, Matthias Waehlisch wrote: > I don't know if we are losing sight. The argument that RS is doing best > path selection was stated several times. > > However, I still don't buy the argument "route servers and rpki are an > uncomfortable fit." > > I buy the argument that fine-grained policy configuration challenges RS > operation. And for sure the principle is indepdent of RPKI. In the most > boring case, the decision results in "Prefer the route received from the > lowest peer address." Ups, is this the IP address of the peering LAN, > given by the IXP. > > What is specific to RPKI is proxying of security-related meta data > (i.e., easier deployment of new protocols via RS). > > For example, in the case of policy prefer-valid-over-invalid AND there > is no valid, RS would announce the (invalid) prefix to peer P. P also > established private peering and receives announcement for the invalid > prefix. Without deploying RPKI, this BGP speaker could benefit from RS > meta data, dropping both. > > > > Cheers > matthias > > On Sat, 14 Jan 2017, Nick Hilliard wrote: > >> Matthias Waehlisch wrote: >>> the current discussion makes clear that documentation of >>> origin-validation-signaling in IXP context is needed >> rpki is conceptually no different to any other type of signaling >> mechanism: it's simply another input into the BGP decision engine >> process, just like communities or meds or as-path. >> >> What we're losing sight of here is that it's the route server which >> calculates the best path for each route using the routing decision >> engine, and then sends a _single_ best path to the client. Conceptually, >> it doesn't matter whether the tie-breaker on the route server is >> communities, meds, as-path or rpki: the point is that the policy >> decision mechanism needs to be configured on the route server itself, >> because the route server is the device which is calculating the best >> path. If the route server operator doesn't do this, the clients will >> end up with path hiding (see 2.3.1 in rfc7947). I.e. it's nothing >> specific to rpki. >> >> This is already extensively documented in rfc7947 and rfc7948. >> >> Nick >> > From nobody Mon Jan 16 15:10:51 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AFE12986A; Mon, 16 Jan 2017 15:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] 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 f4c_DPrqv5hn; Mon, 16 Jan 2017 15:10:45 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 2AE38129867; Mon, 16 Jan 2017 15:10:45 -0800 (PST) Received: from mb-3.local ([IPv6:2601:647:4201:9e61:28fe:64ab:9f0b:9580]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v0GNAhdE006852 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 16 Jan 2017 23:10:43 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:9e61:28fe:64ab:9f0b:9580] claimed to be mb-3.local To: Marco Marzetti References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> <20a8eefe-06e5-e1c9-04f8-3c4a66bc38f1@bogus.com> <44b83365-8ada-4e35-e485-885caa150f44@bogus.com> From: joel jaeggli Message-ID: <329500bc-d283-bf93-d6a6-79a0dae6e284@bogus.com> Date: Mon, 16 Jan 2017 15:10:42 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Thunderbird/50.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mHdHG0FtvRQE6V1Copl7METbAGuJ7gK0W" Archived-At: Cc: Randy Bush , sidrops@ietf.org, GMO Crops , Job Snijders Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 23:10:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mHdHG0FtvRQE6V1Copl7METbAGuJ7gK0W Content-Type: multipart/mixed; boundary="DoffbouD6bPxRHwwHITbmkLXk4dPkAQWR"; protected-headers="v1" From: joel jaeggli To: Marco Marzetti Cc: Randy Bush , sidrops@ietf.org, GMO Crops , Job Snijders Message-ID: <329500bc-d283-bf93-d6a6-79a0dae6e284@bogus.com> Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> <20a8eefe-06e5-e1c9-04f8-3c4a66bc38f1@bogus.com> <44b83365-8ada-4e35-e485-885caa150f44@bogus.com> In-Reply-To: --DoffbouD6bPxRHwwHITbmkLXk4dPkAQWR Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 1/15/17 6:35 AM, Marco Marzetti wrote: > On Sat, Jan 14, 2017 at 9:10 PM, joel jaeggli wrote:= >> On 1/14/17 3:58 AM, Marco Marzetti wrote: >>> Joel, >>> >>> So you don't want your upstreams to honor RPKI just because they're >>> 3rd parties between you and the other end? >> >> An ixp route-server is not a transit provider, all of the nexthops >> exposed are in fact peers. So no I do not consider such a device an >> "upstream" it exists to service the policy needs of the peers on the >> fabric rather than that of the exchange operator. >> >=20 > You can easily do the same in transit providers by disabling next-hop-s= elf. Nope, The router expressing nexthop self retains the available nexthops. Under no circumstance is the router-server in the forwarding path, were it, the route-server would be an upstream. >=20 >> I would expect that a ixp route server that had a state policy of >> validating rpki would not propagate invalid routes. >> >>> In the context of IXPs: instead of peering with the RS you should >>> setup direct sessions with your partners if you really want to do >>> prefix/path validation by yourself. Consider the case where the invalid route masks an valid but longer path from being advertised via the route server as the best path. in that case the validating route-server is facilitating a prefix hijacking which it would not have, had it discarded the route. You might argue that this is no worse than not validating, however I think that is a somewhat dubious point given that the rib on the route-server would show otherwise. >> No, I setup bilateral peering arrangements because they actually load >> balance to my multiple ports, because the loci of control is >> unambiguous, because it facilitates greatly build per session prefix >> filters, and because they converge the control and forwarding path, >> which has a tendency to fail much more gracefully in the face of l2 >> failures in distributed exchange fabric designs then does the route-se= rver. >> >=20 > Aren't we saying the same thing? > Bilateral peering brings more control over what you send and receive. we have a similar concurrence respecting the advantages. We appear to differ on whether the route server offering a feature or not confers a similar outcome. > I just take an additional step and say that RPKI should be part of the > default decision process of RSs To confer the advantage you need to not allow invalid routes into your best path selection processing. > Regards. >=20 >>> Regards >>> >>> >>> On Fri, Jan 13, 2017 at 11:28 PM, joel jaeggli wro= te: >>>> On 1/13/17 1:54 PM, Marco Marzetti wrote: >>>>> >>>>> Every time one suggests a change related to the IXPs world we spend= >>>>> days arguing if it affects the neutrality and how. >>>>> Do we really need that? >>>>> >>>>> >>>>> Anyway, i can't see why IXPs can blackhole traffic (if the destinat= ion >>>>> requests it), but cannot do the same with prefixes. >>>>> After all if a prefix is invalid the owner requested it to be verif= ied >>>>> by the other parties. >>>> In general the consequences for IX operator that either allows it >>>> customers to attack each other over the exchange route-server or doe= s so >>>> itself seems severe. Loss of confidence in the disposition of one's = own >>>> routes seems like immediate grounds for depeering. If the routes rem= ain >>>> afterwards with the short as path; the operator is engaged in prefix= >>>> hijakcing. >>>> >>>> I personally find it dubious that I would choose to honor a third >>>> parties efforts at origin validation if I did not myself validate th= em >>>> but a signal from the exchange that it did validate the origin or th= at >>>> there an invalid roa floating around is at a minimum very interestin= g. >>>>> I suggest to default to drop and, if possible, to switch to announc= e >>>>> with community if the peer requests it (for instance someone may wa= nt >>>>> to collect invalid routes for analysis). >>>>> >>>>> >>>>> On Fri, Jan 13, 2017 at 10:20 PM, Randy Bush wrote:= >>>>>>> Adding grow@ietf.org for reality check. >>>>>> no comment :) >>>>>> >>>>>> when you choose to use a route server [0], you have out-sourced mu= ch of >>>>>> your policy and operational responsibilities. seems to me that wh= ether >>>>>> this includes security decisions is a contract between the user an= d the >>>>>> route server. >>>>>> >>>>>> so i might tell the server to drop invalids. if i do not take tha= t >>>>>> (configurable, i presume) option, having the server mark them seem= s >>>>>> helpful. >>>>>> >>>>>> randy >>>>>> >>>>>> -- >>>>>> >>>>>> 0 - i suspect none of job, carlos, or i do. so this is the expert= s >>>>>> telling other people what they should do. :) >>>>>> >>>>>> _______________________________________________ >>>>>> GROW mailing list >>>>>> GROW@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/grow >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> >=20 >=20 >=20 --DoffbouD6bPxRHwwHITbmkLXk4dPkAQWR-- --mHdHG0FtvRQE6V1Copl7METbAGuJ7gK0W Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlh9UvIACgkQ8AA1q7Z/VrL3UQCfcW6jdovU5VbM5u4+O3TFiouO V7sAn0TC20Ce/w9XllTaDnBcUsqdOsWI =X5vm -----END PGP SIGNATURE----- --mHdHG0FtvRQE6V1Copl7METbAGuJ7gK0W-- From nobody Tue Jan 17 06:05:35 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D7312946D for ; Tue, 17 Jan 2017 06:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lamehost-it.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLVIIsQtMEzL for ; Tue, 17 Jan 2017 06:05:22 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 7FE2C129461 for ; Tue, 17 Jan 2017 06:05:22 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id y9so103681789uae.2 for ; Tue, 17 Jan 2017 06:05:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lamehost-it.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cdxlUU3n+m7HuoFnDvl9Z65rN962vG8ZW+8fV5gy7Bs=; b=CvmY+Dj7497jnMB58hZ5Jnn4SmjdFtxC7V/+wip+y/OUAMBR8qYmsKXq9MEbctBSW7 NHSsBKrPl7BJNcQxBQpmvyfCklwvqbgxSqWgGLRIEuwFZ9mDK0HarHhr9WGzIfA9OdZ6 NWRvBXb/9dSEc/zQffUdWpFCcNjzVhXSUqgT2QGVjdr1yVIuqNPI0u7deHzOJkZJ6r8D dHmKBwXWy9BCQhuP3QN689uV1j9Xmu0+VnTui+DyLnREWNIjjfCKGuYrxTsdq4cbARAu p/1XnBCbqTVG+5J5DhX6JY/bXePqwayzB1KnU8q3oJmsg2/XlTixotOj+fXZPS+SwuEQ GRqg== 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=cdxlUU3n+m7HuoFnDvl9Z65rN962vG8ZW+8fV5gy7Bs=; b=YpxaqObfA/1zN69thNxd5f7bJbFWmonAHCJ6e2r4UBfpBi1+ZASCzDpiGUWnnxQ1qZ +Fj/4yimXWAs9X0Pf4vPj2Rkw9AFbESaPB8n1kn+qPKA7KADj/veS/g24nm+1hRX+HaP FL4BuXGSZFTh3cC4ws2nH5m3iAI1ns4YTcJm63vQotU1Dwt+zEtChUYe+Hwrr27u8CaP qxOE8BUNE+V8VJLrP93jrm17I8VKxQIdFB83w35wHfXkcdh68BPrjO4ZEnOqWt2ICjmc f2utkdQPwutB/oSiSkANOUojrMUcvm+OxBmcKeNz+2m1h2rTMF9r4FGtRS13jPAeQl74 jp3w== X-Gm-Message-State: AIkVDXJZxXweFxn5l8FLLtpxNekmV+Mlacx2hE2JC/gmf7zJej465/bRo6uwB+/CgnEq6b9drKdlLhVBmEKDfA== X-Received: by 10.176.76.154 with SMTP id y26mr40949uaf.41.1484661921116; Tue, 17 Jan 2017 06:05:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.214 with HTTP; Tue, 17 Jan 2017 06:05:20 -0800 (PST) X-Originating-IP: [95.252.41.226] In-Reply-To: <329500bc-d283-bf93-d6a6-79a0dae6e284@bogus.com> References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> <20a8eefe-06e5-e1c9-04f8-3c4a66bc38f1@bogus.com> <44b83365-8ada-4e35-e485-885caa150f44@bogus.com> <329500bc-d283-bf93-d6a6-79a0dae6e284@bogus.com> From: Marco Marzetti Date: Tue, 17 Jan 2017 15:05:20 +0100 Message-ID: To: joel jaeggli Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Randy Bush , sidrops@ietf.org, GMO Crops , Job Snijders Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 14:05:31 -0000 On Tue, Jan 17, 2017 at 12:10 AM, joel jaeggli wrote: > On 1/15/17 6:35 AM, Marco Marzetti wrote: >> On Sat, Jan 14, 2017 at 9:10 PM, joel jaeggli wrote: >>> On 1/14/17 3:58 AM, Marco Marzetti wrote: >>>> Joel, >>>> >>>> So you don't want your upstreams to honor RPKI just because they're >>>> 3rd parties between you and the other end? >>> >>> An ixp route-server is not a transit provider, all of the nexthops >>> exposed are in fact peers. So no I do not consider such a device an >>> "upstream" it exists to service the policy needs of the peers on the >>> fabric rather than that of the exchange operator. >>> >> >> You can easily do the same in transit providers by disabling next-hop-self. > > Nope, The router expressing nexthop self retains the available nexthops. > Under no circumstance is the router-server in the forwarding path, were > it, the route-server would be an upstream. > That;s correct. But is the specific device really relevant? I mean: you send your traffic to another network's forwarding plane. Do you really care about the role of the devices your packets pass through? >> >>> I would expect that a ixp route server that had a state policy of >>> validating rpki would not propagate invalid routes. >>> >>>> In the context of IXPs: instead of peering with the RS you should >>>> setup direct sessions with your partners if you really want to do >>>> prefix/path validation by yourself. > > Consider the case where the invalid route masks an valid but longer path > from being advertised via the route server as the best path. in that > case the validating route-server is facilitating a prefix hijacking > which it would not have, had it discarded the route. You might argue > that this is no worse than not validating, however I think that is a > somewhat dubious point given that the rib on the route-server would show > otherwise. > I argue that the same could happen with transit and we would consider it legit. Why? >>> No, I setup bilateral peering arrangements because they actually load >>> balance to my multiple ports, because the loci of control is >>> unambiguous, because it facilitates greatly build per session prefix >>> filters, and because they converge the control and forwarding path, >>> which has a tendency to fail much more gracefully in the face of l2 >>> failures in distributed exchange fabric designs then does the route-server. >>> >> >> Aren't we saying the same thing? >> Bilateral peering brings more control over what you send and receive. > > we have a similar concurrence respecting the advantages. We appear to > differ on whether the route server offering a feature or not confers a > similar outcome. > >> I just take an additional step and say that RPKI should be part of the >> default decision process of RSs > > To confer the advantage you need to not allow invalid routes into your > best path selection processing. > Again, I really do think that the same logic of transit applies here. Regards -- Marco From nobody Wed Jan 25 08:31:42 2017 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7471A129759; Tue, 24 Jan 2017 21:23:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148532178243.12581.18192108129987843053.idtracker@ietfa.amsl.com> Date: Tue, 24 Jan 2017 21:23:02 -0800 Archived-At: X-Mailman-Approved-At: Wed, 25 Jan 2017 08:31:41 -0800 Cc: sidrops-chairs@ietf.org, joelja@bogus.com, sidrops@ietf.org, morrowc@ops-netman.net Subject: [Sidrops] sidrops - New Meeting Session Request for IETF 98 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 05:23:02 -0000 A new meeting session request has just been submitted by Chris Morrow, a Chair of the sidrops working group. --------------------------------------------------------- Working Group Name: SIDR Operations Area Name: Operations and Management Area Session Requester: Chris Morrow Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: sidr opsarea opsec Second Priority: grow Special Requests: we're newbies! :) and ideally not friday, but... --------------------------------------------------------- From nobody Fri Jan 27 11:11:54 2017 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF99129712; Fri, 27 Jan 2017 11:11:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148554431289.17911.11499459986688912886.idtracker@ietfa.amsl.com> Date: Fri, 27 Jan 2017 11:11:52 -0800 Archived-At: Cc: sidrops-chairs@ietf.org, joelja@bogus.com, sidrops@ietf.org, morrowc@ops-netman.net Subject: [Sidrops] sidrops - Update to a Meeting Session Request for IETF 98 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 19:11:53 -0000 An update to a meeting session request has just been submitted by Chris Morrow, a Chair of the sidrops working group. --------------------------------------------------------- Working Group Name: SIDR Operations Area Name: Operations and Management Area Session Requester: Chris Morrow Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: opsec opsarea sidr idr Second Priority: grow Special Requests: we're newbies! :) and ideally not friday, but... ---------------------------------------------------------