IETF Logo Mail Archive

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

Alexander Azimov <a.e.azimov@gmail.com> Tue, 14 January 2020 15:04 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 ED247120100 for <sidrops@ietfa.amsl.com>; Tue, 14 Jan 2020 07:04:51 -0800 (PST)
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=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 DDnMzl6whCK9 for <sidrops@ietfa.amsl.com>; Tue, 14 Jan 2020 07:04:47 -0800 (PST)
Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 0068D1200FE for <sidrops@ietf.org>; Tue, 14 Jan 2020 07:04:46 -0800 (PST)
Received: by mail-oi1-x235.google.com with SMTP id n16so12056585oie.12 for <sidrops@ietf.org>; Tue, 14 Jan 2020 07:04:46 -0800 (PST)
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=f0AeCUPVlfNwD60k9WBh3QzwEq/0X2p1VRpl3QEK9qM=; b=IrBLzfbt+M/5FnLGFlYA7hukxDqfD6MaQ1VbOxkXXw7yBfP09S0UR3iXsOlpwQA4Lo NjakYjik6IenBsDxv0SnECFvNuMAWsnIte6MMgASqLZl5a+/OofoBkQ+41ZFNwGZZu+A 7RhbW63RDtliHxQVNAsqvfFMpfhxkJFfnWEajAZ91vmNKYNMFWb7iGwXAjQ5tPENUk9f Tgtvd+Dy3GG8TExNxxymN1fPveKl/YtUwk3WTrkc88ucEpUCMCjToErGaG0y6NlXr1vM R0FYnNT7VioqWyP9Mssnu47rVLS7+rHFiTNG6q/5qm+lQPQoyrJ6d3bJLdTinI1JwRiZ EZyw==
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=f0AeCUPVlfNwD60k9WBh3QzwEq/0X2p1VRpl3QEK9qM=; b=nBHPqggoncpJFi6Xc37yuN8ZVJZ1VApNMNvkKeX4z5LoHZVzgA8NoOl3m24X6mJnFm 7rOJkrfukR/kNw16AJpdbzchECKtbyLsiUrXVrZ0n3ElP63NLetqjrOxlWL3Q7Z8IOf+ njIRm7WRb6RdiH5Mb299r6nawnJP7+1HHl6RPsZWl1D444WwrctmCTUoge5yhWaQdVfM 2idP+TypQfWaSiU57RWBO9CWNjtqfpT1sHGyaRFxk479AFcvcBjiSrBHgMnTaPbG3imX aruONrtwhAAOCVV9e03bAoWLcydFpaRabfFikL8K6251/8006hkPa62mrc4u+3W8glMW UbpQ==
X-Gm-Message-State: APjAAAV7+h78Ok3xHvU8mcScZS+FX7G+NmrcMvI98vieaMO1k/7hjnUW ZQ77X+f80lDNBbQ/HNvw60QibeVnswbh6kaIzcA=
X-Google-Smtp-Source: APXvYqyvAcmFRz+uGSLwZgbK/PsgHNdqQjHhedM5W/QIRDwMVranDQEntKVd2G6aq3DffqPQNyddTyPZhlma2uJ4KPM=
X-Received: by 2002:a05:6808:319:: with SMTP id i25mr17630530oie.128.1579014286134; Tue, 14 Jan 2020 07:04:46 -0800 (PST)
MIME-Version: 1.0
References: <20200109114608.GA24582@corley.shackle.nl>
In-Reply-To: <20200109114608.GA24582@corley.shackle.nl>
From: Alexander Azimov <a.e.azimov@gmail.com>
Date: Tue, 14 Jan 2020 18:04:34 +0300
Message-ID: <CAEGSd=D5jZzxqWCdzxwYf4G2869r059+oB7yoioWomneAXaUCw@mail.gmail.com>
To: Luuk Hendriks <luuk@nlnetlabs.nl>
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009ed3be059c1ae97c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/yriqz3c_OwH-_cKy90al7EX1llo>
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, 14 Jan 2020 15:04:52 -0000

Hi Luuk,

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.

чт, 9 янв. 2020 г. в 14:46, Luuk Hendriks <luuk@nlnetlabs.nl>:

> Hi all,
>
> Reading through draft-ietf-sidrops-aspa-verification-03 left me with
> some questions. I have not followed the entire evolution of this
> document, so apologies if I nag about things that have been discussed
> before.  Especially with regards to the actual validation steps, I (or
> rather we, there has been a lot of discussion in our office) think we
> might be missing or misinterpreting some parts, and I'd like to get on
> the same page before diving into details.
>
> With regards to the upstream/downstream and allowing one Invalid to
> occur in the 'chain' so to say, we picture it as follows:
>
>
>                              +-----+
>                     +--------> AS2 +--------+
>                     |        +-----+        |
>                  +-----+                 +--v--+
>         +------->+ AS1 |                 | AS3 +--------+
>         |        +-----+                 +--^--+        |
>      +-----+                                         +--v--+
>      | AS0 |                                         | AS4 |
>      +-----+                                         +-----+
>                                                         |
>                                                      +--v--+
>                                                      | AS5 |
>                                                      +-----+
>
>
> Say, we are AS5, receiving an announcement with AS_PATH 4 3 2 1 0 , thus
> AS0 being the originating AS. The upstream part is AS0 -> AS1 -> AS2,
> the downstream part is AS2 -> AS3 -> AS4 . (Correct?)
>
> Then looking at the diagrams in the draft, there is an I++ when this
> allowed Invalid is observed. Does that mean that the relation between
> the ASes just after the upstream/downstream point (thus, whether AS2 is
> a provider of AS3) is not checked? If so, is that on purpose, and how
> does it not break the validation chain?
>
>
> Hopefully someone can clarify whether we are on the right track of
> understanding these concepts.
>
>
> Thanks,
>  luuk
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
>


-- 
Best regards,
Alexander Azimov

v2.23.0 | Report a Bug | By Email