Re: [Sidrops] ASPA verification questions

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

I agree with Shunwan. The AS has local knowledge of peers and configuration is maintained locally for each peer relationship. 

Note: Even in RFC 9234, the BGP Role is locally configured first and then the BGP Role capability is exchanged to confirm the relationship with the neighbor. From RFC 9234:

"For backward compatibility, if the BGP Role Capability is sent but one is not received, the BGP Speaker SHOULD ignore the absence of the BGP Role Capability and proceed with session establishment. The locally configured BGP Role is used for the procedures described in Section 5." 

Sriram
------------------------------------

From: Zhuangshunwan <[e-mail]> Fri, 16 December 2022 11:41 UTC 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:[e-mail]] On Behalf Of Claudio Jeker
> Sent: Thursday, December 15, 2022 8:59 PM
> To: [e-mail]
> 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:[e-mail]] On Behalf Of Ben
> > |Maddison
> > |Sent: Thursday, December 15, 2022 2:11 AM
> > |To: Claudio Jeker <[e-mail]>
> > |Cc: [e-mail]
> > |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