Re: [Sidrops] On validating AS paths

Christopher Morrow <christopher.morrow@gmail.com> Mon, 01 July 2019 21:18 UTC

Return-Path: <christopher.morrow@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 442F5120106 for <sidrops@ietfa.amsl.com>; Mon, 1 Jul 2019 14:18:51 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 ITj4YTsF0gyF for <sidrops@ietfa.amsl.com>; Mon, 1 Jul 2019 14:18:49 -0700 (PDT)
Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (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 40B1B1200E7 for <sidrops@ietf.org>; Mon, 1 Jul 2019 14:18:49 -0700 (PDT)
Received: by mail-qt1-x844.google.com with SMTP id m29so16290923qtu.1 for <sidrops@ietf.org>; Mon, 01 Jul 2019 14:18:49 -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:content-transfer-encoding; bh=X1WTb1+VmT0X8M4/BLGZ/yxIgr0e2JE5VSJy3+py4e0=; b=JKsAY5t1ipePPbpuOc4WpGs6t1fKcOje/g3n0QjqClx22XW6QiFTteV4jIWJXLnO9/ d3kcPPpGUiPqUqjlbpeeZ8Yk0WfCG95EMgc032uaGpps8u7QogeDJ0Iimhf1TwYCFeSi 0iURCPq2KQfyoujLF2CBMTGN5BoR3LBuRij0mc2MYygcGm1wVIs9v4Hv8C9ZE50Gg7gQ l1v8cl6vxswlBBqrQBoF1zJEviR/upsbnxjSBSIPBJkFdLGSIuHv3i+ep09Nv9dFBA4Y WAsy9T6/wU3Ys7hsxqASiTzSnnwtdBAhFxbXzX0mob0kcHMLwTBiqbscfRnSD8HkLLdZ YiNw==
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:content-transfer-encoding; bh=X1WTb1+VmT0X8M4/BLGZ/yxIgr0e2JE5VSJy3+py4e0=; b=A1PMn8RvfMYc2BOHYpgqfrrE3DpZbPqL44NtGZO+vI+WqEzplAYXpMiN9TRovmZWMa TEOSPoBIvPfxPtg/UEJR4qW7hjLNcMSxssE8PX9yH/Td+slr6rfknw5kihur0a6R3uFi BePCl9GzZU16kLFhYU66b/7IqLxsXotLLBJ7edOFg+RCpeh61rvHpAz83U4HJM2HbKgW wyV/pdgsTltHz4wFNyLhwMZ5j4rYZqSPC90T2n58s+9bV2763RBYJfW7EsHMRFl2P8ZV 2Vf9NPNUP1O9prpXfENZj3sbUWxiDoUHmom/Ek+jqX5LImrKURdam/Q58QoKmoxLOJvH j8ZQ==
X-Gm-Message-State: APjAAAXhMcC5bDCC/HkNRVlNb/lodsa7L7STzYo2rbdINA2ysVXjjEgM 9SIBEHpAdoj5DMx8FMejObChaRrPbP765DlWbmA=
X-Google-Smtp-Source: APXvYqzNYHpTxiz0VWt5MaCP7+b96cEidaZ7NOgaqw7ZgUZdbqTGXgagmp1X6BZ1HaX77d4NAoozLVYn+e/Wb+4AHcM=
X-Received: by 2002:ac8:2fb7:: with SMTP id l52mr21076593qta.93.1562015928118; Mon, 01 Jul 2019 14:18:48 -0700 (PDT)
MIME-Version: 1.0
References: <9D1926FB-30B0-4A28-8AAF-32527BCC2F9F@muada.com> <CAEGSd=AAQqL6kbZKOEjRABd00n27VKSnMRW6W3Xyb=6y6q-ziA@mail.gmail.com> <10331B58-4353-417B-859B-8E78EF4A9F9D@muada.com> <CAL9jLab=eZ8ZkOC_-jOH1+DGcDynhUyjumqdGA677vjPN9AFEg@mail.gmail.com> <15E1C5FA-C511-4377-A582-3320BEBD8AAD@muada.com>
In-Reply-To: <15E1C5FA-C511-4377-A582-3320BEBD8AAD@muada.com>
From: Christopher Morrow <christopher.morrow@gmail.com>
Date: Mon, 1 Jul 2019 17:18:36 -0400
Message-ID: <CAL9jLaY-DC2v3hmp63DuaRFT+7wvRMhovA_okaBpRUb8zUQuzA@mail.gmail.com>
To: Iljitsch van Beijnum <iljitsch@muada.com>
Cc: Alexander Azimov <a.e.azimov@gmail.com>, SIDR Operations WG <sidrops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/fJs7fY6xpRsbsWpcQZNHbKSHLJQ>
Subject: Re: [Sidrops] On validating AS paths
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: Mon, 01 Jul 2019 21:18:51 -0000

On Mon, Jul 1, 2019 at 3:33 PM Iljitsch van Beijnum <iljitsch@muada.com> wrote:
>
> On 1 Jul 2019, at 20:27, Christopher Morrow <christopher.morrow@gmail.com> wrote:
>
> >> Yes. Note that in my previous message I was specifically addressing validating the _entire_ path, while ASPA only concerns itself with validating the "up" part of the path, where the only valid relationships are provider-customer and sibling-sibling.
>
> > isn't this the point of 'bgpsec'? meaning: "you can do this when you
> > see bgpsec signed paths from bgp peers"
>
> Unless I'm missing something (I don't think so, but it's a complicated system so maybe I am), BGPsec gives you two things:
>
> 1. Signatures on all the hops in the path, so you can check that the BGP update did traverse those routers/ASes and no others
>
> 2. A signature from any given AS in the path on the next hop AS, so you can determine that the update was propagated as intended by each previous hop
>

yup, that's bgpsec.

> These features are orthogonal to the issue of route leaks as defined as types 1 - 4 in RFC 7908: these break the valley-freeness property that we expect to see in valid paths, but as they're accidental, they don't do anything that BGPsec doesn't like.
>

ah! yes, this is the same sort of stuff sahron goldberg,. et-al
wrangled in several papers over the last 10 or so years:
  "RPKI, SIDR, BGPSEC are nice, but you STILL have to plan to do some
prefix filtering"

(note that also danny mcpherson was an 'early adoptor' of this
premise... "Hey, this won't stop leaks, so.. like... wtf dudes?"
perhaps a tad more eloquently put by danny)

> Note that the second feature seems impressive until you realize that it's a feature of the internet that ALL BGP updates reach ALL ASes, and that the source only gets to select the next hop AS, but that any ASes after that can apply any mistaken or malicious policy that they see fit.
>

"all" -  where there isn't some policy enforcing a block/etc, or where
best-path didn't cause the route to propagate. sure.

> Of course if it turns out that some of these route leaks are NOT accidental and when we manage to stop them by validating the AS path in non-BGPsec BGP and then the culprits start creating fake AS paths to get around that validation, at that point BGPsec can fix that problem.
>
> But as it is today BGPsec is an unimplemented fix for unimplemented problems.  :-)  :-(  :-)

my guess is we don't know the shape of today's problem :( but ok.

> Once we can validate paths then BGPsec will be of additional value, but I expect that the huge overhead that it carries will never justify the benefits. If people are leaking routes maliciously, as some people have accused China Telecom of doing [*], then path validation even on unprotected paths they'd have to inject fake paths to get through the validation to keep doing that. At that point, there's really no plausible deniability anymore.
>
> [*] https://scholarcommons.usf.edu/cgi/viewcontent.cgi?article=1050&context=mca