Re: [Sidrops] Clarification of draft-ietf-sidrops-aspa-verification-03

Luuk Hendriks <luuk@nlnetlabs.nl> Tue, 21 January 2020 08:06 UTC

Return-Path: <luuk@nlnetlabs.nl>
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 842F7120043 for <sidrops@ietfa.amsl.com>; Tue, 21 Jan 2020 00:06:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl
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 c3cfAEUZcV28 for <sidrops@ietfa.amsl.com>; Tue, 21 Jan 2020 00:05:57 -0800 (PST)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF99120071 for <sidrops@ietf.org>; Tue, 21 Jan 2020 00:05:56 -0800 (PST)
Received: from localhost (unknown [IPv6:2a02:58:96:c501::10]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 258551BF61; Tue, 21 Jan 2020 09:05:54 +0100 (CET)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl
Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=luuk@nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1579593954; bh=vWIvjAZ8n8xO+0+/BQVDZYTmU0kPKL+qirjtgzeIN3g=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=d7LCW73d4y9URd+BDfAZWLSlPog6bpNrbmPb2noRz8kAXES+SoHVdfsb620+DqP74 /mtBr9o7mq6h+K01PvkE+ytu7eLOd9Q0+U4wez7raPA4E6uEGvbwkUbRxVF1xdaxH9 eExP8x57uRXK8A48BsNDw8E6XZEE/OG5Qhkb4EGE=
Date: Tue, 21 Jan 2020 09:05:53 +0100
From: Luuk Hendriks <luuk@nlnetlabs.nl>
To: Alexander Azimov <a.e.azimov@gmail.com>
Cc: SIDR Operations WG <sidrops@ietf.org>
Message-ID: <20200121080553.GA18351@corley.shackle.nl>
References: <20200109114608.GA24582@corley.shackle.nl> <CAEGSd=D5jZzxqWCdzxwYf4G2869r059+oB7yoioWomneAXaUCw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAEGSd=D5jZzxqWCdzxwYf4G2869r059+oB7yoioWomneAXaUCw@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/demTdoR2LWDK4oKvVXXkxNEMavA>
Subject: Re: [Sidrops] Clarification of draft-ietf-sidrops-aspa-verification-03
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: Tue, 21 Jan 2020 08:06:03 -0000

Hi Alexander, all,

On Tue 14 Jan 2020, 18:04, Alexander Azimov wrote:
> In the terms of the draft AS0->AS1->AS2 is an upstream path, while AS3->AS4
> is a downstream path.
> The invalid state of (AS2, AS3) pair triggers the change of the
> 'direction', but the following downstream path verification procedure is
> not applicable to (AS3, AS2) since it can be a peering link, that's why I++
> is used.

Thanks for clarifying, it seems that we did interpret those parts of the draft
correctly then. But we are still wondering whether skipping the check after the
direction change is introducing a problem. (Again, this might be us not having
much operational experience with actual routing, so please bear with me..)


What if a bad actor, AS9, inserts itself in the path like this:

                             +-----+
                    +--------> AS2 +--------+
                    |        +--+--+        |
                 +-----+        |        +--v--+
        +------->+ AS1 |        | +----->| AS3 +--------+
        |        +-----+        | |      +--^--+        |
     +-----+                  +-v-+-+                +--v--+
     | AS0 |                  | AS9 |                | AS4 |
     +-----+                  +-----+                +-----+
                                                        |
                                                     +--v--+
                                                     | AS5 |
                                                     +-----+

No valid (AS2, AS9) ASPA is found, so we assume it is a peering link (the
I++). Direction is changed, so continuing, (AS3, AS9) and (AS4, AS3) are
checked. Now, if and only if any of these yield Invalid, the final result will
be Invalid. Otherwise, the result will be Valid or Unknown, even though there is
a malicious AS in the path. In other words, is the draft in its current revision
beneficial without (close to) 100% adoption?
Or, is this situation not considered a problem in reality due to the longer
AS_PATH and thus a lower preference anyway?


Thanks,
 luuk