Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt
Marco Marzetti <marco@lamehost.it> Sun, 15 January 2017 14:36 UTC
Return-Path: <marco@lamehost.it>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D7212957F for <grow@ietfa.amsl.com>; 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=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 h95a_SxkK62i for <grow@ietfa.amsl.com>; Sun, 15 Jan 2017 06:35:59 -0800 (PST)
Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE30A129547 for <grow@ietf.org>; Sun, 15 Jan 2017 06:35:58 -0800 (PST)
Received: by mail-ua0-x22d.google.com with SMTP id i68so66482952uad.0 for <grow@ietf.org>; 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=fdXNBqtOiCliKR0dYlsynDkbQD5icM3KYTOhtZpzA723mJ2oHeCn3BUGHWBEFE3idS aiFQ5tCHDS0g+hhlSJGiZ6KxZdJ+/sjnIFDyUr4D0XZTyNJEMOUFZt0HHBfeb+1X3ghp qaiSYmYmA5uymcZGAgnJfcn8VsufjaCxV0ZYf+cvdhHO5FVSWuk9ES9bkT2KUeuWRaRb lDSNQhbkNxs+zIDPGXt3iy/pxnWPe3whDwbJWphmB69WKXVIXpG3wfsNv+bZ/4oGkl1C blZhkOZHrgoCYUlARu8F0pmf2EVP87MIOB90RtPlwpMA3kEzX6ZyztE2hHUOMgRUU6Zv XZKg==
X-Gm-Message-State: AIkVDXIEXBLWPn7KVQpNm21ldlgie9nyKl2o7rTRivJMzdaK/54GbxqIgUxeFx1pphoiKxShwX8UsByaCTAJ3A==
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> <c55845cc-ca06-45c8-9b2e-075421d0447c@Spark> <m2lgueejxr.wl-randy@psg.com> <CAO367rX1jjOdenqgouzbTRBfeaWz+TFoUjGFJVtUr9tifwAw3g@mail.gmail.com> <20a8eefe-06e5-e1c9-04f8-3c4a66bc38f1@bogus.com> <CAO367rWdDkG7f7eF+FPj9VONsajZHYjTk7cEpWsxQKR1V9dnWw@mail.gmail.com> <44b83365-8ada-4e35-e485-885caa150f44@bogus.com>
From: Marco Marzetti <marco@lamehost.it>
Date: Sun, 15 Jan 2017 15:35:56 +0100
Message-ID: <CAO367rW7pGpK1y8EMBg7oWTx-Sz0N8EtBHqNupkhj5ECKmzCag@mail.gmail.com>
To: joel jaeggli <joelja@bogus.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/grow/4A4EkOTZ2pSe2KAnrbeCLHEnKWM>
Cc: sidrops@ietf.org, GMO Crops <grow@ietf.org>, Job Snijders <job@ntt.net>
Subject: Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/grow/>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Jan 2017 14:36:02 -0000
On Sat, Jan 14, 2017 at 9:10 PM, joel jaeggli <joelja@bogus.com> 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 <joelja@bogus.com> wrote: >>> On 1/13/17 1:54 PM, Marco Marzetti 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 >>>> 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 <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-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
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… job
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Randy Bush
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Marco Marzetti
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Christopher Morrow
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Marco Marzetti
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… joel jaeggli
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Nick Hilliard
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Christopher Morrow
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Job Snijders
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… joel jaeggli
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Jakob Heitz (jheitz)
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Randy Bush
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Jakob Heitz (jheitz)
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Matthias Waehlisch
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Nick Hilliard
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Nick Hilliard
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Marco Marzetti
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Marco Marzetti
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Nick Hilliard
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Matthias Waehlisch
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Marco Marzetti
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Christopher Morrow
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… joel jaeggli
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Nick Hilliard
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Randy Bush
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Marco Marzetti
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Marco Marzetti
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Job Snijders
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Marco Marzetti
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Matthias Waehlisch
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… i3D.net - Martijn Schmidt
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… joel jaeggli
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Marco Marzetti