Re: [Sidrops] ASPA verification questions

Zhuangshunwan <zhuangshunwan@huawei.com> Fri, 16 December 2022 11:41 UTC

Return-Path: <zhuangshunwan@huawei.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 8C82FC14CE53 for <sidrops@ietfa.amsl.com>; Fri, 16 Dec 2022 03:41:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Level:
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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
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 v8oZZbqEhaUP for <sidrops@ietfa.amsl.com>; Fri, 16 Dec 2022 03:41:48 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F170C14CE43 for <sidrops@ietf.org>; Fri, 16 Dec 2022 03:41:48 -0800 (PST)
Received: from lhrpeml500002.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4NYRv14rb4z6J6JM for <sidrops@ietf.org>; Fri, 16 Dec 2022 19:38:37 +0800 (CST)
Received: from kwepemi500001.china.huawei.com (7.221.188.114) by lhrpeml500002.china.huawei.com (7.191.160.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Fri, 16 Dec 2022 11:41:44 +0000
Received: from kwepemi500002.china.huawei.com (7.221.188.171) by kwepemi500001.china.huawei.com (7.221.188.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Fri, 16 Dec 2022 19:41:43 +0800
Received: from kwepemi500002.china.huawei.com ([7.221.188.171]) by kwepemi500002.china.huawei.com ([7.221.188.171]) with mapi id 15.01.2375.034; Fri, 16 Dec 2022 19:41:43 +0800
From: Zhuangshunwan <zhuangshunwan@huawei.com>
To: Claudio Jeker <cjeker@diehard.n-r-g.com>, "sidrops@ietf.org" <sidrops@ietf.org>
Thread-Topic: [Sidrops] ASPA verification questions
Thread-Index: AQHZD8sFIFca6CMGnUe+Jg5XUvXhKa5tKQaAgACM7wCAAK5EgIACAFQA
Date: Fri, 16 Dec 2022 11:41:42 +0000
Message-ID: <d737248a3df94e73b14cff3e2b59bdf0@huawei.com>
References: <Y5nh7YrUMjxOy1xA@diehard.n-r-g.com> <20221214181035.bydtb3nvtsklav4j@iolcus> <1ce683ebac624b9fa87ff32000f0aa40@huawei.com> <Y5saAzBLErhmwQM8@diehard.n-r-g.com>
In-Reply-To: <Y5saAzBLErhmwQM8@diehard.n-r-g.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.202.95]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/XAXXHJ6jUyatHrX_RAnvtzfRhTY>
Subject: Re: [Sidrops] ASPA verification questions
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: Fri, 16 Dec 2022 11:41:53 -0000

Dear Claudio,

On an actual running network, the business relationship of each EBGP neighbor is well known to the network administrator.
In my opinion, we can simply add 2 configuration command for ASPA as follows:

bgp 20221216
 peer x.x.x.x remote-as 20221217
 #
 ipv4-family unicast
  peer x.x.x.x enable
  peer x.x.x.x relationship { provider | customer | peering }
  peer x.x.x.x aspa-validation enable
#

Kind regards,
Shunwan

> -----Original Message-----
> From: Sidrops [mailto:sidrops-bounces@ietf.org] On Behalf Of Claudio Jeker
> Sent: Thursday, December 15, 2022 8:59 PM
> To: sidrops@ietf.org
> Subject: Re: [Sidrops] ASPA verification questions
> 
> On Thu, Dec 15, 2022 at 02:35:00AM +0000, Wanghaibo (Rainsword) wrote:
> > Hi Ben,
> >
> > I agree with you.
> >
> > When an ISP wants to do ASPA verification, the ISP should sign its own
> > ASPAs. Then the border router can calculate the peer's role according
> > to that database.
> > When we set a peer's role according to RFC9234, it also makes the
> > calculating easier. But even if we do that, I think we may also check
> > the peer's role configuration whether match the ASPAs, because of
> > misconfiguration may happen.
> 
> I desagree.
> 
> Tying ASPA verification together with announcing ASPA objects will result in a
> much higher bar to deploy ASPA verification at large. It also adds a
> dependency of ASPA verification to specific ASPA objects and will cause
> disruption if for whatever reason the ISP's ASPA object fails to validate.
> Also it may be easier for bigger providers to enable ASPA verification well
> ahead of adding official ASPA objects.
> 
> I see the elegance of the proposal but I think the downsides of using
> Validated ASPA Payloads to control ASPA verification are to big.
> 
> --
> :wq Claudio
> 
> > |-----Original Message-----
> > |From: Sidrops [mailto:sidrops-bounces@ietf.org] On Behalf Of Ben
> > |Maddison
> > |Sent: Thursday, December 15, 2022 2:11 AM
> > |To: Claudio Jeker <cjeker@diehard.n-r-g.com>
> > |Cc: sidrops@ietf.org
> > |Subject: Re: [Sidrops] ASPA verification questions
> > |
> > |Hi Claudio,
> > |
> > |On 12/14, Claudio Jeker wrote:
> > |> Hi all,
> > |>
> > |> I'm working on ASPA verification in OpenBGPD and while I have the
> > |> basic validation algorithm working I have a question that is not
> > |> covered by
> > |> draft-ietf-sidrops-aspa-verification-11:
> > |>
> > |> What should happen with ebgp peers that have no role assigned?
> > |
> > |My personal view (which I have previously discussed, without
> > |agreement, with some of the authors) is that the default
> 'provider/non-provider'
> > |status of an external peer should be derived from the ASPAs issued by
> > |the local AS.
> > |
> > |This obviously needs a knob for override on a per-peer, per-afi basis.
> > |
> > |I would prefer not to have a tight coupling with RFC9234 roles in
> > |implementations.
> > |
> > |Cheers,
> > |
> > |Ben
> >
> > _______________________________________________
> > Sidrops mailing list
> > Sidrops@ietf.org
> > https://www.ietf.org/mailman/listinfo/sidrops
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops