[Sidrops] Extending RPKI-Router protocol to do more

Iljitsch van Beijnum <iljitsch@muada.com> Thu, 11 July 2019 11:57 UTC

Return-Path: <iljitsch@muada.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8EAE412010E for <sidrops@ietfa.amsl.com>; Thu, 11 Jul 2019 04:57:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=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=pJznIbAp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VjlwAJMq
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id TfUBfeQIahqF for <sidrops@ietfa.amsl.com>; Thu, 11 Jul 2019 04:57:49 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EB8E1200F5 for <sidrops@ietf.org>; Thu, 11 Jul 2019 04:57:48 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 4426E21FA9 for <sidrops@ietf.org>; Thu, 11 Jul 2019 07:57:47 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute2.internal (MEProxy); Thu, 11 Jul 2019 07:57:47 -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=VPPAKzs333VVyuadufWsQVDAIbnTLvtDUDjrNQF1bZo=; b=pJznIbAp wk3CVRtxZUOtdH2MPRJz0KwVoWupA+XUaruPvz7iNcHh+40ok8RtNqxThkepZxwQ M4FD8CnT1ZG3NdD9gv4bZSvCuXlQF03JVtIgnY+UDncJioG2aXa6Wev1/6hvMHh+ q/kjbS+Aaf0C9RL/rydQgzcvN280D/k9I+FxO6x+5LQfWjL32fHigU+31kOqMGGW H/9GqnVw3IcOOBcvUqL82obwi0pkhmtf241/vd7em6RhhFghaJdt/mGrjupyVhCu 4GDTHuETd4tkqwD0hQFCXwD+HlnTocWvHTe/aAjXZC26XWNqpqXBOT2E/kj7Pbkt 5ss7UJ9z2pM5tA==
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=VPPAKzs333VVyuadufWsQVDAIbnTL vtDUDjrNQF1bZo=; b=VjlwAJMq6vkx3z/KqCxTKRWHLZQNjzYiYlciQDMh8SnPT ntx5wGMn4092B8MGXzSOzecZ5ntqR6bebMJQ2jMgC1opxkd27iutPkgEwlhVf7T9 Ko3zCOFR8n5FoZZdSCmtJfZrX5nv4qng0y2YQpxwH4veRmq29wvceYT6ByNhC6X9 r394NE1MKlK1iOOyKFce9LUNRxVpUL3lhiEgtXVYKK8SDa7ichdNvRXP45lpb8PU 85722Siensp0f4AoDJ+NRG03kY4IPvjxyP9Kv7E+hGd6AsBgT7L7WErTVVlbxi2f ZHyi73bhCNQpJy4IuJlLHFt7/mA9t2l3UKbLv2xIQ==
X-ME-Sender: <xms:OiQnXfvYLY782nsaL7AzusGDqwHEPTh250C1G-KsN35ickWyP-6VyQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrgeekgdegkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephfgtggfukfffvffosegrtdhmrehhtd dvnecuhfhrohhmpefklhhjihhtshgthhcuvhgrnhcuuegvihhjnhhumhcuoehilhhjihht shgthhesmhhurggurgdrtghomheqnecuffhomhgrihhnpehmuhgruggrrdgtohhmnecukf hppeekfedrkeehrdejuddrleehnecurfgrrhgrmhepmhgrihhlfhhrohhmpehilhhjihht shgthhesmhhurggurgdrtghomhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:OiQnXUva_wx30Qpua3OFLptfYV678dI1AgkzwfbN5m4v2rWmMWOivA> <xmx:OiQnXdxA3m8IQxkhDCH66ahf561zhH8hLrMc-6BoCqGtspySCLsW6g> <xmx:OiQnXShPtvGdYch5z45fgNDn0YeEtbGDzWCN8EtQekF1KGNcV-hszA> <xmx:OyQnXSWKoezMyWxHL4tpfW7vPsMxSx4JA8RW9LSQ79p0Ah5geLIjhg>
Received: from [] (83-85-71-95.cable.dynamic.v4.ziggo.nl []) by mail.messagingengine.com (Postfix) with ESMTPA id 229BB380084 for <sidrops@ietf.org>; Thu, 11 Jul 2019 07:57:46 -0400 (EDT)
From: Iljitsch van Beijnum <iljitsch@muada.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5FE8F65C-043E-4D6B-B08C-86A26023E839"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <7855DABC-E278-46E6-840B-3A536C0023B2@muada.com>
Date: Thu, 11 Jul 2019 13:57:41 +0200
To: sidrops@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/WW6WK0aivnA0lYfRmvYn7zOxv8U>
Subject: [Sidrops] Extending RPKI-Router protocol to do more
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, 11 Jul 2019 11:57:52 -0000

[Posted to sidrops, grow and RIPE routing-wg]

Hi all,

A few weeks ago I wrote a draft on extending RPKI to make it possible to validate the full AS path rather than just the origin AS.

Rather than ignore other work in this area such as ASPA and AS Cones, I've decided to focus on the thing that all these efforts will benefit from: extensions to the RPKI-Router protocol so that more types of filtering become possible under the RPKI model than just origin validation as per RFC 6811.

I think the RPKI model is a powerful one: you run the software that uses complex algorithms on a small set of central boxes. This is very flexible software that can be changed quickly (often open source). Then you send filters over to the routers using very well-defined semantics, so you know exactly what the routers are going to do and the risks are minimal, with no need to keep changing the router implementations when there are new validation mechanisms.

My additions are:

- a way to filter entire AS paths (such as created by ASPA or my PathRPKI draft)
- a way to allow prefixes from a given set of ASes, which could be used to implement a system like AS Cones
- a way to deny prefixes from a given set of ASes, which could be used to react to route leaks etc on the fly

These are just examples, I'm sure there are many different things that could be done with these filter extensions.

I wrote a draft about the whole thing, but draft submissions are currently closed so read it here for now:

http://www.muada.com/drafts/draft-van-beijnum-sidrops-rpki-rtr-ext-00.txt <http://www.muada.com/drafts/draft-van-beijnum-sidrops-rpki-rtr-ext-00.txt>

I'm very interested to hear what you think.