Re: [Sidrops] ASPA false leak

Alexander Azimov <a.e.azimov@gmail.com> Wed, 16 October 2019 20:41 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 3E47E12022D for <sidrops@ietfa.amsl.com>; Wed, 16 Oct 2019 13:41:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=0.001] autolearn=unavailable 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 pEKNgQZCxRxU for <sidrops@ietfa.amsl.com>; Wed, 16 Oct 2019 13:41:32 -0700 (PDT)
Received: from mail-oi1-x244.google.com (mail-oi1-x244.google.com [IPv6:2607:f8b0:4864:20::244]) (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 8077312008B for <sidrops@ietf.org>; Wed, 16 Oct 2019 13:41:32 -0700 (PDT)
Received: by mail-oi1-x244.google.com with SMTP id w6so181553oie.11 for <sidrops@ietf.org>; Wed, 16 Oct 2019 13:41:32 -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=Ht6Vhsa5IwbFevh15q7fKJxAyYdYN/I4pwNTPi6ryAw=; b=uSJC7lATmBNPrvBdSQzDatACjf27bEemQLMO22oFUmH2v2UgH2b46YIVUJ8TV2fnep SgVYEtJcXWdpdt1FlPRAH4Hzmg0xlHM8Gx44iQ1zwVUjP+46suD+ghDMb+3TlY/uS3Gy M/GJfYcuz4k5dgdQPiPkmc8spd7s9Th575+/+NzLZMzFOQdqhaGBM13sFKnu9z0gawnP 9zJ32sdRnJtMxd41kPYKcc6Q2kpa5qu7nH9ptgQnSL7JLvBUuV3TFfL7Wqx3HMV2dwDI SUaFIiGI0eueHlj/qjZp+5ubNcaQNqxgJDM67YRRXYDuwwW7a5ydx2SS4sfnTAdr+Lkm sCWA==
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=Ht6Vhsa5IwbFevh15q7fKJxAyYdYN/I4pwNTPi6ryAw=; b=pl9JVygndmlxN6MP0KCAwSsNAWMDCEIy/ku7b1lxJBCrkhu+LZYc+M6i5oJBKIIOLz 93vKqi+UTKmbmg0Sm+KkQUeh7WWVvvDFKe5M8OICB5h0ktedDjt3X/Sk/zzrQNvroJ0U rXNAegq2tkO8k9XijC6PiHUK4Z+FAQFlpLV4lhxnEqCu/rRfSszh+WH6SABP6lN12SRX 4l1SWZHMFDdTajJ57jxbR3UY9yIMm6pDJzH4IWuHPBNHq3XxfOlTmvUJVALQkzznGL6t gndqR9lINV0VadoqERge8gMgkJmud7aZgzUSr9YeaV3JAgYPdo/bJ+NpLCbzxTjHj3ae rxtw==
X-Gm-Message-State: APjAAAXCg8XJx0SJnnUxDOsHpsPoM0cHBu29B1pC65Gt8bhplcHhChk7 gdw702iupAogLGjjuhnvNcbhvR9u56hhVIUF1kE=
X-Google-Smtp-Source: APXvYqylsReFUrLMLN3o+DduKiB0AeEmoNNARGiDCPYTaxy8+uqRXAor8FALh86gyVf6AVKjziHXkH/Bfgyu6RmD6yI=
X-Received: by 2002:aca:f01:: with SMTP id 1mr229941oip.32.1571258491673; Wed, 16 Oct 2019 13:41:31 -0700 (PDT)
MIME-Version: 1.0
References: <BN8PR11MB37463090DCE5AF62C9D8B9E5C0930@BN8PR11MB3746.namprd11.prod.outlook.com> <m2y2xlsbsn.wl-randy@psg.com> <AM0P190MB0756169E6093C2C101BAF4EBC0920@AM0P190MB0756.EURP190.PROD.OUTLOOK.COM> <m2wod5ry24.wl-randy@psg.com>
In-Reply-To: <m2wod5ry24.wl-randy@psg.com>
From: Alexander Azimov <a.e.azimov@gmail.com>
Date: Wed, 16 Oct 2019 23:41:17 +0300
Message-ID: <CAEGSd=AtJP+_OSua=VONnw2peNmCtd9Wgiy_wRgZTBGxW2qbRA@mail.gmail.com>
To: Randy Bush <randy@psg.com>
Cc: Ben Maddison <benm=40workonline.africa@dmarc.ietf.org>, "Jakob Heitz (jheitz)" <jheitz@cisco.com>, SIDR Operations WG <sidrops@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003f1ef005950d2078"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/1nDzLlDLM7ok1RAj-yssFXICqwg>
Subject: Re: [Sidrops] ASPA false leak
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: Wed, 16 Oct 2019 20:41:35 -0000

And another real-world scenario.

The significant number of route leaks today happens when an ISP is using
the prefix-list of their customers as the only egress filter (no ingress
filters/no communities).
In this case, just like in your scenario, it starts to leak customer's
prefixes when it gets them from providers/peers, thus spoiling TE of their
customers. More then, the customer even can't redirect traffic from such
misconfigured upstream provider even if it experiences a service
degradation.

I don't believe we should legitimize such behavior.

ср, 16 окт. 2019 г. в 09:42, Randy Bush <randy@psg.com>:

> >> Consider the topology:
> >>
> >>    AS5      AS3
> >>      \     /   \
> >>       \   /     \
> >>        AS4     AS2
> >>          \     /
> >>           \   /
> >>            AS1
> >>
> >> AS1 has providers AS2 and AS4.
> >> AS2 has provider  AS3.
> >> AS4 has providers AS3 and AS5.
> >>
> >> AS5 receives a route with AS-path (4 3 2 1).
> >> ASPA would declare that AS4 leaked the route from AS3 to AS5.
> >> However, AS4 is an authorized provider for AS1.
> >> Even though AS4 has a path to AS1, it chose to use an alternative
> >> valid path to reach AS1.
> >
> > and that alternate path sure looks a lot like a route leak.
>
> lemme try a different way
>
> the attacker A3 wishes tio siphon jelly beans from A5's traffic to A1.
> so she convinces A4 to prefer the A4 A3 A2 A1 path, which A4 then
> announces to A5 as her best path.  profit.
>
> randy
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
>


-- 
Best regards,
Alexander Azimov