Re: [Sidrops] ASPA verification algorithm error

Alexander Azimov <a.e.azimov@gmail.com> Mon, 15 February 2021 18:15 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 943503A0ED2 for <sidrops@ietfa.amsl.com>; Mon, 15 Feb 2021 10:15:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 l6nu8vOkkjyT for <sidrops@ietfa.amsl.com>; Mon, 15 Feb 2021 10:15:14 -0800 (PST)
Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 1F69B3A0E9B for <sidrops@ietf.org>; Mon, 15 Feb 2021 10:15:13 -0800 (PST)
Received: by mail-ot1-x32d.google.com with SMTP id b16so4416464otq.1 for <sidrops@ietf.org>; Mon, 15 Feb 2021 10:15:13 -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=v9YHqxz+4UG7Hr5G751L+M55FBc1MFnlyBNopEwKw4c=; b=sgnOITwsiaL2ssqIsibPYvL0hjbB/eghkPwBlEMwDVHLCOrwADtLbLJ3kDgdMgUMX+ yQ/0s7I2hAODfhPpXllV2i1dZfwsG+3+ZYX1uJEHMpDnubPOqj82qIsvhD6pFv4wDO2n 2c98NccQbI2WsA5Fd92ZjK+d+UZwvKAAf4AQICZypwYnWDlePYV4wW4IefA+sK6brAdt ZyaRbzSne8m/OZmnr7A63a+XqdVQmO2JUGAW3AMGyRuOTlEdyZG1WXsuNzpliKV3Rk9i E7oqX1RMSYmqGm71SGb9xK+hxXqeBCyml4vA9eyzz+/1n2dXD/xYKG5/N0X9rRPDubi+ MPQg==
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=v9YHqxz+4UG7Hr5G751L+M55FBc1MFnlyBNopEwKw4c=; b=J6KCrKh13/palYGSXaL/TzHV0l8POmR8ke+fzgysHGDIexxl3nk7jLmt0GSEgNqMoW lhTv3TNLsl16MjLicYgLkskrbNCCOYxX7pXuZAOQbpjmzqyhIBNx/Sx20pqOuZdagn8d piwgRy/WSfrOBERF4UlUwFGXyiMQU2YpWMXi9bZkfxQwOZvXtxsJv2LqZk5A/1nC+mob PrHeuXYmijrIp9P0qlhJNAkZtlQKIu5RV5btgB/K5GF3gPVU/fIIvkf194u9QmqrKSOH h+7T9iSb9cgeUvGYUcHNr/V8BImkRTuAi0Pvr/ZJ38zuieP5dMFnuOZP/wo1VS6Chf18 rN4g==
X-Gm-Message-State: AOAM532SF7QcfuReK0yncBYHcwjTmqEgerc5iFbrqXwOaVGIgrjRlbQB Xu9EhY7/SpmXd1C+ySxM7NqW+vDUPGsejay1sUM=
X-Google-Smtp-Source: ABdhPJy6/LH9jbKFDy/hzhb1Tm4EUAyas5oJ1KfHJJ8zyJjxZ6HmDgSVv/h2EqmXthiiObiePYMvU991+xckzGGH3yw=
X-Received: by 2002:a9d:861:: with SMTP id 88mr12637298oty.27.1613412913237; Mon, 15 Feb 2021 10:15:13 -0800 (PST)
MIME-Version: 1.0
References: <BYAPR11MB320714401DE9AFBF5D24C832C0A09@BYAPR11MB3207.namprd11.prod.outlook.com> <CACC_My906OxmEphW=DOrGhwSagZKf--hd5oLR9uF=24kuA24ag@mail.gmail.com> <BYAPR11MB3207BD021F246199C7E4CCD6C08C9@BYAPR11MB3207.namprd11.prod.outlook.com> <CACC_My8Kg33v=2kXgDZb+11QHSPwJtiFSmuXm_w=LuoEP2crBA@mail.gmail.com> <BYAPR11MB320745F7CD054ABBAD1647FBC08C9@BYAPR11MB3207.namprd11.prod.outlook.com> <20210212081003.bm52czsjoevwtnw3@benm-laptop> <CAEGSd=B7KSaAbm-zLE_FUvFHnFaUUF9Sp-1rJ6e94E_LDVpw=Q@mail.gmail.com> <DM6PR11MB3211D016C73756ADB6E979EBC08B9@DM6PR11MB3211.namprd11.prod.outlook.com>
In-Reply-To: <DM6PR11MB3211D016C73756ADB6E979EBC08B9@DM6PR11MB3211.namprd11.prod.outlook.com>
From: Alexander Azimov <a.e.azimov@gmail.com>
Date: Mon, 15 Feb 2021 21:15:01 +0300
Message-ID: <CAEGSd=CiBGi1VYji+k8WQKn6DorApFdX6JrvasoB_=xaELKOGA@mail.gmail.com>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
Cc: Ben Maddison <benm=40workonline.africa@dmarc.ietf.org>, "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>, Lukas Tribus <lukas@ltri.eu>
Content-Type: multipart/alternative; boundary="00000000000091d26a05bb63f794"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/yKH0nA_d9ju98TmVregGhNC_NPY>
Subject: Re: [Sidrops] ASPA verification algorithm error
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: Mon, 15 Feb 2021 18:15:18 -0000

Jacob,

I think you haven't got my point. Let me quote the current document:

   Instead of checking AS_PATH correctness, this document focuses on
   solving real-world operational problems - automatic detection of
   malicious hijacks and route leaks.


What you are suggesting doesn't improve the detection of route leaks,
though can be harmful in fighting malicious activity.
I stay in favor that Valid in terms of ASPA should mean that all pairs are
Valid for upflow paths and slightly more complex for downflow paths.

