Re: [Sidrops] On validating AS paths

Alexander Azimov <a.e.azimov@gmail.com> Thu, 04 July 2019 21:55 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 ED9731200D8 for <sidrops@ietfa.amsl.com>; Thu, 4 Jul 2019 14:55:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 OiDzdYdPbWav for <sidrops@ietfa.amsl.com>; Thu, 4 Jul 2019 14:55:35 -0700 (PDT)
Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 D873F1200C1 for <sidrops@ietf.org>; Thu, 4 Jul 2019 14:55:34 -0700 (PDT)
Received: by mail-ot1-x32c.google.com with SMTP id l15so7137777otn.9 for <sidrops@ietf.org>; Thu, 04 Jul 2019 14:55:34 -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=VLFYucnfIBzSrnqpVuuNWuK9+uemyvgIRSGAdsCBh1I=; b=iHC4tM69fOc0MlmoXBZoqmRt/LTsrVlssZs3VDiLto2wXx1gfXxPkul2u+P2+evtis 1D3pvB2FGBXuLxZfTDoF3oAO0GeEsUPwMryKDcrFa5DuE2fhIBOjHwCLZQJPApDwD4+8 oFH7l7ONFqp0LqGLRGgkUs1Rb8qzib3HPRvAGG40wnleP8HxoTecB59Vox86eT+Y43I8 76DqZy+4Fog1z3U8J/s5oMixjGTT0F1Abmu1yPU2jGh4oag3vfPcOVWnLOsVzQEYvnZ4 qq/vMSTB31I3JybP9AWLPRegAmom9LWCadThhzldKShxUmO7vLIZywlOAweH7eWj5SoE YetA==
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=VLFYucnfIBzSrnqpVuuNWuK9+uemyvgIRSGAdsCBh1I=; b=UXotuUbpgBxOc94RAw5qB2Q8KVAbFoBXa22crM0vPwLsBDQBYE+N4LBnNOI8clgisv WF91zMIdqHGlISytcnPW+Xd/GgQOHr20cZJuU8RkUfIqf3HWb13NHeNt95pZgHVXuDPk gODylzrIkjiomJoklS83oQI2GXqYhU1hTR70CjfVEaHuu96ZTH67NGnMQ9m8gmKpo9Sf aDT8SjGzDFdyLnhY6vP8kQxrUKWo7yoq5MU6AggQsquWQhy7SiH6Z/K2gDYwVGuI+M7o ZlUOeAGRd8C1i/W0at8BNV8FRg4mdogvbj+Rl+b98bcPUPU3qBFfd1bhHu/X0JGCpKsA h5jw==
X-Gm-Message-State: APjAAAUHSxDJsqa2GrwtRLRhU4t9kBGNbgLflhVjA9eaAtLNe0FlXVIh UdV82sN8TCesqEwXOco+UCkxqeSM0fTVZj6WXs1hUnmt
X-Google-Smtp-Source: APXvYqzzodpqi7mwJu4rB5ijKFwYyRJ6xfz/6p+roqPpCoodSsB8jAFA0ie7KnbV97W5QD1Y96CoEfYFpCEx3vs4/sg=
X-Received: by 2002:a9d:28:: with SMTP id 37mr132563ota.289.1562277334107; Thu, 04 Jul 2019 14:55:34 -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>
In-Reply-To: <10331B58-4353-417B-859B-8E78EF4A9F9D@muada.com>
From: Alexander Azimov <a.e.azimov@gmail.com>
Date: Fri, 5 Jul 2019 00:55:20 +0300
Message-ID: <CAEGSd=DOC012T94zvPbMAv0pXQb6WUmv7uvRt2fxAK-9KbdSuA@mail.gmail.com>
To: Iljitsch van Beijnum <iljitsch@muada.com>
Cc: sidrops@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008a4a16058ce209ff"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/nmilPjJGYTThka1KxwxMW0v85mA>
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: Thu, 04 Jul 2019 21:55:38 -0000

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