[Sidrops] Path validation with RPKI

Iljitsch van Beijnum <iljitsch@muada.com> Thu, 20 June 2019 10:36 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 9DCA51200FA for <sidrops@ietfa.amsl.com>; Thu, 20 Jun 2019 03:36:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=i381I1ns; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fwokiHe+
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 9cNhxmTV0_Mj for <sidrops@ietfa.amsl.com>; Thu, 20 Jun 2019 03:36:43 -0700 (PDT)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAEB7120073 for <sidrops@ietf.org>; Thu, 20 Jun 2019 03:36:42 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id E0593315 for <sidrops@ietf.org>; Thu, 20 Jun 2019 06:36:41 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 20 Jun 2019 06:36:42 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=muada.com; h= from:content-type:mime-version:subject:message-id:date:to; s= fm3; bh=x92Z7gkGfZJe/Uf91iXXIIe5ZIMhTITYscQ2brSB5a8=; b=i381I1ns CO6PkY9j1AyIJhKjBjZ3UrjvssWTONjoNHrQ/+aJWV1cOruFZTKPHcfge2k2Q1Xa Bfjsus5vHudiMmxPYCNxl5vxKNP/JmKy2M78uV9TsnXjvYXyk1+ys/oKJ0EVsIol ZodQ7sv7DQpCqZDsmsrDSpMmh9AQPUtS7+YTexjXZUJkYMPzQxL+Fu48IEi6N2bu Q2hcexsMSrVDLN3pyebFSL+2oPZHv8zBgE2X2WG0Ak7Bu7QicpYLl1SXIXbLypCj 0du5qsxkW49UWx5DhZiawWeLyhbB5hhnCfelscpkECXncIIKELAYTmlQYXRdu//G zdqvIqsvR26L1w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=x92Z7gkGfZJe/Uf91iXXIIe5ZIMhT ITYscQ2brSB5a8=; b=fwokiHe+mD73qjFXHnnx+z3goT/BHd8PfoRaslntEm2A9 BE0VBOxeDHTcomSY54S55c9ug6G2hvBXOVOvScLN6YHlohKyaVB39ZoikJWUyNQK vGlX7bCBkEz6T/85sUYu+rq6r/c/2Dm6rWoCoFvpB0TShfklhYynhQayBtJKTA2P b2b0NSk+xtQYQSckhAoOs+CYr8WdCo3OgCgh4M8A9A+q20X4BQYSSEAgALQyVYvp nvUKRXeJYMRd+tq+6Jgx2iNNb1DUcR36dWrO+N5lcYcbpNtFJOAszcGORLPyRpSm syF3qlkYNoUuns50LNP43zrex2AaIdX3IXgRd0Rrw==
X-ME-Sender: <xms:uWELXaW7paVLCF02TK99TfGbzNzLFqz4ycRFgRR5NvfNz0-hXHHv4g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrtdeggdefudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephfgtggfukfffvffosegrtdhmrehhtd dvnecuhfhrohhmpefklhhjihhtshgthhcuvhgrnhcuuegvihhjnhhumhcuoehilhhjihht shgthhesmhhurggurgdrtghomheqnecuffhomhgrihhnpehmuhgruggrrdgtohhmpdgsgh hpvgigphgvrhhtrdgtohhmpdhivghtfhdrohhrghenucfkphepkeefrdekhedrjedurdel heenucfrrghrrghmpehmrghilhhfrhhomhepihhljhhithhstghhsehmuhgruggrrdgtoh hmnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:uWELXWK66h_lXlEI1T2Xo6onaFKs9IAqdozG1PEGvr1J8z69LqK17Q> <xmx:uWELXU24PfgepuUAF4HDdCAAq7YKNiTqxgnTn_UeOK8S_0PQpDW2zg> <xmx:uWELXQ51pFS_6Ej5giwY2BcsySH7pTW6msV4a1USPjhBsJAoSPFSuw> <xmx:uWELXeLYXw_CisVfeLJkJ4wtGawlLQ5wga6Oz4Mmsuf7tHpdp3aBtw>
Received: from [192.168.178.17] (83-85-71-95.cable.dynamic.v4.ziggo.nl [83.85.71.95]) by mail.messagingengine.com (Postfix) with ESMTPA id 9F7D88005C for <sidrops@ietf.org>; Thu, 20 Jun 2019 06:36:40 -0400 (EDT)
From: Iljitsch van Beijnum <iljitsch@muada.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_89A4086C-D76E-4530-8882-1B3EC991AB43"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Message-Id: <98C70F11-2E01-4951-AECF-C7DE856841A5@muada.com>
Date: Thu, 20 Jun 2019 12:36:37 +0200
To: sidrops@ietf.org
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/BScq9dSCS1_2ddFMSHngzVPa_-g>
Subject: [Sidrops] Path validation with RPKI
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: Thu, 20 Jun 2019 10:36:46 -0000

Dear secure interdomain routing operators,

I've been away from the IETF for a while, and I'm new to this mailing list, so I'm not up to date with what's been happening here. I'm not going to let that stop me  :-)  but apologies if I retread worn out paths.

Also, I'm not sure if this work ultimately fits this wg, but I think this is the right place for an initial discussion. I'm also starting this discussion on the RIPE routing-wg list.

A few weeks ago there was a significant route leak through Safe Host and China Telecom. This keeps happening. I think we can stop these route leaks with a relatively modest change to RPKI: by combining the ASes the origin trusts and the ASes the operator of an RPKI relying party server trusts, we have a list of all the ASes that may legitimately appear in the AS path as seen from this particular vantage point.

I believe deployment will be relatively easy, as it works for the two ASes at both ends even if ASes in the middle don't participate.

So this means a change to the ROA format, a change to the RPKI-router protocol, and of course changes to the software involved.

Here is the draft:

https://datatracker.ietf.org/doc/draft-van-beijnum-sidrops-pathrpki/ <https://datatracker.ietf.org/doc/draft-van-beijnum-sidrops-pathrpki/>

There is path filter example code in the appendix to show that this part is easy.  :-)

In case you want to try this out but don't want to compile it yourself, (mostly) the same code is also running here:

http://bgpexpert.com/pathrpki/ <http://bgpexpert.com/pathrpki/>

Probably not too much new information for this group, but some background:

http://www.muada.com/2019/06-13-lets-fix-those-bgp-route-leaks.html <http://www.muada.com/2019/06-13-lets-fix-those-bgp-route-leaks.html>

Note that this is significantly different from the AS-Cones proposal. AS-Cones is a way for transit ASes to filter their peers (and maybe their customers). RPKI path validation is everyone filtering all prefixes they see, regardless of whether these prefixes come in through peering or transit. However, there is no reason the two can't be deployed side by side.

I've also read the ASPA draft, and although there are some overlap between ASPA and RPKI path validation, I'm not entirely clear on the details but they seem to be very different.

Iljitsch