Re: [Sidrops] On validating AS paths

Iljitsch van Beijnum <iljitsch@muada.com> Mon, 01 July 2019 19:34 UTC

Return-Path: <iljitsch@muada.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 75C49120177 for <sidrops@ietfa.amsl.com>; Mon, 1 Jul 2019 12:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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_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=muada.com header.b=MKCzy2wA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=zKCClqZ7
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 z77nC9cY_RPg for <sidrops@ietfa.amsl.com>; Mon, 1 Jul 2019 12:33:58 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE8E9120170 for <sidrops@ietf.org>; Mon, 1 Jul 2019 12:33:57 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 7A4EB20D12; Mon, 1 Jul 2019 15:33:54 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 01 Jul 2019 15:33:54 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=muada.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=D 2KyD/+hwd7DP32V+DnsXfK4zCItXBhrbZibjuB6ekM=; b=MKCzy2wAa2CsCEnIh tkzCioRRj8X1+gtpEm6bVhnFcJs0TKWLoWkqd4xgIVUOipDRbl4YTgDcYRmcZu2c bnRt/PglUrNkzejT1Rdva9jFZogEcXl62C1gN16Ura/xjujuv1Du02Cxp+kd9X1f r2ylDxZdvsbhc+dMpB0uUeJSB8wgiP4tg5rzbaZnZwG036+MtA/G/x3+m1G8ZCkv 1p/5lKAdCyYkb+LOzEPc12H2jFRrPuPNYKeiQedY9VPwM9B0B6mMMplNN6TBjoD/ ohaKLpsSWD8rVAPsEG4WAV/LVjksCoakQ3otZyhZ8zmCARs5ajPAm4ZRjSvIuQqt xp9Pg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=D2KyD/+hwd7DP32V+DnsXfK4zCItXBhrbZibjuB6e kM=; b=zKCClqZ7EGLFpUF62pNHe3TFM6iFJgT8hrmmSVG+o+TKwqGLpLCWr3MoK kjqrH/N++L+5oTyLEzZK2zIl7mYThBuO/W/2LqM5284S++cdR8Nw7EWaIXZHxffM k5JxUjBc+CgGkrLtohm7YI0pWYEKIxOVvLRSXCMVTO/0TSipxCt8p0Hp+4tvn6w3 VUsn95nBkbc0Ealpc8apWWgGuUZH4phWD/fpl5sSB/Pl16N8T5WzoGfuhaBtkm66 DTFukC9vl3jBc4btFJ/69PSpElSs1VTCOo1ONPAgqmu07ZfneO8DceRwWEd8Xv1v iZpK3ADjPUW+7wBHoH3qCeo55Q1Cw==
X-ME-Sender: <xms:IWAaXTSd5YazrLEkp-a5dDfMB_ohh4azUM3ql_o2pellaPmPDAaCDw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrvdeigddufeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepkfhljhhi thhstghhuchvrghnuceuvghijhhnuhhmuceoihhljhhithhstghhsehmuhgruggrrdgtoh hmqeenucffohhmrghinhepuhhsfhdrvgguuhenucfkphepkeefrdekhedrjedurdelheen ucfrrghrrghmpehmrghilhhfrhhomhepihhljhhithhstghhsehmuhgruggrrdgtohhmne cuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:IWAaXU4ogsm5STcFvu2LoOdkRrqx_iyVye2RiK4Tgw17CZ3zumB1Aw> <xmx:IWAaXQxHXPbsgoANOVfh1v7WVYJlVNVOnRg7FqYHZvSPS392KkiDNw> <xmx:IWAaXbTIXRfimPt_w2taLVhmGJGYjWFUSanKYWnSL8Ig9h061Gps0w> <xmx:ImAaXfTADNA8RA-s4ooaQPQXwV-q92sP7ckzb3n5K0pWcqiMsSIfOA>
Received: from [192.168.178.24] (83-85-71-95.cable.dynamic.v4.ziggo.nl [83.85.71.95]) by mail.messagingengine.com (Postfix) with ESMTPA id 146C3380085; Mon, 1 Jul 2019 15:33:52 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <CAL9jLab=eZ8ZkOC_-jOH1+DGcDynhUyjumqdGA677vjPN9AFEg@mail.gmail.com>
Date: Mon, 1 Jul 2019 21:33:50 +0200
Cc: Alexander Azimov <a.e.azimov@gmail.com>, SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <15E1C5FA-C511-4377-A582-3320BEBD8AAD@muada.com>
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>
To: Christopher Morrow <christopher.morrow@gmail.com>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/yAdKcN7anrKcJwHcuSTqy6iODwg>
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 19:34:01 -0000

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

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.

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.

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.  :-)  :-(  :-)

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