Re: [Sidrops] draft-ietf-sidrops-aspa-verification-01: Handling unknowns

Alexander Azimov <> Tue, 20 August 2019 09:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A96E1120072 for <>; Tue, 20 Aug 2019 02:08:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DFdkYPvGRpYU for <>; Tue, 20 Aug 2019 02:08:53 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8D23D120024 for <>; Tue, 20 Aug 2019 02:08:53 -0700 (PDT)
Received: by with SMTP id n1so1135169oic.3 for <>; Tue, 20 Aug 2019 02:08:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UxXGHAI65mBDopu/HOSm/qKjolI2WwNGmTsgQacogPY=; b=pHUwxthXQ6buKbGUa/eGv5jukQs6QxOFOkCZF3arbf/IgUm8p+ws2tMV6iJNipODxf wXkOsjSzGH80DDD5UWeVknfBOhlwmtCYdviSXjBYJEqNuse4NU9c7OeSqe9xVoaOHiQL Sk9cweuO5FtLW4jYpCp7I3RuApAj16rTdy1ciLY2KEhF5ZYBjs0+MYwItUADQTXxMDkn vRiu4jzr6wsEZL5zXLvRpFv+ZUIMTuCpooly1AySQFoIqE7TCHRXYQuUovtAEqaaYQf8 CriJCZyablZuqwGtgOSl9c5TsdMPGm736czcHfuSIhxIQh/cOjvd2co6nXrwUw415789 QSSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UxXGHAI65mBDopu/HOSm/qKjolI2WwNGmTsgQacogPY=; b=pjxlruOZdu3QvW/vfAagYqjgANtNBf6M1CndUIWYTIk3gcetTqNNFA5tPtdUMuaUZA /MFnXTV8XsiaFVR4LM9mEqZOSil+jjANX8uUj7nefOPuDlTMP1l+3sY6UACA+4eHEEop XOeb9YfXcCxV0qW1+ouKK1/1okG0IqgQdlWfaR3LvhMe/TLLkOGrJPTwnlYapyoKq2rN qU7vkH8EkGWTRbvc6RcChzeiBXB9XDvtUAp3hUbyg5MDc1E5oDePLupnqG7uFOe2fplo Ds6aZs556wjyEXhcWUBeLpsGxrCpCO6IqGglHbrp3lwqCUy0jhYnBQKNo/dESAXzRJrP 6kHw==
X-Gm-Message-State: APjAAAUVNlOzeOCXLPoKsX/zWhWGPjbw7qzMWn24rHa3hvYnhuT2Mdad c2THnY8H/gsGm3DI+2ysPsvKzZD05icmgpA/BeM=
X-Google-Smtp-Source: APXvYqwz7Paa7XMwGbCKudRquSogwSaraBmK05RBlyqctBoko31pvlwtHnjXvEjRJ3CQvck1LNoCD9gmE///ydNNr0w=
X-Received: by 2002:aca:1a02:: with SMTP id a2mr9660696oia.32.1566292132472; Tue, 20 Aug 2019 02:08:52 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Alexander Azimov <>
Date: Tue, 20 Aug 2019 12:08:38 +0300
Message-ID: <>
To: "Jakob Heitz (jheitz)" <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="0000000000002baa74059088cee1"
Archived-At: <>
Subject: Re: [Sidrops] draft-ietf-sidrops-aspa-verification-01: Handling unknowns
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: Tue, 20 Aug 2019 09:08:56 -0000

Hi Jakob,

I'm sorry that it took so long to reply to your suggestion.

I think that explicitly state what means the absence of record (AS-A, AS-C)
is a good idea.
There are already several minor issues that were found in the draft, I will
work them through in the next couple of weeks.

сб, 27 июл. 2019 г. в 04:35, Jakob Heitz (jheitz) <>:

> The draft states:
> An ASPA attests that a Customer AS holder (CAS) has authorized a
> particular Provider AS (PAS) to propagate the Customer’s IPv4/IPv6
> announcements onward, e.g. to the Provider’s upstream providers or peers.
> I suggest to make this more precise and to add the "otherwise" condition:
> An ASPA attests that a Customer AS holder (CAS) has authorized a
> particular Provider AS (PAS) to propagate the Customer’s IPv4/IPv6
> announcements to all of the provider's neighbors. If an AS, AS-A publishes
> at least one ASPA and it lists AS-B as a provider and AS-C is connected to
> AS-A, but AS-A does not list AS-C in an ASPA, then AS-A authorizes AS-B to
> propagate the announcements of AS-A to all of AS-B's neighbor ASes and
> authorizes AS-C to propagate AS-A's announcements only to ASes that
> consider AS-C to be their provider. I.e., AS-A prohibits AS-C from
> propagating the announcements of AS-A to AS-D if AS-D does not consider
> AS-C to be provider for AS-D.
> Consequently, a chain of ASPAs can be used to verify the plausibility of
> an AS-PATH.
> Thanks,
> Jakob.
> On Jul 26, 2019, at 11:08 AM, Alexander Azimov <>
> wrote:
> I'm sorry for the last email. It was supposed to be bigger.
> пт, 26 июл. 2019 г. в 08:38, Jakob Heitz (jheitz) <>:
>> If you receive an AS-PATH of 2 ASes and neither of them make any
>> attestation,
>> then your procedure calls it valid. It could be invalid,
>> so it must be considered unknown.
> It an interesting point. When I was writing the ASPATH verification
> procedure I had in mind that we need to detect invalids. But for debugging
> purposes, it might be also useful to distinguish fully verified paths where
> all pairs are valid and those paths that represent a combination of valid
> and unknown pairs. It will also require clarification that for backward
> compatibility such unknown paths MUST be treated as valid. We should add
> this option into consideration.
> If an AS-PATH contains an AS-SET, then the segments on either side of
>> the AS-SET can still be verified. If any such segment turns out to be
>> invalid, then the whole path must be considered invalid, not unverifiable.
> I do agree and that's how both downstream path upstream path procedures
> are defined in the draft.
> As we discussed in person, we might need additional clarification in the
> beginning where {AS(I), AS(I-1)...} sequence is defined.
>> My procedure accounts for these cases and more.
>> For the cases where every AS makes an attestation, my procedure agrees
>> with yours.
> If you have ASPA(1, 2) you can't make assumptions about relations of 2.
> Otherwise, it may lead to incorrect results in the case of siblings.
> BTW, you have a copy/paste error in 5.2 Downstream paths:
>> If a route from ROUTE_AFI address family is received from a customer
>> should be:
>> If a route from ROUTE_AFI address family is received from a provider
>> Yes, you are right. Copy-paste can become tricky. Will be fixed in the
> next version.

Best regards,
Alexander Azimov