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
- [Sidrops] ASPA verification questions Claudio Jeker
- Re: [Sidrops] ASPA verification questions Job Snijders
- Re: [Sidrops] ASPA verification questions Ben Maddison
- Re: [Sidrops] ASPA verification questions Randy Bush
- Re: [Sidrops] ASPA verification questions Wanghaibo (Rainsword)
- Re: [Sidrops] ASPA verification questions Claudio Jeker
- Re: [Sidrops] ASPA verification questions Zhuangshunwan
- Re: [Sidrops] ASPA verification questions Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] ASPA verification questions Claudio Jeker