Re: [Sidrops] On validating AS paths

Alexander Azimov <a.e.azimov@gmail.com> Sun, 07 July 2019 15:34 UTC

Return-Path: <a.e.azimov@gmail.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 D235912009C for <sidrops@ietfa.amsl.com>; Sun, 7 Jul 2019 08:34:46 -0700 (PDT)
X-Quarantine-ID: <KF4AeYYhW9oP>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BANNED, message contains text/plain,.exe
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 KF4AeYYhW9oP for <sidrops@ietfa.amsl.com>; Sun, 7 Jul 2019 08:34:43 -0700 (PDT)
Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4265120058 for <sidrops@ietf.org>; Sun, 7 Jul 2019 08:34:43 -0700 (PDT)
Received: by mail-ot1-x333.google.com with SMTP id d17so13720028oth.5 for <sidrops@ietf.org>; Sun, 07 Jul 2019 08:34:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AEfQDSBNescFjGPtRJnpKHuNM7xX/aeP4WyZP3slxKc=; b=sEGnhtN++mojcIvdNZAick9FBBrIkEhzI2FlF0Se9JPQeyDmS8+arudfBOOGOs3Wa/ hscdU4ON1GPeQL6qhtid/RjdPRqYBQS/lY2+j/EKBcHdCOXAMCSdrukZTPckDC8Cpr90 kUXNSr2e0XyUyFYZAF+h1ekNRjDwLhTSeXprS2gGhMOTucIScZSFM7wOsrPX0ejToT0a qpdPOKwWyIRRj3LG68dpfhpepdpO3f9Op/I2SYwGh89hoQzx1AacminV4K9f4FQZ9zM4 hUxyJTwyhlVMgvawQKuANYjyCYB+li90VO6HLS72Cx1NdEiBmthun9nTbfFlrOd8BdHa VTTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AEfQDSBNescFjGPtRJnpKHuNM7xX/aeP4WyZP3slxKc=; b=T14bQqU7K7Qfcd6p8dM6ia/AadgJWtcv7ig/CZUavdHbhvBjz7zUtMRyUeeA9o76ec /PyKi2t+3tS3MkBwVWieaqPVTnBj+Dhxhi2ijuteCJIqFOE7szL6gc+saek9Caj+3X8L DVwZJBxTwCJbrAH3TcPbjknsRY3Z126DZwCCPQaW2Ba0jVXzYVtMxfJV/xW52gdtFJgx fgXZKDZhV5hTEGA9+JSv4RKX24snLYRdpLTmDVtef/1t0WVe2osHNiCiAKGS40zKhd3C HhYDGsQpiw3HVl3gEu5CiOdurIRCBG/HsY+vP6TbrwriavluhW1M2AXz+x1ehNwE4xUB pJCw==
X-Gm-Message-State: APjAAAWw7M3Es+To/3ZUR4ChJSlcxKg8PxI9IUhLDsK3s9Z4sKqctJeb 2jUKU1M2xZkOU+wvL0oGw7u2sezI7ZIO1EsR4xO+l9dj
X-Google-Smtp-Source: APXvYqwvCV7zLs63+3WCWJR5YFesNqeSrF7kiGyronhxuoIEl8dwAQzqW5zWQK6bGhmKOSSoPLzsINFfslml1ioDPnA=
X-Received: by 2002:a9d:7411:: with SMTP id n17mr9965500otk.27.1562513682945; Sun, 07 Jul 2019 08:34:42 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CAEGSd=DOC012T94zvPbMAv0pXQb6WUmv7uvRt2fxAK-9KbdSuA@mail.gmail.com>
From: Alexander Azimov <a.e.azimov@gmail.com>
Date: Sun, 7 Jul 2019 18:34:31 +0300
Message-ID: <CAEGSd=BTn2vuHrUEhHVB7UEwjhRT+j8yK8JzUXxd1kz0VDyjFA@mail.gmail.com>
To: Iljitsch van Beijnum <iljitsch@muada.com>
Cc: sidrops@ietf.org
Content-Type: multipart/alternative; boundary="00000000000007592b058d19113e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/tMfsfGE6C3SHRtLuL37W6-Q2yl8>
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: Sun, 07 Jul 2019 15:34:47 -0000

Here is a sample of pseudocode:

def verify_aspath(local_role, reverse_aspath, neigbor_asn):
>     if not len(reverse_aspath) or local_role in (customer, peer, rs,
> provider) and neigbor_asn != reverse_aspath[0]:
>         return False
>
>     if local_role in (provider, peer, rs):
>         for i in range(len(reverse_aspath)):
>             if not i or reverse_aspath[i-1] == reverse_aspath[i]:
>                 continue
>
>             if verify_pair(reverse_aspath[i-1], reverse_aspath[i]) ==
> invalid:
>                 return False
>     elif local_role in (customer, rs_client):
>         going_up = True
>         for i in range(len(reverse_aspath)):
>             if not i or reverse_aspath[i-1] == reverse_aspath[i]:
>                 continue
>
>             if going_up and verify_pair(reverse_aspath[i-1],
> reverse_aspath[i]) == invalid:
>                 going_up = False
>                 continue
>
>             if not going_up and verify_pair(reverse_aspath[i],
> reverse_aspath[i-1]) == invalid:
>                 return False
>
>     return True


It's slightly simplified (I ignored AS_SETs) but it shows that it is
possible to add route leak detection for prefixes that are received from
providers without changing ASPA profile.

пт, 5 июл. 2019 г. в 00:55, Alexander Azimov <a.e.azimov@gmail.com>;:

> 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.
>
>
>> 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.
> My idea was to add one-side s2s (or c2c) to make it work. But I'm still
> not sure about this.
>
>
>> 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.
>
> 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).
>
> So, if we are not speaking about BGPSec-like signatures, your approach
> will not protect from ASPATH violation.
> The thing it might bring is the detection of mistake route leaks that are
> received from providers. So, it can bring benefit at the state of early
> adoption.
>
> I will try to integrate into ASPA logic. I have a feeling that it can be
> done without registering siblings.
>
> --
> Best regards,
> Alexander Azimov
>


-- 
Best regards,
Alexander Azimov