Re: [Sidrops] [GROW] An alternative approach to draft-ietf-grow-route-leak-detection-mitigation

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 03 July 2019 17:20 UTC

Return-Path: <brian.peter.dickson@gmail.com>
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 085181203C3; Wed, 3 Jul 2019 10:20:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 by5uPxPDOxkD; Wed, 3 Jul 2019 10:20:10 -0700 (PDT)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 582AC1203CA; Wed, 3 Jul 2019 10:20:10 -0700 (PDT)
Received: by mail-qt1-x832.google.com with SMTP id y57so2351448qtk.4; Wed, 03 Jul 2019 10:20:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mkfFK+dPzR9gM1ZrgSCS2Jhz8CHsxU8nUkuf6XWHNko=; b=LGEQ3Ts9bLhPvcWyhBQEy8hMVGRNj360AqlP5tQ3xtxcTbX+XPFXb9jlySzL6to9Mv vQB8gIFpSrWOIwo1yTIpfB6T4cahiQ/5YWdg2lN9xG1ry/6toOy/HhxlchbJFCp8c6xB Rua+jipldNnE/DIQt7aVUkt0u2EuOtbd0TXLlRuC8Oa3A4UksvRbCps4FKSDZOeVlZJ/ i5vzBwzSUIMGZN78OxhTWvxC2pBVa6ZUJq2tJL1C+x/2Y+qwUQZJPHIzvp7UO++pdOg1 wsR6Vzagy9otPMvpO2L+cfEfIZJZq4M/xzgU/ahg1zIlAGyXLbsquPy0D+8VzC7JDFiG vHiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mkfFK+dPzR9gM1ZrgSCS2Jhz8CHsxU8nUkuf6XWHNko=; b=WsJ9DbB3XX18VVX9K8ES2fpmuDVyRtSKX6VBiGxzeTSh+9zHxN5qQTegKkWM7/1DWu civhJYV2eHnHJiaPQBONM2jj3Vxl1OMFdJJ/fFjqSt7oHnQ1FLZAOwdw+5lOpKV93Huy dwI82IB87CKe4432pjTTBar6F9QJIMDKCqzHpC6hPul9BD0K98TCrWBSa38QaUdjaYOx TgWJxPe1g7zmfkOdrY8Z4yGZjfy3DvBHOeCHNewZnyWeMI3eLRNW8bw3wnQyN37ZGELY vb5RQyMjkQ2/xdE11wSbiiBcnOT9x2XyLcKn5bJb8Kafitlc/wfF7LJknC0ZxJA0WL8h FKGw==
X-Gm-Message-State: APjAAAVcC6sF66Huc5ZrcAins5KlKqWS0mFm6+elTeellw0yQdaXqZVh UB3UAF67SNB215LmD+LPECPYt/luirT7Llv8/UwnNQ==
X-Google-Smtp-Source: APXvYqxJ3BqWGnjbsmHhxM4uXUes553PYW4lbQwlvT2Q2MeDUhrI85D5SEBW+SDk3UAv4wxXgUZu37temV5a3var4uw=
X-Received: by 2002:ac8:30a4:: with SMTP id v33mr32274192qta.249.1562174409498; Wed, 03 Jul 2019 10:20:09 -0700 (PDT)
MIME-Version: 1.0
References: <20190528162707.GD29921@hanna.meerval.net> <CAH1iCip6YmGri9Eq5YvHqs8bqooNMYcY_fPYGQ4v5epcc9oV_w@mail.gmail.com> <b8d27bb4-32a1-281e-7361-a58da8a28dc7@foobar.org> <CAEGSd=CMhjpFramk_oNjO9g2YTmXvvntrjwBjXtc8D=EUTpBbw@mail.gmail.com> <465695D1-51CD-49A6-9126-A7125E12062F@muada.com>
In-Reply-To: <465695D1-51CD-49A6-9126-A7125E12062F@muada.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Wed, 03 Jul 2019 10:19:58 -0700
Message-ID: <CAH1iCipBQsOGhxC2nEemm3cEXjToQYQw0UvP1UkQ18bM=7BDPg@mail.gmail.com>
To: Iljitsch van Beijnum <iljitsch=40muada.com@dmarc.ietf.org>
Cc: grow@ietf.org, sidrops@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c165f1058cca128b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/H9I4fMHuTRrjKkpVNpQdDOW1p0g>
Subject: Re: [Sidrops] [GROW] An alternative approach to draft-ietf-grow-route-leak-detection-mitigation
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2019 17:20:13 -0000

Hi, Iljitch,

The document is being revised by the authors.
The rewrite of any DO will be going away as part of that, as will L.
The end result will be that the Large communities (for RLP) will be a
complete list of all DO ASNs (i.e. as appropriate to the topology wrt
transit relationships), and nothing else new.
This makes it simple, reliable, deployable, and scalable, and allows
non-adjacent ASNs to identify/stop leaks (even if an intermediate ASN
deliberately allows the leak to pass, for whatever reason.)
(BTW: You should only ever receive DO-marked prefixes from upstream transit
providers, or from a peer where the peer ASN is the only DO=N value.)

Putting a first entry for blocking leaks at the top of route-maps won't
interfere with any other route-map mechanics.
If a route-map didn't previously exist, it will need to but consist only of
the block.
Route-maps for blocking will only need to be modified or created on
customer and peer facing connections.
Transit connections won't have the need or ability to detect leaks; this is
a trade-off on simplicity, reliability, and scalability.

Brian

On Tue, Jul 2, 2019 at 3:22 AM Iljitsch van Beijnum <iljitsch=
40muada.com@dmarc.ietf.org> wrote:

> Hi all,
>
> I was made aware of this draft in sidrops, and wrote there that I don't
> think it'll work because the AS in DO is overwritten with _last_ AS that
> propagates a route over peering rather than the _first_ (origin) AS. Maybe
> with the L thing everything will still work, but now that I see here that
> the point is to make it work using existing mechanisms, I don't see how
> that can happen. The community filters and route maps to make it all work
> would be way too complex.
>
> Also, if you _really_ want to deploy tomorrow, don't use large communities
> or extended communities, because those aren't implemented widely enough:
> use regular communities.
>
> But it all comes back to this: if you see a DO, how do you know it's one
> from multiple hops away that indicates a leak, rather than one from the
> neighboring AS that is not problematic?
>
> My conclusion: this can't work and be deployed realistically with any type
> of communities.
>
> But you know where you can stick information that will be linked to a
> specific place in the AS path?
>
> In the AS path.
>
> What if we prepend all prefixes we announce to a peer with a 1, and
> prepend all prefixes that we receive from a peer wit a 2.
>
> So if there's a 1 or a 2 more than one hop beyond our peer AS, we have a
> leak.
>
> Adding a provider - customer indicator is left as an exercise for the
> reader.
>
> The only downside that I see is that with partial deployment, certain
> paths will be longer while others remain the same length for now, which
> will have impact on traffic engineering.
>
> Iljitsch
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>