Re: [Sidrops] On validating AS paths

Iljitsch van Beijnum <iljitsch@muada.com> Tue, 09 July 2019 13: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 055B7120164 for <sidrops@ietfa.amsl.com>; Tue, 9 Jul 2019 06: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=KhnQ/yjo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XXpldYbn
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 bfCsENt60nPP for <sidrops@ietfa.amsl.com>; Tue, 9 Jul 2019 06:36:41 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C5CB120157 for <sidrops@ietf.org>; Tue, 9 Jul 2019 06:36:41 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 8B06020E89; Tue, 9 Jul 2019 09:36:40 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 09 Jul 2019 09:36:40 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=muada.com; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm3; bh=nNzoqzYSdCP1dYNqXiXppoX CudSgRe+BJUW96SZl3bs=; b=KhnQ/yjos7g0xCpBwRTwUlOkL+RRARwCiqSl+8M ODlj8s/39M1C91bgFTKpceS3h8J8zMDWBsDLDw2cPG9DY4qDSDPMV+7e9mrRJd5o jVHwFL4EORbKnOSWs0nryIh6e5E8DXjeE2ZkNsPS/wVLktrzFXsycGdlGgsiw7ku 0kbtW8hwouBwTYab0642+hCSfrDrhL4yeeltLkv0LAh7remKYko0PKimB6hoZpw0 +lNbvxe8kiZ5ScKswhGhO9IkGw7JgCo5AJH0jmIJfvaFrfeqTIde9GEv6/RbDmEi CwOZOh2gKzOUu5O8mXkd/hI3bpHcuXWQmkzujCX/B0AvH4g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=nNzoqz YSdCP1dYNqXiXppoXCudSgRe+BJUW96SZl3bs=; b=XXpldYbnrS3+yhcnj62mDs R6pmSBig+umjzQC2G1xbnvO3JrW8SVXjfAxKjnSrbZCo9M5eGkbPnxUDd600m/od q7wxD5oaMvjUd4zAG+kO8kO9LlpEOJztQUKIcs/9v6atld9IYDHfB1WWXMaythob 9DvK8MGFkEJ9xVWmRO66t4mj1mlvcM+2uZ0NvXtb1fbFgU8TecrEoN49yH/1bUb7 VBIxAhr3gbiKSNUWOd0ckc/nK1o5VxmRWq2AfcqWYlFvmg2yQbyQ0FigaX+9M13a ox5auVXR65D9IlKvq1hb6kyHWc4OKL4KmpzOlhLZWDBvtJ0hf40KXuPkloxUv/dA ==
X-ME-Sender: <xms:aJgkXYjqzs_B5O_TuQXJJdvNZdHVhfTngWPFDNo1S4-ZdDqKtPy1tQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrgedvgdejtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtvdenucfhrhhomhepkfhljhhithhs tghhuchvrghnuceuvghijhhnuhhmuceoihhljhhithhstghhsehmuhgruggrrdgtohhmqe enucfkphepkeefrdekhedrjedurdelheenucfrrghrrghmpehmrghilhhfrhhomhepihhl jhhithhstghhsehmuhgruggrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:aJgkXZynWCTFrcByQ_Pjhn5gMVcnc2t0C6OfSXvuFDNcg-s6ZtVGsA> <xmx:aJgkXeykxDZlAFzdh4pILa_uTy8U16Ueplhw0jTLkFHKLIfoV6EX4w> <xmx:aJgkXbrXkBHQrskOWuiCNIuSWJ_4O88qHzRXUN2aTSPkSU0vz6Amow> <xmx:aJgkXT9CxchoJ4MexP_B-_cDVWXdlyBVp85f-ydAcaZH6-wzby_szA>
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 3B8C4380084; Tue, 9 Jul 2019 09:36:39 -0400 (EDT)
From: Iljitsch van Beijnum <iljitsch@muada.com>
Message-Id: <7ACD9CEF-21F5-47FD-9737-C020365071F4@muada.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_ABB37B29-B494-421A-8AAD-51A173353CC0"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 09 Jul 2019 15:36:36 +0200
In-Reply-To: <CAEGSd=DOC012T94zvPbMAv0pXQb6WUmv7uvRt2fxAK-9KbdSuA@mail.gmail.com>
Cc: sidrops@ietf.org
To: Alexander Azimov <a.e.azimov@gmail.com>
References: <9D1926FB-30B0-4A28-8AAF-32527BCC2F9F@muada.com> <CAEGSd=AAQqL6kbZKOEjRABd00n27VKSnMRW6W3Xyb=6y6q-ziA@mail.gmail.com> <10331B58-4353-417B-859B-8E78EF4A9F9D@muada.com> <CAEGSd=DOC012T94zvPbMAv0pXQb6WUmv7uvRt2fxAK-9KbdSuA@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/Su79J4R7EBMIzEEEagNPhTYcCpM>
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: Tue, 09 Jul 2019 13:36:45 -0000

