[Sidrops] some wording improvements in draft-ietf-sidrops-aspa-verification

"Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov> Mon, 22 May 2023 16:53 UTC

Return-Path: <kotikalapudi.sriram@nist.gov>
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 1FA16C151082; Mon, 22 May 2023 09:53:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.099
X-Spam-Level:
X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nist.gov
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfSTMBcyEX1I; Mon, 22 May 2023 09:53:06 -0700 (PDT)
Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on20702.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d04::702]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA3F8C151087; Mon, 22 May 2023 09:53:05 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GAR8i56qOlqG1foVUNJCvsslvhsP3h7w/SK86wC1etw4+W8jAEFMO5NFqUJQnDennEye23aaJGds94E8vZ5+pthcDOVdKrqfDG8ecROB7woNS0f+ZDUnOf2jKBepCkmZXJMV5ujOKQ679hQU9J+TcMN29Xbkwkw2xdllUWEVn0vljy5sN7VufYALt+BFdvQQNUoKaM8PBYer/Z8uLeF9QFAKd7tf8qs3E0f+M7o9hxupSpf8XFZbzulptVjf2SQ7Edlmk9Pl6i0whWSSMDuj50/RWR8gGVnzlrbFA/4EcGXniE1M0tUmhvJD8R3hqw4V3GRkJxOgFlMmmy3kJ2S4KA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=oxRJEjEyGbEKhSSkUs8g3Zm5NF8Kdff3NRQVzrpqf/k=; b=FJWjIUGckK9wm/OB4VCfXgziAIjNkM9x70ceA0U0FMiQdrx3OzOCyTqVFxq15gQwOT6+EtZOPgbHuDNT7231RlQbcY2aNpmBFRmX0e4fcx3Cz8a0wqqP/r0BENL9E1zeekKLImhfNPRDrgLc1T3PFb7fTBcGsktl/2X6hHJ9FYUffP6SIMS2SSq8y5W2kAuMMrZRFnLAsRUaolDrcte8fUuBAZ9Fj7icqzENkGWgc04LWg4g1W4Y7e3GQd2cQViqYpp1eH1QSd8RGEOf9jpTNqjrnF8sFiu8fqTrLPcrwZmxkJWxwnUKR5zqigGZq+9hyYq5rcRTtFYlvxpDPDbskQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oxRJEjEyGbEKhSSkUs8g3Zm5NF8Kdff3NRQVzrpqf/k=; b=xwWcaEvZCbrcPcd4OwO67lGFEaiNcTJGuLUzVVB857W0vv2CdnppDhVxfuK8jBkq8EWG/B/0/JRyox7J5V8gdzTDK9w+W+IXctB/1gLv5RbFRI9nAE40v4ii2kfRoW7FU06az24HNI6opbWv07Qur1NVbB7S82XpGO+bsS5EA2IpoiQvj8TY290oJd8jXzdYQefJWILZuyPKL0lAwqJcrwSrQ00Z0vSt0VXoTC5+UUWa9HEW+lW+51wbwi4/16104BxmnGDxxDV0ZX5KHZ0lVeECcbiO6m/D5tFfG/w4//gbQLaJxBFjtj1pl9uMh6+0NeXBb+IeXrO//e9PEEy+kw==
Received: from SA1PR09MB8142.namprd09.prod.outlook.com (2603:10b6:806:171::8) by PH0PR09MB11599.namprd09.prod.outlook.com (2603:10b6:510:2aa::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6411.28; Mon, 22 May 2023 16:52:59 +0000
Received: from SA1PR09MB8142.namprd09.prod.outlook.com ([fe80::226a:790b:a85c:d03e]) by SA1PR09MB8142.namprd09.prod.outlook.com ([fe80::226a:790b:a85c:d03e%6]) with mapi id 15.20.6411.029; Mon, 22 May 2023 16:52:59 +0000
From: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
To: Claudio Jeker <cjeker@diehard.n-r-g.com>
CC: "Borchert, Oliver (Fed)" <oliver.borchert@nist.gov>, "sidrops@ietf.org" <sidrops@ietf.org>, "draft-ietf-sidrops-aspa-verification@ietf.org" <draft-ietf-sidrops-aspa-verification@ietf.org>
Thread-Topic: some wording improvements in draft-ietf-sidrops-aspa-verification
Thread-Index: AQHZjM3dtasahjaM7UK1SgaSUG3D+w==
Date: Mon, 22 May 2023 16:52:58 +0000
Message-ID: <SA1PR09MB8142CF03CEBF445924004B0784439@SA1PR09MB8142.namprd09.prod.outlook.com>
References: <SA1PR09MB8142523FA03AC4EA6E0E014E847C9@SA1PR09MB8142.namprd09.prod.outlook.com> <SA1PR09MB814235BE0566A5C6935CF5B184439@SA1PR09MB8142.namprd09.prod.outlook.com> <SA1PR09MB814231707524646D651B69B884439@SA1PR09MB8142.namprd09.prod.outlook.com> <ZGs5bFRjPLnyL2Jd@diehard.n-r-g.com>
In-Reply-To: <ZGs5bFRjPLnyL2Jd@diehard.n-r-g.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nist.gov;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SA1PR09MB8142:EE_|PH0PR09MB11599:EE_
x-ms-office365-filtering-correlation-id: 00ee3f85-26a2-4794-29d8-08db5ae4ff88
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: hy8vbARiB4Sy7jZB1avjiQumvPTayhwkm8/vyRK3OfJKhg/nInft7x86vmthetUWcDyMBMwCLBJ2HyuN8tjnLYaLNfax3OjpyP9HrsolQ/0yTL4/8DrJWSptBm67moohetGoASbVVy/ZGUUHAlxfLCXR40Mho4oLkMyUCErvZYSVLDhn86KboBO4myRzS1IS/sBLIY4ueJzMT4mej/0K3aEmoggBTGZbyP+fS2jpOIE03WPfE7z03jLWYsvHTkhbUPFwy3V9aMPxjSEhP/SmQ/IqcaRKTC4TUb5SD8RwtxFl0Wtjhe5zb59i7AMsSKJBFftybMzPph/AVWCMDvHXxO4sW5X4jD02OIYr80hvLo8A43RZD5vxlAOsMvaj5TkkxNNDXv9PlnTWaobeHcIFd5UTQCe8Zys3DfMOF43tZV/EB/n60Ooe3l0R7v/pDHpXJvZRhR3kM3b+1PfGG7RA+MZyUay71isjPaoHuaVMUOTbd3G03F9YwEZbb8ZcvOGwVQbP2W/yOHuJxA+lr8wEUn5oTGvpXpPvsYiK9tACHFQgHIWT1N3HhovanLPJea2z9Q8AdnRPPQmz/6akaJAQWYsKcdCA86DnPqoROSYgpLU=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA1PR09MB8142.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(4636009)(366004)(451199021)(2906002)(15650500001)(52536014)(5660300002)(83380400001)(8676002)(8936002)(55016003)(76116006)(66946007)(64756008)(66556008)(66476007)(966005)(6916009)(4326008)(54906003)(7696005)(498600001)(71200400001)(66446008)(33656002)(86362001)(82960400001)(122000001)(26005)(6506007)(186003)(9686003)(38070700005)(38100700002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: d4Kjs1J8b8v9v/s7e94+ib6Yeuh+2ctQ7F6eRAIIqNASNCXFQVbzcn4trP9C+OKN6uEBmswvol9rK8dQZekuIChRRGsQcG1wjlKViK8yIP996WxvJiRYrhZWXgUYz/MfhdJkcvnRDkbB8ERIhTs8H44eQfPiER0zx/y1ZZlmTqH+wbfAt/hjAYnALD5KD0ohu7MJLijtjWr5OAoGBJhhFKCdlqD8nSUwDI2LPZtLuvoeJTzS2Lkph5U0fa4lbCQjvD9o38Tka9m2Ipo0E6YyverDqaP1ZQAhyPV/Jp0kyWmf19URTJfI3kJ2BXJN3djRM+UW3hUt6P0ietqokRqmpabmkOJ0lM8oj085IBN36N6XzXEaZuegJcFrT4Gmpm3oewlmpjAY3Hpbrh4xCldrXwp17ME0YVziU+eIeNm2y8IPT91IIXrDVcjXKnlxnjD31aBYb7XhGkXnxEr1lg/vWann8GYlwS4sPoW2/uAFS2d/M/XTAFPEujZWDCM1CWd8qOqWCqXGQCn0sTSx4IGr6Zx6OXY+PoSJPQYcDawYpiKjCkbXcXgLhOHrCPvuJ4DL7p6nyhHWXvUeb6tQALDJtjGWpEEBQRSpjAYFke0fsMJcR31U5yJMFOJlioe7L6TmMlKxjvwzW3u0U5E4+O/VH300EOTBhWeVzZ2+DmdoKqbfv+qYfsUsIZ1enWh90CLC85cNnKMKjodepL8Ix7cOFbOufgyPULUvt10PWfMWphDQRXRh8vCcEDP1wb/N0owbfhuvsN/juVbmjwKNkN5sUKA9An36DLFO2C3vnl9g2JNJqZJ9ypWQurUhgSD2FPX42B9b+Q8UdvlXLV3Ml8NFrwx4EWU4P+xuzRsNe7pLNguPEIck03scSs8RRrLOPBmE/XVymwLlcnUhT7OGPyQKvV07Xs0jERzJ7yRYxCkP5OIDG3kR7nK3gI4+iECCYTWwHhc3WH/5CnqVmHtBv6+9xrGLhjnNDjUYlli366SOHVfqbf7PNo1m35l2wni2HIuarGrriEbTx32IVUQS4R+nsHC9OaigtNtjjESq9CnVNQdE0Hos3JZBpTvahWxo3aQvOPfRQq3dtAmehA6GzO0HOQMMsBHkUiT9MKFwrtwPnkwQvaLLdkSw7CpXtT5oynxT/ETCGFh0XjdjW/SMKXw5X9pWEzITbKM/pU0/OVvJ8qtBn6zyfxo+ND2fzO6lY7ez0w9t+4+5PSuqsUJkbgWw/hwy0EbcgWNXpkE/Sfsh8sXVzJAgLnTfZx3HU86GG1ZnkeK7Tyv6hErugG4THhY/PeVGA4aZQ10gkMJZubF3i4Q60zYWg14JnSpJ3NMYVxn1Od4ZdSg+30XPjpGEhnZmuGsZnI1UQIjA8KcsKqY7ftlNj+hkKepDdHnLSMrEnBFXZNX8QyoFNkQCVO9ZgOLwx7+jNXmHeTZOWVoC3Pf5y/LTwxyPI+5e6DW2qzCmLbx5pE7XG/XnNxxq8X6/j82bOg/eH9aRCxJTLQ62KBBIMEsC73ANvT7FMo0PIGUTvDq3gkdRVMloppZNvklymm/xjDIn2WXHeBwFPDittD7lBB0=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA1PR09MB8142.namprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 00ee3f85-26a2-4794-29d8-08db5ae4ff88
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2023 16:52:58.9004 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR09MB11599
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/C9nBdaxjQ86XGrlkS4kpRcegO-w>
Subject: [Sidrops] some wording improvements in draft-ietf-sidrops-aspa-verification
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.39
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, 22 May 2023 16:53:10 -0000

[We are now talking about edits in the ASPA verification draft;
so I've changed the subject line;
it was "Re: [Sidrops] Which 8210-bis error code should be used?"]

Claudio,

It appears we are converging well. Thanks for your suggestions. I've incorporated them.

The paragraph in consideration is now simplified as follows (the "Note: ..." stuff is deleted):

   If, despite the above recommendations, the ASPA(s) of a CAS includes
   SPAS for one AFI but not for the other AFI (not even an AS 0), then
   for AS_PATH verification purposes, the CAS is considered to have no
   providers (i.e., absent VAP-SPAS) for the neglected AFI (see the hop-
   check function computation in Section 5). 

I have improved the hop-check function description per your suggestion as follows:

                                             /
                                             |  "No Attestation" if there is no entry
                                             |     in VAP-SPAS table for CAS = AS(i)
                                             |     regardless of the AFI value
                                             |
   hop(AS(i), AS(j), AFI) =  /   Else, "Provider+" if a VAP-SPAS entry for
                                            \     CAS = AS(i) for the mentioned AFI
                                            |     is present and includes AS(j)
                                            |
                                            |  Else, "Not Provider+"
                                            \

Also made the following change for clarity regarding the "No Attestation" outcome (in Section 5 after the above equation):

OLD text:

    The hop-check function is AFI dependent because an AS may have 
    different SPAS for different AFI.

NEW text:

   The "No Attestation" result is returned only when the CAS = AS(i) has
   no ASPA(s) registered or none of its ASPAs are cryptographically
   valid, resulting in no entry for the CAS in the VAP-SPAS table
   (regardless of the AFI value).  The hop-check function is AFI
   dependent because an AS may have different SPAS for different AFIs.

Thanks.

Sriram

==============================

From: Claudio Jeker <cjeker@diehard.n-r-g.com> Mon, 22 May 2023 

On Mon, May 22, 2023 at 05:05:21AM +0000, Sriram, Kotikalapudi (Fed) wrote:
> Oliver and I have discussed the issue off-list. Requiring an artificial
> insertion of an AS 0 only VAP-SPAS for the neglected AFI for the CAS is
> not required. The verification algorithm (hop-check function in Section
> 5) inherently takes care of the neglected AFI (absent VAP-SPAS)
> situation.

I agree with this direction. I suggested a very similar change in a
previous mail.
 
> The previously proposed text change (
> https://mailarchive.ietf.org/arch/msg/sidrops/C5newCanz60yBNc6myoEZfQnMoc/
> ) is retracted.
> 
> But a slight modification of the paragraph in consideration would be
> good as follows:
> 
> 
> OLD text:
> 
> 
>    If, despite the above recommendations, the ASPA(s) of a CAS includes
>    SPAS for one AFI but not for the other AFI (not even an AS 0), the
>    ASPA SHALL NOT be rejected just for that reason.  However, such an
>    ASPA(s) will be presumed to imply that the CAS has no providers
>    (equivalent to AS 0 SPAS) for the AFI that they neglected to include.
> 
> 
> 
> NEW text:
> 
> 
>    If, despite the above recommendations, the ASPA(s) of a CAS includes
>    SPAS for one AFI but not for the other AFI (not even an AS 0), then
>    for AS_PATH verification purposes, the CAS is considered to have no
>    providers (i.e., absent VAP-SPAS) for the neglected AFI (see the hop-
>    check function computation in Section 5).  (Note: Artificial
>    insertion of an AS 0 only VAP-SPAS for the neglected AFI for the CAS
>    is not required.)

I think one should just remove this section and offload all of this into
Section 5. Especially the added Note: does not help at all and is just
confusing for a reader of the draft/RFC who does not know the backstory.
We need to write this for people not knowing all the discussions we had.
 
> The hop-check function is slightly tweaked as follows:
> 
>                              /
>                              | "No Attestation" if there is no entry
>                              |   in VAP-SPAS table for CAS = AS(i)
>                              |
>    hop(AS(i), AS(j), AFI) =  / Else, "Provider+" if a VAP-SPAS entry for
>                              \   CAS = AS(i) for the mentioned AFI
>                              |   is present and includes AS(j)
>                              |
>                              | Else, "Not Provider+"
>                              \
> 
> 
> This is basically the same function definition as before but makes it
> clearer that since VAP-SPAS is absent for the neglected AFI, there would
> be no match in the VAP-SPAS for AS(j) and hence the outcome for that AFI
> would be "Not Provider+".

While already better I prefer if in the "No Attestation" case a clear
statement that this applies to all possible AFI values.
A possible option is:
                             | "No Attestation" if there is no entry
                             |   in VAP-SPAS table for CAS = AS(i)
                             |   independent of the AFI value

I really prefer the definition of the hop-check function to be explicit 
to avoid any possible misinterpretation.

-- 
:wq Claudio