Re: [Sidrops] On validating AS paths

Alexander Azimov <> Sun, 07 July 2019 15:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D235912009C for <>; Sun, 7 Jul 2019 08:34:46 -0700 (PDT)
X-Quarantine-ID: <KF4AeYYhW9oP>
X-Virus-Scanned: amavisd-new at
X-Amavis-Alert: BANNED, message contains text/plain,.exe
X-Spam-Flag: NO
X-Spam-Score: -1.998
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KF4AeYYhW9oP for <>; Sun, 7 Jul 2019 08:34:43 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A4265120058 for <>; Sun, 7 Jul 2019 08:34:43 -0700 (PDT)
Received: by with SMTP id d17so13720028oth.5 for <>; Sun, 07 Jul 2019 08:34:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <> <> <>
In-Reply-To: <>
From: Alexander Azimov <>
Date: Sun, 7 Jul 2019 18:34:31 +0300
Message-ID: <>
To: Iljitsch van Beijnum <>
Content-Type: multipart/alternative; boundary="00000000000007592b058d19113e"
Archived-At: <>
Subject: Re: [Sidrops] On validating AS paths
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <>om>:

> 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