Re: [Sidrops] ASPA verification questions

On Fri, Dec 16, 2022 at 11:41:42AM +0000, Zhuangshunwan wrote:
> 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
> #

That is exactly what my question was about.

What about a config with missing relationship? like:

bgp 20221216
 peer x.x.x.x remote-as 20221217
 #
 ipv4-family unicast
  peer x.x.x.x enable
  peer x.x.x.x aspa-validation enable

Will 'aspa-validation enable' fail because relationship is missing?
Will 'aspa-validation enable' fail silently?
Will there be some default relationship assumed?

Btw. I would not call this relationship. It is the 'role' and should
offer the RFC 9234 roles (which are also used by the ASPA draft). This way
you get two RFC with one stone. Also there are more than 3 roles defined.

Regards
-- 
:wq Claudio

> 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 mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops