Re: [Sidrops] ASPA verification algorithm error

Alexander Azimov <a.e.azimov@gmail.com> Fri, 12 February 2021 18:26 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 352C33A0045 for <sidrops@ietfa.amsl.com>; Fri, 12 Feb 2021 10:26:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bOT0CB7Io80y for <sidrops@ietfa.amsl.com>; Fri, 12 Feb 2021 10:26:36 -0800 (PST)
Received: from mail-oo1-xc34.google.com (mail-oo1-xc34.google.com [IPv6:2607:f8b0:4864:20::c34]) (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 719F33A003F for <sidrops@ietf.org>; Fri, 12 Feb 2021 10:26:36 -0800 (PST)
Received: by mail-oo1-xc34.google.com with SMTP id f26so64479oog.5 for <sidrops@ietf.org>; Fri, 12 Feb 2021 10:26:36 -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=T5tFDIkBcy7fhZqLIHJ3jkUXsRwD3SAArmL+K0uYNQI=; b=r96DC9o+7F8Trt49vt+Cy1j8Tb9AOGhVLPzERIRdaMA5w2LB+dKhAm5glTYxvDx9VS eFboLIrDmLVHuPyyXEXrBLIUsizIc2+hXvQ7Kw+gRLAvsSOXq+C2xgeYLFO3UT53Q3qd XWvbmzVOLizDtJ8tGnyOUTH0E639CB4JqkEZKZ1yCeFKnWtpHOkqk5yqGysvVjYvTlxK vI1nq0EFsHWNVACQrZTLfxYTemqp2lc7GzG6BevkPmOBXvOlvNeCeBekQHk5uezKTDgj 43EOzGpOrhYxm64p+s6HmSF8ek3Td+SSnckdCxMosJJBO7OWLOD6zk1r+aQMOSXL3wy4 +IYQ==
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=T5tFDIkBcy7fhZqLIHJ3jkUXsRwD3SAArmL+K0uYNQI=; b=qZL2an+zqgco8TdAwWg9way5pYH45yw3kemDzEwg/i1KaTpyF60HdxrY5Pud8ouuSe 2O8yVFgZbxpLWSG9/uwmzzuYBnic0XfVL6l6wFTlBx8zMFQdHpOKSzMrKYwOJZgoWsLH pg+Kfj+HGGCUEZk3m+GrTaEQNHFsr4h+8+yez0lCDaHoEU4OaQMfJqBY9REnY92RVFGY /qgFXis6K2afaryhGRZ2zgDwhx/w7tK0gZ5rd22PRXK82a0OKMPpfGSCNPQ1xq51wBPC 24rYH1zj2lXfD2A484lcKQVf335ePIq/FT/0r+9vKrlgQR0Pntw3tWVII3flvPgTlc0/ +gjw==
X-Gm-Message-State: AOAM530v1AyvBh5lluFKiH97rSxygarzMTecu7SFdLeP4KtEXANn555G FmOpM88MnAeI3eu8YgpUdDfmQO2LswKmPzBcQeM=
X-Google-Smtp-Source: ABdhPJwWzuJ9D1ilUsf4HbsfdbF7z3XvSwst0fcdzw1DDHu8gtpSReSZytttEqeEYAvknEHzZz76QqKZwbod30InrJA=
X-Received: by 2002:a4a:97a7:: with SMTP id w36mr2870156ooi.64.1613154395727; Fri, 12 Feb 2021 10:26:35 -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>
In-Reply-To: <20210212081003.bm52czsjoevwtnw3@benm-laptop>
From: Alexander Azimov <a.e.azimov@gmail.com>
Date: Fri, 12 Feb 2021 21:26:24 +0300
Message-ID: <CAEGSd=B7KSaAbm-zLE_FUvFHnFaUUF9Sp-1rJ6e94E_LDVpw=Q@mail.gmail.com>
To: Ben Maddison <benm=40workonline.africa@dmarc.ietf.org>
Cc: "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="000000000000b9a97705bb27c68b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/8NoPxeGqu7k7nIxct6wRWKlm-bE>
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: Fri, 12 Feb 2021 18:26:38 -0000

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