[Sidrops] Different path validation options

Iljitsch van Beijnum <iljitsch@muada.com> Tue, 09 July 2019 15:14 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 C787F120165; Tue, 9 Jul 2019 08:14:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
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=LaQmPAwg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VhM8fv5n
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6JXcjHIoxW-k; Tue, 9 Jul 2019 08:14:55 -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 4382212023C; Tue, 9 Jul 2019 08:14:54 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 47F04218BB; Tue, 9 Jul 2019 11:14:53 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute2.internal (MEProxy); Tue, 09 Jul 2019 11:14:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=muada.com; h= from:content-type:mime-version:subject:date:references:to :in-reply-to:message-id; s=fm3; bh=jrAmQzX5UfMDGLwfc6x+6fCvSMuI6 lvplfiPjuUC2HI=; b=LaQmPAwgdwzdw3NeaC4l25XRYcQTjtQBLnUSzsUEEYTFd cyRZ9UJtLGqBkJZtHmR2xJL1XaHfnVbacwvaPYXCkT7Y5O30hD7K9d0gnDFMehdI 5ae9euJJRPafl5mkEFivLH5mDuQBPKPiJrceAq7yJnTqqsnLnQ7yRSUmH2sXCOQO 2P6IXNvQ0aNJfKKLGzZf5ep7Rj7oTuedF0kLdgZEnV8DJXpKO5j+OCL2kw26VW/i 1JNLTadspztjEkwlixRiLNONyhI3enTr9hT68vC0W+Bq4CA5lQtRjqpbspgN+jxE IXCTJkLmsTRcWjSyUmLBKtknwNFDyC8PpAjszyJBA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=jrAmQz X5UfMDGLwfc6x+6fCvSMuI6lvplfiPjuUC2HI=; b=VhM8fv5nvTEAT/ZpWii0f9 TwDAOPkc2DdW2LccfuvGs2MUcL6q4MqqfyllVo0tZv8BLtZOcgu+jTX0cmMlykY/ EbOvI9ADYGzYp2XTW2uF4SyBo951/Je9v+bbKgbNhRFTPP12ZrlUPvEaoDS//KSE 0Tg9bgd5DsUd30Rp10aWKyHn39XtVDfJK8NaMhwlhYqhHxOX5nHnprPtjGqo/ibu BtDRP55vA0jme8Rpf2uXzOhblpoiMxC6wcq1li57yFEiEf3sUZx6XimFgOatg7dK epNvd/G1OKG8Rss1Kf0Wlo/Ep8Yw+jtAKwMaesBhaZaAPPTpNXKMXho7Aay47vHw ==
X-ME-Sender: <xms:bK8kXeRaaOAsFHUrR6-6_J0SPqEW3ZsxhgEC7Ubr6tYPmSUcH8ANNQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrgedvgdeltdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephfgtggfuffhfvfgjkffosegrtdhmre hhtddvnecuhfhrohhmpefklhhjihhtshgthhcuvhgrnhcuuegvihhjnhhumhcuoehilhhj ihhtshgthhesmhhurggurgdrtghomheqnecukfhppeekfedrkeehrdejuddrleehnecurf grrhgrmhepmhgrihhlfhhrohhmpehilhhjihhtshgthhesmhhurggurgdrtghomhenucev lhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:ba8kXZ6Pdms_EZ7ME37Ylak2jB12WfF-7apTEoBftOvV4md1uOw5AA> <xmx:ba8kXRbC5lopjiIhtEkzgaQHYXmSnn28zjOJkmY8jhSaGyoHIqtL2Q> <xmx:ba8kXdYEDk00kwi6vrBDmx6RkThmHur52IsfaSekdJVnJoB7qV1aDA> <xmx:ba8kXf1zV9Wvk6WZmnS08SBt26hVvpMjRWbHSU0_jZn9vPQ1wLbxBA>
Received: from [] (83-85-71-95.cable.dynamic.v4.ziggo.nl []) by mail.messagingengine.com (Postfix) with ESMTPA id 4589C380076; Tue, 9 Jul 2019 11:14:52 -0400 (EDT)
From: Iljitsch van Beijnum <iljitsch@muada.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2EBB6D47-F9BA-4C4B-88ED-E91D42B03DB4"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 9 Jul 2019 17:14:49 +0200
References: <9D1926FB-30B0-4A28-8AAF-32527BCC2F9F@muada.com>
To: sidrops@ietf.org, grow@ietf.org
In-Reply-To: <9D1926FB-30B0-4A28-8AAF-32527BCC2F9F@muada.com>
Message-Id: <EE53C3DB-326E-441C-9259-86A9A1DF4866@muada.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/1pHhe8dZVjhgDmpOaRCnrKOGZow>
Subject: [Sidrops] Different path validation options
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: Tue, 09 Jul 2019 15:14:59 -0000

