Re: [Sidrops] ASPA verification questions
"Wanghaibo (Rainsword)" <rainsword.wang@huawei.com> Thu, 15 December 2022 02:35 UTC
Return-Path: <rainsword.wang@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 59899C14CE2E for <sidrops@ietfa.amsl.com>; Wed, 14 Dec 2022 18:35:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 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] autolearn=unavailable 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 I7EbpXbA_rA6 for <sidrops@ietfa.amsl.com>; Wed, 14 Dec 2022 18:35:06 -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 3777FC14CE29 for <sidrops@ietf.org>; Wed, 14 Dec 2022 18:35:06 -0800 (PST)
Received: from lhrpeml500004.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4NXbpj3sTtz6H73T for <sidrops@ietf.org>; Thu, 15 Dec 2022 10:31:57 +0800 (CST)
Received: from kwepemi500003.china.huawei.com (7.221.188.51) by lhrpeml500004.china.huawei.com (7.191.163.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Thu, 15 Dec 2022 02:35:02 +0000
Received: from kwepemi500002.china.huawei.com (7.221.188.171) by kwepemi500003.china.huawei.com (7.221.188.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Thu, 15 Dec 2022 10:35:01 +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; Thu, 15 Dec 2022 10:35:01 +0800
From: "Wanghaibo (Rainsword)" <rainsword.wang@huawei.com>
To: Ben Maddison <benm=40workonline.africa@dmarc.ietf.org>, Claudio Jeker <cjeker@diehard.n-r-g.com>
CC: "sidrops@ietf.org" <sidrops@ietf.org>
Thread-Topic: [Sidrops] ASPA verification questions
Thread-Index: AQHZD8sFQkVOJWwd102JFoM4tHOBLa5tKQaAgAERU+A=
Date: Thu, 15 Dec 2022 02:35:00 +0000
Message-ID: <1ce683ebac624b9fa87ff32000f0aa40@huawei.com>
References: <Y5nh7YrUMjxOy1xA@diehard.n-r-g.com> <20221214181035.bydtb3nvtsklav4j@iolcus>
In-Reply-To: <20221214181035.bydtb3nvtsklav4j@iolcus>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.202.204]
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/E6FLC5ubJBj3c9KiuRoPtjDw2yo>
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: Thu, 15 Dec 2022 02:35:07 -0000
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. Regards, Haibo |-----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] 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