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

Luuk Hendriks <luuk@nlnetlabs.nl> Thu, 09 January 2020 11:46 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 9AA4E12011E for <sidrops@ietfa.amsl.com>; Thu, 9 Jan 2020 03:46:12 -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 NY6XayoCKRgl for <sidrops@ietfa.amsl.com>; Thu, 9 Jan 2020 03:46:11 -0800 (PST)
Received: from dicht.nlnetlabs.nl (open.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 38B27120818 for <sidrops@ietf.org>; Thu, 9 Jan 2020 03:46:11 -0800 (PST)
Received: from localhost (unknown [IPv6:2a02:58:96:c501::10]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 831171C1EA for <sidrops@ietf.org>; Thu, 9 Jan 2020 12:46:09 +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=1578570369; bh=0VQyb/vuqPpefKy9NjJTs/+VV8rPRUT0IDfsWGdGiq0=; h=Date:From:To:Subject; b=bBvG8QBbaQbeKzi8A+4WV0ISa5jSa3VqgUB2+dnuV7fWKI+zizFA4erphbUH95RN9 0uleX4Bb2F9zcXLEbDmYMMfwh2JXahfgD+IkQC7qyuUwtMW//9CVXNaKJjnSHGJZdt yjkHLW5QkswDYkjOUQJF7y3r94U1BJugDfGCkx8o=
Date: Thu, 9 Jan 2020 12:46:09 +0100
From: Luuk Hendriks <luuk@nlnetlabs.nl>
To: sidrops@ietf.org
Message-ID: <20200109114608.GA24582@corley.shackle.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/GZv8tQZ-rCp__t-EfCTA8c_ETMg>
Subject: [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: Thu, 09 Jan 2020 11:46:13 -0000

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