We don't try to combine ROAs and Route Objects at the ROV procedure to get
more 'Valid' outcomes, this principle should be applicable here too.

пт, 12 февр. 2021 г. в 22:48, Jakob Heitz (jheitz) <jheitz@cisco.com>om>:

> It seems we all agree that the path I illustrated is valid and the
> algorithm in the draft marks it unknown.
>
> The first priority is to get the correct result.
>
>
>
> ASPA has to work as well as possible without full participation.
>
> It will never work if full participation is required.
>
>
>
> I agree with Ben that it is difficult to reason with the model of ASPA as
> written in the draft.
>
> Here is an alternative:
>
>
>
>     Every transit AS in the path must have at least one neighbor that
> calls it a provider.
>
>
>
> That's a lot easier to reason about than trying to figure out where
> upstream turns to downstream
>
> in the presence of bilateral peers, siblings, complex relationships and
> ASes making no attestations.
>
> You only need to consider one AS at a time and what is to its left and to
> its right.
>
>
>
> Repeating:
>
>
>
> Consider the as-path (1 2 3 4), where
>
> 1 attests that 2 is its provider
>
> 4 attests that 3 is its provider
>
> 2 and 3 make no attestations.
>
> Then the path is valid.
>
>
>
> Here is a simple and working algorithm:
>
>
>
>    - The received AS-path is prepared:
>       - Remove duplicate ASNs.
>       - Prepend own ASN.
>       - May also prepend Forwarded-to ASN to detect own leak. (optional)
>    - For every sequence (A, B, C) of consecutive ASes in an AS-path:
>       - If A attests that B is not a provider and C attests that B is not
>       a provider,
>       then B leaked the route: B is transiting for free. The segment is
>       invalid.
>       - If either A or C attests that B is a provider, then the AS-path
>       segment  (A, B, C) is valid.
>       - Else if either A or C make no attestation, then the leak state is
>       unknown. Even if B lists both A and C as providers, it is not necessarily a
>       leak, because either A or C could consider B as a provider for some of
>       their routes, even though they don’t attest to it.
>    - If all the path segments are valid, then the whole path is valid.
>    - If any of the path segments is invalid, then the whole path is
>    invalid.
>    - Else, at least one path segment is unknown and one more rule must be
>    applied: for any sequence of ASes (A, B1, ..., Bn, C), if A attests that B1
>    is not a provider and C attests that Bn is not a provider, then the AS-path
>    is invalid. This is for any number of Bx greater than 1.
>
>
>
>
>
>
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* Sidrops <sidrops-bounces@ietf.org> *On Behalf Of *Alexander Azimov
> *Sent:* Friday, February 12, 2021 10:26 AM
> *To:* Ben Maddison <benm=40workonline.africa@dmarc.ietf.org>
> *Cc:* Jakob Heitz (jheitz) <jheitz=40cisco.com@dmarc.ietf.org>rg>;
> sidrops@ietf.org; Lukas Tribus <lukas@ltri.eu>
> *Subject:* Re: [Sidrops] ASPA verification algorithm error
>
>
>
> Jacob, you are right that additional heuristics can be added to ASPA logic
> to transform some Unknown states to Valid, though it will not improve
> leak/hijack detection.
>
> Nevertheless, I agree with Ben. Such changes can result in
> misleading understanding if one will try to distinguish if the path is more
> reliable a.e. Valid from Unknown. This has special importance if we start
> speaking about malicious activity.
>
>
>
>
>
>
>
> пт, 12 февр. 2021 г. в 11:10, Ben Maddison <benm=
> 40workonline.africa@dmarc.ietf.org>gt;:
>
> Hi Jakob,
>
> On 02/11, Jakob Heitz (jheitz) wrote:
> > pair_check with either AS2 or AS3 as customer will return unknown.
> > Therefore, the algorithm returns unknown, when it should return valid.
> >
> If I'm understanding you correctly:
> *Any* ASPA (even an [AS0] one) issued by either AS2 or AS3 would result
> in a valid path.
> Therefore, you are arguing, even if no ASPA covers the AS2<->AS3
> adjacency, the path should be considered *valid* since there is no possible
> ASPA object that could result in it being *invalid*?
>
> I think that logic holds. However I don't favor incorporating it into
> the validation algorithm for a few reasons:
> 1.  We (and I expect most others) will make no policy distinction
>     between valid and invalid paths in policy. Thus any additional
> complexity
>     is a poor trade.
> 2.  It is important that engineers are able to easily reason about how a
>     set of ASPA objects and an observed AS_PATH result in a validation
>     state. Whilst I think the above logic is valid, accounting for it
>     mentally is non-trivial.
> 3.  In the event that operators do de-pref invalid in favor of unknown
>     (yes, I know I said above that they probably won't: but *if* they do),
>     then AS2 and AS3 lose traffic on that adjacency (which is undesirable
> for
>     them both - otherwise they won't have built it).
>     This creates a positive economic incentive for AS2 and/or AS3 to go
>     and create an ASPA. Positive incentives are in short supply in the
>     routing security world - I don't think we should opt-out of them
>     lightly!
> 4.  There is no creation dependency problem for ASPAs, like there is for
>     ROAs - where e.g. a provider has to wait for customers to issue ROAs
>     for all sub-allocations before issuing for the aggregate. As a
>     result I don't believe that we should be spending cycles
>     accommodating those operators that don't bother doing it.
>
> Interested to hear your thoughts?
>
> Cheers,
>
> Ben
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
>
>
>
>
> --
>
> Best regards,
>
> Alexander Azimov
>


-- 
Best regards,
Alexander Azimov