Hi Alexander,

On 4 Jul 2019, at 23:55, Alexander Azimov <a.e.azimov@gmail.com> wrote:

> Hi, bellow my additional comments.
> Just in case - I removed from quote those parts where we are on the same side.

:-)

> a1 ^ a2 / a3 \ a4
> 
> ^/\ is not a valid path. So a3 has to register its C2P relationship with a2.
> You can't enforce it. Sibling occurs not only between parties under single administrative control.
> And you don't want to have such kind of dependency for your security configuration.

Not sure what you mean...
 
>> Maybe it can be fixed by adding a sibling flag to the c2p record, but at the moment I'm not sure about security consequences.
> 
> In the draft you mention that it's important that the customer can claim the relationship and not the provider. So I would be hesitant to have a S2S relationship record is that would either be too easy to claim (if one sibling can do it) or complex to implement (only valid when both siblings claim the relationship).

> IMO the moment we require two (or more) independent parties synchronize their configuration without automation - we lose. 

Well, yes, life without automation is hard. But then again, not everything is about making life easy.

In this case, if two ASes disagree about their relationship, then we have a problem. The only question is how the problem manifests itself. Today, too often it manifests itself as a route leak. We want to stop that.

Assuming we can't magically make the disagreeing about the relationship disappear, this means the problem must be pushed elsewhere. I.e., rather than adopt the most optimistic interpretation (allowing all prefixes allowed by _one_ AS) we should adopt a more pessimistic interpretation (only the prefixes allowed by _both_ ASes) or maybe even the most pessimistic interpretation (no prefixes allowed through unless there is agreement).

> My idea was to add one-side s2s (or c2c) to make it work. But I'm still not sure about this.

I don't think we have to do anything special. Assume AS1 and AS2, these are the possibilities:

AS1->AS2    AS2->AS1    Relationship
 claim       claim

  C2P          -        AS1 = customer, AS2 = provider
   -          C2P       AS1 = provider, AS2 = customer
   -           -        AS1 and AS2 are peers
  C2P         C2P       AS1 and AS2 are siblings

So by overclaiming a peer can upgrade to a customer relationship or a provider to a sibling relationship.

However, this is relatively harmless as the outgoing filters that a peer uses towards a peer are the same as a customer uses towards a provider, and the same for provider to customer and sibling to sibling.

So as long as each AS independently determines its relationship with other ASes and sets up filtering accordingly, C2P overclaiming is not problematic.

Of course incorrect C2P claims by one AS combined with incorrect filters by the next AS will still result in a route leak. But at least two incorrect actions by two different organizations are now required.

As a result, it's imperative that we don't use automation to propagate the relationship information from a single mistaken source.

If fact, I would go as far as to depeer any peer who registers an incorrect C2P claim.

>> And to follow up my previous email, if we have a network with malicious intent that would hijack/disaggregate prefixes + create a 'virtual peering link' between it and victim ASN, its customers will not able to detect it anyway since it will look like a valid path: '-\'.
> 
> 
> You mean a virtual sibling link? No, we certainly don't want that to be possible.

> No. Imagine I'm an attacker (or BGP optimizer) and I want to send prefixes with a malformed path to my customer.
> To bypass filters based on your proposal I just need to have a 'virtual' link with the originator.

Hm, that sounds like the logic that gave us SSL inspection.

It would be better to turn off path validation if you know there is going to be manipulation of the AS path.

> If the original path was 'a1 a2 a3 attacker customer', the path 'a1 attacker customer' will be also valid. (the path is again reversed, just to keep it same to the previous email).

Yes, in the sense that if the path "a1 a2 a3 attacker customer" is considered a valid path, then the mechanism I propose will also allow "a1 attacker customer".

However, I don't think that that makes a difference here, as surely customer hasn't registered attacker as a valid transit AS. If attacker is not a valid provider, then both paths above, the long one as well as the short one, will be rejected.

The more problematic situation is the one where a1 peers with attacker, and attacker now sends the AS path "a1 a2 a3 customer". RFC 4271 only suggests that an implementation MAY want to check whether the left most AS in the path matches the AS of the BGP neighbor.

Cisco does this by default, hence you need to configure "no bgp enforce-fist-as" on Cisco routers when you peer with a route server that doesn't add its own AS to the AS path. Juniper routers don't perform this check by default but can be configured to do so. Extreme doesn't have a configuration option for this so I assume they don't perform the check.

Of course when attacker sets up peering (or a customer relationship) with a1, it can claim to have AS a2 and thus circumvent the checks done by the routers.

> So, if we are not speaking about BGPSec-like signatures, your approach will not protect from ASPATH violation. 


Yes. When we have figured out how to validate paths, we still have some work to do to make sure those paths are not faked.

Iljitsch