Return-Path: 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 ; 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 ; 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 ; Tue, 20 Aug 2019 02:08:53 -0700 (PDT) Received: by mail-oi1-x22f.google.com 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; 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: In-Reply-To: From: Alexander Azimov Date: Tue, 20 Aug 2019 12:08:38 +0300 Message-ID: To: "Jakob Heitz (jheitz)" Cc: "sidrops@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002baa74059088cee1" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 09:08:56 -0000 --0000000000002baa74059088cee1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. =D1=81=D0=B1, 27 =D0=B8=D1=8E=D0=BB. 2019 =D0=B3. =D0=B2 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=E2=80=99s IPv4/IPv= 6 > announcements onward, e.g. to the Provider=E2=80=99s upstream providers o= r 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=E2=80=99s IPv4/IPv= 6 > announcements to all of the provider's neighbors. If an AS, AS-A publishe= s > at least one ASPA and it lists AS-B as a provider and AS-C is connected t= o > AS-A, but AS-A does not list AS-C in an ASPA, then AS-A authorizes AS-B t= o > 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. > > =D0=BF=D1=82, 26 =D0=B8=D1=8E=D0=BB. 2019 =D0=B3. =D0=B2 08:38, Jakob Hei= tz (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 debuggin= g > purposes, it might be also useful to distinguish fully verified paths whe= re > 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 unverifiabl= e. >> > 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. > > --=20 Best regards, Alexander Azimov --0000000000002baa74059088cee1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jakob,

I'm sorry that it t= ook so long to reply to your suggestion.

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

=D1=81=D0=B1, 27 =D0=B8=D1=8E=D0= =BB. 2019 =D0=B3. =D0=B2 04:35, Jakob Heitz (jheitz) <jheitz@cisco.com>:
The draft states:

An ASPA attests that a Customer AS holder (CAS) has authorized a parti= cular Provider AS (PAS) to propagate the Customer=E2=80=99s IPv4/IPv6 annou= ncements onward, e.g. to the Provider=E2=80=99s upstream providers or peers= .

I suggest to make this more precise and to add the "otherwise&quo= t; condition:

An ASPA attests that a Customer AS holder (CAS) has authorized a parti= cular Provider AS (PAS) to propagate the Customer=E2=80=99s IPv4/IPv6 annou= ncements to all of the provider's neighbors. If an AS, AS-A publishes a= t 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, the= n 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 announcem= ents only to ASes that consider AS-C to be their provider. I.e., AS-A prohibits AS-C from propagating the announce= ments 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.


Thank= s,
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 bi= gger.

=D0=BF=D1=82, 26 =D0=B8=D1=8E=D0=BB. = 2019 =D0=B3. =D0=B2 08:38, Jakob Heitz (jheitz) <jheitz@cisco.com>:

If you receive an AS-PATH of 2 ASes an= d 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 procedu= re I had in mind that we need to detect invalids. But for debugging purpose= s, it might be also useful to distinguish fully verified paths where all pa= irs are valid and those paths that represent a combination of valid and unknown pairs. It will also require c= larification that for backward compatibility such unknown paths MUST be tre= ated 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 a= ny such segment turns out to be

invalid, then the whole path must be c= onsidered invalid, not unverifiable.

I do agree and that's how both downstream path upstream path proce= dures are defined in the draft.
As we discussed in person, we might need additional clarification in t= he beginning where {AS(I), AS(I-1)...} sequence is defined.
=C2=A0

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.<= /div>

BTW, you have a copy/paste error in 5.= 2 Downstream paths:

If a route from ROUTE_AFI address family is rece= ived from a customer

should be:

If a route from ROUTE_AFI address family i=
s received from a provider
Yes, you are right. Copy-paste can become tricky. Will be fixed in the= next version.



--
Best regards,
Alexander Azimov
--0000000000002baa74059088cee1--