Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-verification - ENDS 03/22/2023 (Mar 22 2023)

戴志滨 <daizhibin@ruijie.com.cn> Mon, 10 April 2023 13:08 UTC

Return-Path: <daizhibin@ruijie.com.cn>
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 D20B6C151717 for <sidrops@ietfa.amsl.com>; Mon, 10 Apr 2023 06:08:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=ruijie-com-cn.20200927.dkim.feishu.cn
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 1wsIwMoDpOQ3 for <sidrops@ietfa.amsl.com>; Mon, 10 Apr 2023 06:08:54 -0700 (PDT)
Received: from s01.bc.larksuite.com (s01.bc.larksuite.com [209.127.230.11]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9C44C151548 for <sidrops@ietf.org>; Mon, 10 Apr 2023 06:08:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=s1; d=ruijie-com-cn.20200927.dkim.feishu.cn; t=1681132129; h=from:subject:mime-version:from:date:message-id:subject:to:cc: reply-to:content-type:mime-version:in-reply-to:message-id; bh=mMVhltuCfZeH+VHCHAFCN+7psu6+D2l5TmmwFL/dN/0=; b=klG6VizN1Vq/J3P+cCQa1TQp5US5QkDqwfTyiDaltQl7u2pPjCDJ1yQPUh+I9/DLsOstY8 lbBKg3y3p/Z1QSnZGlLbEGSf1Ky80lTTROm0S0tPEsq/9diP/ojwGdqPZviogi+xwwYwYM fkHWm3QIynTpzBBBS77pUSZjYep4uSzPZeeEXroLvVEjwcRM1pe+5q8I3GqjjZYaDJqxfz 5c7cUgdx1tm2wDGtPOhjdH/DDjSbJzWgotV1DlogIzRt0HuMaYcic8B91qP8NViTzQbQ3C xth/4d9zNkfbUDE/jp6jB9dVm98KNfTz5pOezj5LVewo8GmHOfau4JkToFrzjw==
Content-Type: multipart/alternative; boundary="f8077b6730af661f8c2c32e648fbcf3e7cb954ac7ec9f92916b39f642900"
Date: Mon, 10 Apr 2023 21:08:38 +0800
Message-Id: <180853ad1e71559b555b2d81e25cbd6e2b2c12e7.6bb3a20e.ce45.4f8e.8378.c9504f8ba716@feishu.cn>
Cc: draft-ietf-sidrops-aspa-verification <draft-ietf-sidrops-aspa-verification@ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>
X-Lms-Return-Path: <lba+164340a56+78fe67+ietf.org+daizhibin@ruijie.com.cn>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
From: 戴志滨 <daizhibin@ruijie.com.cn>
Mime-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/tPxmzlsEmFMJtzvAR-u1FF96cQI>
Subject: Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-verification - ENDS 03/22/2023 (Mar 22 2023)
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, 10 Apr 2023 13:08:58 -0000

Hi Sriram,
   Thank you for your reply. I still have a different view.

>1. Section 6.1, Step 2, "Collapse prepends in the AS_SEQUENCE(s) in the AS_PATH (i.e., keep only the unique AS numbers). " ==>if there are multiple AS numbers with the same number in AS_PATH, which AS is selected to join the ordered queue as a result?
 eg. the AS_PATH's AS_SEQUENCE(s) is {100,101, 102, 101, 103, 104}, the ordered queue should be {100,101, 102, 103, 104} or {100, 102, 101, 103, 104}?

With AS_PATH {100,101, 102, 101, 103, 104}, it is not possible for the Update to pass the basic AS_PATH sanity checks. It is discarded because it contains a loop. Please see RFC 4271 (do a search with “loop”).
>> RFC 4271 as loopdetection is checking that the autonomous system number of the local system does not appear in the AS path,but administrator can add one or more AS numbers to the AS_PATH attribute using the post-routing policy, so in the case of misconfiguration or malice, it is possible to receive the AS_PATH attribute in the above case.

For example,  the AS 100 router announces a route with AS_PATH {100, 101,102, 101} to the AS 103 router,  and {101, 102, 102} are forcibly added through the post-routing policy.
After receiving the route, the as103 router scans for the AS_PATH and finds that local AS 103 does not exist in the AS_PATH. Therefore, the router determines that there is no loop。
The procedure for router AS 104 is similar。

So we need to consider the handling of these unexpected AS_PATH attributes.

Kind regards,
zhibin

> From:"Sriram, Kotikalapudi (Fed)"<kotikalapudi.sriram@nist.gov>
> Date:Sat, Apr 8, 2023, 01:04
> Subject:RE: [Sidrops] draft-ietf-sidrops-aspa-verification
> To:"戴志滨"<daizhibin@ruijie.com.cn>,"draft-ietf-sidrops-aspa-verification@ietf.org"<draft-ietf-sidrops-aspa-verification@ietf.org>
> Cc:"sidrops@ietf.org"<sidrops@ietf.org>
> Hi Zhibin,
> 
> Sorry for the delay in replying.
> 
>  >1. Section 6.1, Step 2, "Collapse prepends in the AS_SEQUENCE(s) in the AS_PATH (i.e., keep only the unique AS numbers). " ==>if there are multiple AS numbers with the same number in AS_PATH, which AS is selected to join the ordered queue as a result? 
>  eg. the AS_PATH's AS_SEQUENCE(s) is {100,101, 102, 101, 103, 104}, the ordered queue should be {100,101, 102, 103, 104} or {100, 102, 101, 103, 104}? 
> 
> With AS_PATH {100,101, 102, 101, 103, 104}, it is not possible for the Update to pass the basic AS_PATH sanity checks. It is discarded because it contains a loop. Please see RFC 4271 (do a search with “loop”).
> 
> >2. Section 6.2, "The downstream path verification procedure" step 4, find the lowest value of v (2 <= u <= N) for which hop(AS(u-1), AS(u)) = "not Provider". Call it u_min.==>"the lowest value of v " should be "the lowest value of u". 
> 
> Other also pointed this out and it was fixed in v-13.
> 
> >3. If the private as (64512-65534, 4200000000-4294967294) exists in BGP AS_PATH,the verification result should be invalid or otherwise? 
> >4.Could private AS exist in ASPA? 
> 
> I will plan to add a statement like the following which is copied from RFC 9234.
> 
> 	"The procedures specified in this document in scenarios that use private AS numbers behind an Internet-facing ASN (e.g., a data-center network [RFC7938] or stub customer) may be used, but any details are outside the scope of this document."
> 
> Sriram
> ========================
> 
> 
> From: 戴志滨 <daizhibin@ruijie.com.cn> 
> Sent: Sunday, March 26, 2023 8:34 AM
> To: draft-ietf-sidrops-aspa-verification@ietf.org
> Subject: [Sidrops] draft-ietf-sidrops-aspa-verification
> 
> Hi author, 
> 
>  After reading this document, I would like to ask you the following questions: 
> 
>  1. Section 6.1, Step 2, "Collapse prepends in the AS_SEQUENCE(s) in the AS_PATH (i.e., keep only the unique AS numbers). " ==>if there are multiple AS numbers with the same number in AS_PATH, which AS is selected to join the ordered queue as a result? 
>  eg. the AS_PATH's AS_SEQUENCE(s) is {100,101, 102, 101, 103, 104}, the ordered queue should be {100,101, 102, 103, 104} or {100, 102, 101, 103, 104}? 
>  2. Section 6.2, "The downstream path verification procedure" step 4, find the lowest value of v (2 <= u <= N) for which hop(AS(u-1), AS(u)) = "not Provider". Call it u_min.==>"the lowest value of v " should be "the lowest value of u". 
>  3. If the private as (64512-65534, 4200000000-4294967294) exists in BGP AS_PATH,the verification result should be invalid or otherwise? 
>  4.Could private AS exist in ASPA? 
>   
> Kind regards, 
> zhibin dai