Re: [Idr] operator inputs -- route leak solution

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 22 March 2017 22:13 UTC

Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C603127342; Wed, 22 Mar 2017 15:13:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCZ06se0aQXb; Wed, 22 Mar 2017 15:13:04 -0700 (PDT)
Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBC7A127735; Wed, 22 Mar 2017 15:13:03 -0700 (PDT)
Received: by mail-it0-x22a.google.com with SMTP id 190so31004151itm.0; Wed, 22 Mar 2017 15:13:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oUHKLFxuZRky4t5r6WW0J1XCW+fLpRqc3d2eE1QmR/Y=; b=V9zI3/OXt0h8dzmKaggNrxMdCHAD5XiTNcrf0hx9YtqjiEKcHuJbhN3RMvPOAKd8tp y5R3DvFn6RoX3CD999aix5r8p3LuvwN+emRjcDxM5HuVJOmGCQitwQ4fibgoec+EIQni 6QzkeXENXtPK/AYBiREOM3NOooSkm33b5CyoGhRxIK0q9zviYKAB4JU5RKmPCbotPEKZ +GaIIZs4eDIk8SamDrvo9TQy/YCrKujkVl8Oi1RVQhmPfFE6J8nzJ/EBhQLjXNI4FcJ3 U3bJLhOWAaPq2pK95CVdDMEhH5qiIHePlfTronraFt6wg+eHvHkdXCGH3JlwYkc7hcNc DKOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oUHKLFxuZRky4t5r6WW0J1XCW+fLpRqc3d2eE1QmR/Y=; b=XUCiWtjZdPrtlbJldMMPmbjxMxJES81XKKfFpAthYw/JyOhdtin/z5kQlPVurv8hKg 4F3Yu8kgAgvkroCSDP9aL4hiAEOvPas8nzqUUFMFutPJUjC9XDSTI1M3XE5zcAvOAhsi wJ//JmRuK9W/aGIYc1TtKFLINlQItjHlMsgXcjMN5M7Ioivovov9ieuLDW0KXuXsNLn5 9AwD8MFEByoQZpPCa14zTYsdtXrvApIsG4J/PFUDOXmr/4xWirk0YgIefh9qQmwlmQiF MFfxeX015Yvi34AdvYibAf7zhEgTYT8LGCXKyWXHzU+yZStoX+jTsR3O39ei7XEnFSy3 IEeg==
X-Gm-Message-State: AFeK/H3HxY2xPVkDHS/tX2hB4ZTAPfdnnQrQBramODZ/+x+t26wT6X82SloauUqVpUWTD16Yd7OmVWMtK8M6BQ==
X-Received: by 10.36.4.67 with SMTP id 64mr10149401itb.19.1490220783203; Wed, 22 Mar 2017 15:13:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.121.77 with HTTP; Wed, 22 Mar 2017 15:13:02 -0700 (PDT)
In-Reply-To: <20170322143302.GG2367@Space.Net>
References: <DM2PR09MB044656C168037D0BEF7A78CB843D0@DM2PR09MB0446.namprd09.prod.outlook.com> <20170321205513.GA2367@Space.Net> <CAH1iCirbAnj+Tyn0rs5Zs9-RyY=Qj2onqNh=DehEkDQtPrRSJA@mail.gmail.com> <20170322143302.GG2367@Space.Net>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Wed, 22 Mar 2017 15:13:02 -0700
Message-ID: <CAH1iCiotU8OzKLWgz=9Z7YMvbFw1apo_273fqvju3j_Mg4ss1Q@mail.gmail.com>
To: Gert Doering <gert@space.net>
Cc: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>, "grow@ietf.org" <grow@ietf.org>, "idr@ietf.org" <idr@ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>, "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" <draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org>, "sidr wg list (sidr@ietf.org)" <sidr@ietf.org>
Content-Type: multipart/alternative; boundary="001a1140ad4e6ba0a9054b59103c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/uj2-_3STAyjO0DoC4e8_Ee34mpQ>
Subject: Re: [Idr] operator inputs -- route leak solution
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Mar 2017 22:13:06 -0000

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

> Hi,
>
> On Tue, Mar 21, 2017 at 03:19:42PM -0700, Brian Dickson wrote:
> > Pre-emptive top-post in case anyone mistakes the technique proposed: This
> > will NOT be implemented via communities.
> >
> > The proposal is for a NEW optional transitive attribute.
> >
> > If any operators can answer the original question, this will be very
> > helpful. Thank you in advance to any and all operators.
> >
> > Reminder on optional+transitive logic
> > - If the attribute is not understood/implemented/enabled, the attribute
> is
> > passed unmodified.
> > - If it is understood & implemented & enabled, behavior is subject to the
> > applicable standards.
> > - Thus, optional transitives are "opt-in", by definition.
>
> It does not really matter if this is a well-known community or a new
> transitive attribute.
>
> If ISPs do not turn this *on* on their customer connections, it will not
> do anything - and given that those ISPs that *need* to turn this on are
> the ones that are not caring today, I'm still not seeing why they would
> turn this on tomorrow.
>
>
There is direct benefit to partial (even very sparse) deployment.

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

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

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

On1 - (arbitrary path) - Tn1 - (arbitrary path) - L - (arbitrary path) -
Tn2 - (arbitrary path) - On2

   - leaks in both directions pass without any tagging/blocking;
   - Path via L is preferred, because T1 and T2 prefer customer routes
   (which include L)
   - All traffic between Tn1 and Tn2 is affected (assuming L leaks the
   entire routing table)
   - In addition to latency caused by extra hops, there will likely be
   queueing-based latency, and significant loss

On1 - (arbitrary path) - Ty3 - (arbitrary path) - L - (arbitrary path) -
Ty4 - (arbitrary path) - On2

   - leaks in both directions are blocked, at Ty3 and Ty4 respectively
   - The leak is blocked despite neither On1 nor On2 activating the protocol
   - The actual path selected will be something else, possibly/probably:
      - On1 - ... - Ty3 - Ty4 - ... - On2
      - Since Ty3 and Ty4 both block the L routes (leaked) inbound, those
      routes are excluded
      - Assuming Ty3 and Ty4 peer, there will not be a better path
      respectively, modulo other peers with shorter AS paths to On1 or On2.

If both of the above paths (Tn1 - L - Tn2, and Ty3 - Ty4) are valid paths,
the following will be the case:

   - In all likelihood, there will be massive latency and packet loss, on
   the first path via L
   - The other path will not have that latency/loss
   - On1 and On2 will both be better served by
      - preferentially routing to Ty3 and Ty4 (apply better  local-pref
      inbound to Ty3 and Ty4)
      - preferentially announcing to Ty3 and Ty4 (prepend to Tn1 and Tn2)
   - On1 and On2 obtain benefit by being able route around L (the leaker)
   - Ty3 and Ty4 get benefit by having more traffic to/from their customers
      - Potential customers may choose Ty3 and Ty4 for those reasons
      - Networks who deploy on their own infrastructure gain similar
      benefits, even if they

All of the above presumes intermediate ASNs that do not implement (all of
the "arbitrary path" bits), yet there is benefit to all the named parties.

The same would be true for ASNs at Tier-2 who peer at various exchange
points, who implement; they would possibly position themselves better than
Tier-1's until any Tier-1's implement.

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

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

Brian



> So you're adding implementation complexity which will not help anything.
>
> Gert Doering
>         -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279
>