Re: [Sidrops] ASPA: Is this really a leak?

Lukas Tribus <> Wed, 16 December 2020 21:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC8B63A109F for <>; Wed, 16 Dec 2020 13:11:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Z8ysW_5I1oVC for <>; Wed, 16 Dec 2020 13:11:26 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7EE223A109C for <>; Wed, 16 Dec 2020 13:11:26 -0800 (PST)
Received: from ( [IPv6:2001:67c:2050:105:465:1:1:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 4Cx78r6TchzQl92 for <>; Wed, 16 Dec 2020 22:11:24 +0100 (CET)
X-Virus-Scanned: amavisd-new at
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=MBO0001; t=1608153084; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GhCvgms7tax/mDHA1GuAHSHy9Nnb3idzcacakT2+qUk=; b=m1lT5kAUWS+J+H6OykRJ9AcQaoSCIJlYPRSVpsC2zIYaWSWj9digSV/D8JTZFmwy3w+VIM CLcVTkc0o3v1NYqby0/yiYFRmF2TAZ10kLa8qpdQPMD2/123poAGl1Lz3o4T2a0X4+UzCb o0VcYVy93gKttAxSqDkzj2C/XDvMbu0LxtxcWw9u7/RvkHrVx2TAcKqHFvdPHiCVMX8wx3 IE+h7V0Coth2zkVHXkrZn0E2c7JCyjzASyGkCxF0jGjUDDfWZlexb2ZlPQb/NoKLOe1R4T 7dqMC+kJOJsIxB23yqASJOWbj0Qnt31dwtuShAUzvIv9Uvh0poqd2k7X+Hk4LA==
Received: from ([]) by ( []) (amavisd-new, port 10030) with ESMTP id W_hKYh7GFYCO for <>; Wed, 16 Dec 2020 22:11:22 +0100 (CET)
Received: by with SMTP id q5so3314990ilc.10 for <>; Wed, 16 Dec 2020 13:11:21 -0800 (PST)
X-Gm-Message-State: AOAM533RZCwul23u/4ERTG9jiZOwuaJ2mxFJKn0Nce2T491m9y0NEcaz 8kY1PlBzal1ZWaFOFcyIXMcRa0ad3cUGwWOnDfI=
X-Google-Smtp-Source: ABdhPJxmDmyycR83Qpi6/gCYs1wjRUJ6ubSItNWPCS9s8ST1XpypNaqeFVK/EWTcho66kDF4NZMKfwS7QEqTzg09m4k=
X-Received: by 2002:a92:ba82:: with SMTP id t2mr7459943ill.139.1608153080004; Wed, 16 Dec 2020 13:11:20 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Lukas Tribus <>
Date: Wed, 16 Dec 2020 22:11:08 +0100
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: "Jakob Heitz (jheitz)" <>
Cc: Jay Borkenhagen <>, "" <>
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Score: -2.56 / 15.00 / 15.00
X-Rspamd-Queue-Id: A33E51833
X-Rspamd-UID: 7c91b2
Archived-At: <>
Subject: Re: [Sidrops] ASPA: Is this really a leak?
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: Wed, 16 Dec 2020 21:11:28 -0000

Hello Jakob,

On Wed, 16 Dec 2020 at 20:57, Jakob Heitz (jheitz)
<> wrote:
> Jay,
> I disagree that the algorithm in ASPA rejects routes whose AS_PATHs are
> contra-indicated by the expressed wishes of the AS resource-holders,
> as communicated by the set of validated ASPA records.
> I posit that it rejects more than that.
> Suppose AS1 has providers AS2 and AS20.
> AS20 is also a provider for AS2.
> What I am proposing is that AS2 should be allowed to divert traffic
> that it received from the Internet through AS20 on its way to AS1.
> Internet --> AS2 --> AS20 --> AS1.
> The algorithm stated in ASPA prevents that.
> Nobody is breaking any laws or contracts by doing that.

I disagree. AS2 is breaking the contract which is that it won't
announce my routes to non-customers peers. The fact that we are
talking about AS1 originated routes which is a customer of both AS20
and AS2 doesn't change that.

AS20 AS1 is an as-path that AS2 must not announce to non-customers,
unless specifically authorized by AS20. AS2 doesn't get to share AS20
routes, whether the origin-as AS1 is a common customer or not.

AS20 must decide whether this is acceptable or not. Not AS2 and not AS1.

> Nobody is seeing any traffic that they are not permitted to by doing that.

I disagree. If I'm AS20 and my customer AS2 shares prefixes with
non-customers without authorization, I will order AS2 (my customer) to
stop. I don't care if those routes are AS1 originated.

What if AS2 has insufficient capacity to deal with the traffic? AS20
has SLAs with AS1, but if AS2 suddenly thinks it has to be a transit
provider for AS20->AS1, then AS20 can no longer guarantee those SLA's,
because suddenly AS2 will pick up the traffic.

What if AS1 specifically disconnects AS2 to route around temporary
technical issues in the AS2 network? Now AS2 is still involved,
despite best efforts of both AS1 and AS20 to not traverse it.

This is an unauthorized announcement (unless AS20 says otherwise), and
a nightmare with real technical and contractual consequences. If my
customer AS2 insists on doing this, actively impeding my ability to
guarantee SLA's to AS1, then I will disconnect AS2. You can bet that I
will have the legal/contractual power to do so.

> This kind of diversion happens frequently on the internet and
> ASPA should not prevent it.

It happens frequently by mistake because of the use of static prefixes
list instead of BGP communities. It also causes damage. If this basic
and common leak is not something that ASPA prevents, then I'm afraid a
lot of network operators won't even bother with ASPA.

> The big difference is that AS2 is a provider for AS1.

Your opinion is that this changes something. I'm saying it doesn't
change anything at all.

The example you provided causes a number of issues for all 3 parties
involved. Nobody wants this:

AS1 doesn't want this, because it cannot reroute around technical
problems in AS2 by disconnecting it. It is multihomed for a reason.
AS2 doesn't want this, because it would just give AS20 free transit
and overload it's own network with traffic that is not generating
revenue (but may happen erroneously due to static prefix list).
AS20 doesn't want this, because it will be unable to guarantee SLA's
to AS1 when an unauthorized transit provider is involved.

If this is something that both AS2 and AS20 agree on, then the proper
authorizations will be in place and all is good anyway.

- regards,