Re: [Sidrops] Path validation with RPKI

Iljitsch van Beijnum <iljitsch@muada.com> Mon, 01 July 2019 14:40 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 C180F1200D8 for <sidrops@ietfa.amsl.com>; Mon, 1 Jul 2019 07:40:03 -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=qb3TsxFv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RQOw9wg2
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 FVkJ_mAzegAI for <sidrops@ietfa.amsl.com>; Mon, 1 Jul 2019 07:40:00 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E76F1200D6 for <sidrops@ietf.org>; Mon, 1 Jul 2019 07:40:00 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 81A7821FC1; Mon, 1 Jul 2019 10:39:59 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 01 Jul 2019 10:39:59 -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=N HXH64cRMtz+rQdeLIyn9C1i+/ZHC9EU7v//wq0TG+A=; b=qb3TsxFvCA4E3TqlF LvVlZflQs8HH6xiL8oVnPnVr72/osznQmw9jSJzoV2jjTPdjvi3JgftoTTh0aFTH c9sAg9yERbmrOehhPT/NnqBWTFH06DHtLl2h5hSiMhIVRrfE8/HRjezEubSLCZWK S7B8w5URbHhKOIACpxiDXJC7nQzDy0MHvBcuFq8Y9KlHnZXkL71EgotCJhSZNsBD SMsRGhObWTeJ2vKoOB5gtPB7f8ItAWFMM64oEO0ebMCb4fciBsl5vy6n3CVtDLQ1 i3zFFb9ALQ+b8zqloufqpQTgqQ3ZAEkkm8BpY7rZ+41v7f8PYUj6r5MJHsL8zfBE k951g==
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=NHXH64cRMtz+rQdeLIyn9C1i+/ZHC9EU7v//wq0TG +A=; b=RQOw9wg2HxWDWlXjG9kX2PHCgDpUeD3PPYXLVwWtcEb3RMYuJBYgS16Ow UzUEcFqGZb/wMXpUptbz1OYrzLvhxZmQJ+c44yI61wMb7DRPQKgzd75ajiYMUrZb OsMOr5w28fU7h2DPbwhWW0KDmVTQUVBhtElEqcbPfkvLLtn8pf/i/27MRutKTF89 aw+ErmfdzI8SazGtynnmZ084o574lWJZbGBTNLgEYhHLA3Vjlgj0WpHdxwpgOILR dtrWgoCvsJALBsgyNEXd2dRV4r6ljzRfHd6HwcVypdkDRlGe9tnFB+mcfRMh1oEQ sqLSmRmfM3Yz5pET63oX/qg6Inb+A==
X-ME-Sender: <xms:PhsaXWdHGQL13Bq-bURJGCa5n2W3au4sDIhcgyktoHCSsqNquTgcyQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrvdeigdektdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpefklhhjihht shgthhcuvhgrnhcuuegvihhjnhhumhcuoehilhhjihhtshgthhesmhhurggurgdrtghomh eqnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepkeefrdekhedrjedurdelheen ucfrrghrrghmpehmrghilhhfrhhomhepihhljhhithhstghhsehmuhgruggrrdgtohhmne cuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:PhsaXTrNYlCKj-uyXDUxVxpg-XGiCge3MlktRnb6WQuRoD5B3Mdtlg> <xmx:PhsaXUSXhseyTCrkhVIOoEqbVq2voaMUwblDy4Um03JMjXodWFH3lQ> <xmx:PhsaXXVtI794o23tfPYP51xC_gkUVOwa3WK_AV1Az7icoBSy-EoZfQ> <xmx:PxsaXQzoxMjZqZkJqjGesM-6ii3RTzheh-w3rpckHhl2vXTpVa_SIg>
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 F14C3380087; Mon, 1 Jul 2019 10:39:57 -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: <DM6PR09MB3019C087BDBE27633C6641F584FD0@DM6PR09MB3019.namprd09.prod.outlook.com>
Date: Mon, 1 Jul 2019 16:39:55 +0200
Cc: "sidrops@ietf.org" <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E8CEC9C2-8C7C-4AAA-B307-97F7D77C3EAA@muada.com>
References: <DM6PR09MB3019C087BDBE27633C6641F584FD0@DM6PR09MB3019.namprd09.prod.outlook.com>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram=40nist.gov@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/Bs15BBbTiG8pGhaRZJI_BWhsM24>
Subject: Re: [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: Mon, 01 Jul 2019 14:40:04 -0000

Hi Kotikalapudi,

On 28 Jun 2019, at 00:53, Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram=40nist.gov@dmarc.ietf.org> wrote:

> Just in case you are not aware, there is another effort in the GROW WG 
> for route leaks solution:
> https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-00  

Indeed, I wasn't aware of this one. Any particular reason these efforts are split between sidrops and grow? And are idr and/or sidr also in some way involved?

The ASPA draft and my draft assume out of band information to validate (parts of) the AS path. The other approach is convey the necessary information in band, and as I was reading this draft I thought this was a good way to do it. Obviously there are limitations to in band, most notably, the ability of a malicious AS to manipulate any in band information in the absense of cryptographic protections like the ones BGPsec offer.

So basically, using the notation I invented last week, RLDM conveys a ^ or / somewhere in the path (assuming origin on the right direction). And as the validating AS knows whether it has a ^ or \ relationship with the next AS, we can detect invalid paths like these:

^??^??
^??/??
\??^??
\??/??

(With more or fewer ? as desired.)

I think that could work well. But: I have two issues:

The first issue: this uses the large communities feature. I'm not sure how this is implemented, but with regular communities, routers must sometimes be configured to propagate them, and can be configured to _not_ propagate them. If this is the same for large communities, then the feature won't be as robust as it could be, as the community may not be propagated over eBGP sessions. And less than well meaning networks have plausible deniability "oh no we turn off large communities because of ...".

So it would be better to make this its own transitive path attribute. The BGP spec is very clear on how these need to be propagated.

Second, this is makes the whole thing not work:

   2.  Else, when propagating a route that already includes a DO (i.e.,
       was received with a DO) to a customer or lateral peer, replace
       the DO value with the local ASN.

So assume the following path:

5 4 3 2 1

With 5 being the validating AS (which would normally not show up in the AS path) and 1 being the origin AS. Now suppose the relationships are:

5 ^ 4 \ 3 ^ 2 \ 1

AS 2 includes DO=2. So if AS 5 has access to that information, it can determine that this is an invalid path. However, AS 4 replaces DO=2 with DO=4. However, now AS 5 only gets to see that the prefixes it gets from AS 4 are from peering, which is not news to AS 5. The actionable fact that AS 2 was sending the prefix in question over peering and that prefix is now leaked by AS 4 is now hidden from AS 5, so AS 5 is not in the position to take any action.

What needs to happen is that the community or attribute is ONLY added when it's not present and a prefix is sent over a ^ or / relationships, and then subsequently never touched.

> You mention, "We implement this by extending RPKI ROAs so that 
> in addition to the origin AS, they also list all possible transit ASes."
> The idea of "extended ROA" was considered during BGPsec 
> design discussions. See Section 6.5.2, list item #3 in RFC 8374:
> https://tools.ietf.org/html/rfc8374 
> The extended ROA was proposed to include the transit AS of the origin AS.
> The purpose was to make it easier for resource-constrained stub ASes 
> to participate in BGPsec without incurring the upgrade costs.

It says:

       This approach was rejected due to possible complications with the
       creation and use of a new RPKI object, namely, the extended ROA.

What would be the possible complications with creating such extended ROAs? Obviously there is some extra work, but I can't imagine any show stoppers.

> In your design, you seem to include in the ROA a sequence AS1, AS2, AS3, ... where
> AS1 is the origin AS, AS2 is transit of AS2, AS3 is transit of AS3, etc. Is that right? 

Well, sort of. Suppose AS1 is the origin and AS2 and AS3 provide transit. Then that would result in:

AS1 AS2 AS3 or:
AS1 AS3 AS2

But now suppose AS1 gets transit from AS2 and AS2 gets transit from AS3. Then you get:

AS1 AS2 AS3 but not:
AS1 AS3 AS1

So the two different transit scenarios can't be determined from the extended ROA. I don't think this is an issue because the unintended paths that would be declared valid in this case would still have to appear in a BGP AS path, which is very unlikely.

> Prefix owner may know the origin AS (AS1) and one level higher transit AS (AS2).
> But they would typically not know the transit ASes further up in the hierarchy.
> Does that pose a challenge for your design? 

I think the main challenge is not determining this information once, that seems doable. But now if there is a change in the transit providers for AS2, AS2 has to inform all of its customers and these customers have to take action.

Also, if internet exchange route servers are present in the path, then that could potentially add a large number of "transit" ASes.

In this sense, the ASPA approach works better. On the other hand, my approach gives origin ASes more options to determine their policy.

Perhaps a hybrid solution that allows origin ASes to indicate "these ASes, plus any transit ASes specified by these ASes" or "these ASes, and nothing else".

Thanks,

Iljitsch