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

Alexander Azimov <a.e.azimov@gmail.com> Tue, 20 August 2019 09:08 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 A96E1120072 for <sidrops@ietfa.amsl.com>; Tue, 20 Aug 2019 02:08:55 -0700 (PDT)
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 DFdkYPvGRpYU for <sidrops@ietfa.amsl.com>; Tue, 20 Aug 2019 02:08:53 -0700 (PDT)
Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (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 8D23D120024 for <sidrops@ietf.org>; Tue, 20 Aug 2019 02:08:53 -0700 (PDT)
Received: by mail-oi1-x22f.google.com with SMTP id n1so1135169oic.3 for <sidrops@ietf.org>; Tue, 20 Aug 2019 02:08:53 -0700 (PDT)
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=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; d=1e100.net; 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: <BYAPR11MB37517CDEF18A211F9D9B6324C0C10@BYAPR11MB3751.namprd11.prod.outlook.com> <CAEGSd=BJ+zbpaOTjb0mQm+TktVZO+yU_xhnjM1ZMcVFLQo20xA@mail.gmail.com> <BYAPR11MB3751F9334FDC8E598D004388C0C00@BYAPR11MB3751.namprd11.prod.outlook.com> <CAEGSd=BYK-mN9hWQ6Fn3KK8ACqnUy=ePLeE1EboYufHod2H8EQ@mail.gmail.com> <D85DA5AE-703D-4DC8-A656-D0D2C6A3B776@cisco.com>
In-Reply-To: <D85DA5AE-703D-4DC8-A656-D0D2C6A3B776@cisco.com>
From: Alexander Azimov <a.e.azimov@gmail.com>
Date: Tue, 20 Aug 2019 12:08:38 +0300
Message-ID: <CAEGSd=CzkPQkzX8SN=6HUCbbRsFsCy-Q_2rUiJJ004dNt0QGjw@mail.gmail.com>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
Cc: "sidrops@ietf.org" <sidrops@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002baa74059088cee1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/j7Lw4LnXPjHaBLH3AChGp2GZFjQ>
Subject: Re: [Sidrops] draft-ietf-sidrops-aspa-verification-01: Handling unknowns
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, 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) <jheitz@cisco.com>om>:

> 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 <a.e.azimov@gmail.com>
> wrote:
>
> I'm sorry for the last email. It was supposed to be bigger.
>
> пт, 26 июл. 2019 г. в 08:38, Jakob Heitz (jheitz) <jheitz@cisco.com>om>:
>
>> 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