There are now four drafts about AS path validation to remedy routing leaks that I'm aware of:

LDM:	draft-ietf-grow-route-leak-detection-mitigation
ASPA:	draft-ietf-sidrops-aspa-verification
ASCones:	draft-ietf-grow-rpki-as-cones
PathRPKI:	draft-van-beijnum-sidrops-pathrpki

The TL;DR on the four:


Add in-band information to BGP that signals that a peer-peer hop has been traversed to avoid having two peer-peer hops. The idea is to do this without new code, at first at least. As the checks must thus be implemented with existing policy options, those will probably be easy to implement in code on the routers later.


Register customer-to-provider (C2P) relationships with extensions to RPKI. Based on this, check the upstream and downstream parts of the AS path, making sure there are no valleyfreeness violations and that if the customer in the relationship between two ASes has registered a set of provider ASes, the upstream AS is indeed one of the registered providers. If not, then the path is considered invalid.

The hop between the upstream and downstream parts of the path may be an unregistered hop; peer relationships are not registered and in this part of the path any relationship is a valid one anyway. If there are additional unregistered relationships in the path, validation is not possible and the path is considered valid.


Register provider-to-customer (P2C) relationships with extensions to RPKI. Recursively collect this information to resolve all ASes that may be visible behind a given AS. Then do a reverse lookup in the ROA database to obtain all the prefixes that are authorized to be advertised by these ASes and generate a prefix filter that can be applied to a BGP neighbor.

Unclear what happens to prefixes that aren't included in the filter because of a missing AS-Cone (P2C record) or ROA.


The RPKI ROA format is extended to include a set of authorized transit ASes in the upstream part of the path. Authorized ASes in the downstream part of the path are known through local configuration. For each prefix, the two halves of the path are combined into a list of ASes that may appear in the AS path.

These paths are sent to routers using an extended version of the RPKI to router protocol. Routers mark a prefix as invalid if the origin AS doesn't match as usual, and if an extended list of ASes is present, if there are ASes in the BGP AS path that are not in the filter list (or appear in the wrong order).

So let's compare.

In-band vs out-of-band

LDM is the only mechanism that works in-band. In-band is inherently less effective because the same issues that create a route leak in the first place may also send incorrect in-band information.


LDM: although it was supposed to be easy to deploy, discussion has been going on for four years, and in my opinion, as per my earlier email about the draft, deployment issues haven't been solved at this time.

ASPA, ASCone and PathRPKI all require changes in the RIR RPKI front- and backends and the RPKI relying party software implementations.

ASPA: requires unspecified changes to the RPKI to router protocol to convey C2P records, and for routers to implement the validation logic. (Maybe this is not necessary, but this is my best guess at this time.) If so, that may take considerable time and subsequent updates to the filtering logic will be difficult because of the slow update cycle in routers. Lack of an "unknown" validation state with partial deployment may be problematic.

ASCone: generating router filters to be included in configurations is easy to deploy, but very clumsy. Not clear how reusing the RPKI to router protocol would work. Unclear what partial deployment would look like.

PathRPKI: changes to RPKI to router protocol necessary. However, the scope of these changes is small. Good partial deployment as each combination of origin AS and destination AS is immediately protected agains route leaks even if ASes in the middle don't implement PathRPKI.

Who is involved

LDM: transit ASes. Leaf ASes that don't peer have no actions.

ASPA: All ASes. Origin ASes and transit ASes that have transit ASes of their own register C2P records. All other ASes filter based on this, most notably ASes that peer.

ASCone: Transit ASes register P2C records, ASes that peer filter based on this. Leaf ASes that don't peer have no actions.

PathRPKI: origin AS registers authorized transit ASes. No specific actions for transit ASes. ASes in the downstream part of the path filter based on this.


LDM: relatively low, as a malicious AS could modify the in-band information.

ASCone: middle, as ASes can incorrectly claim a P2C relationship with no obvious recourse for the AS that is incorrectly labeled as a customer.

ASPA: high, as only customers claim the customer-provider relationship.

PathRPKI: a little higher, as the upstream part of the path is solely determined by the origin AS (however, at the cost of flexibility as transit relationship changes further upstream now require work by all the ASes downstream of the change)

What now?

There are some good ideas here, but it sure looks like we haven't figured out the best way to attack this problem. Publish four RFCs, throw them to the wall, see what sticks? Hopefully we can come up with a better process than that.