Re: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-verification-16.txt

[Job Snijders <[e-mail]>]

On Tue, Aug 29, 2023 at 02:10:07PM -0400, Nimrod Levy wrote:
> On Tue, Aug 29, 2023 at 11:41 AM Sriram, Kotikalapudi (Fed)
> <kotikalapudi.sriram=[e-mail]> wrote:
> >
> > (2) Do not include ASPA path verification in IBGP either.
> > Reasons: Performing ASPA path verification and rejection of routes with
> > Invalid AS path at eBGP ingress is sufficient. The AS is expected to
> > maintain a consistent view of RPKI data across all its border routers.
> 
> I agree that it should be sufficient to enforce validation on eBGP, but in
> practice this is not always possible.
> Adding validation on certain iBGP sessions (on RRs for example) can add
> security.
> Understanding that this does leave some gaps, this is still a better
> scenario than not enforcing validation at all.
> 
> What problem do we solve by adding this restriction from validating on iBGP?

It isn't so much "adding a restriction", but more "deliberately not
specifying how to do something".

In order to be able to do ASPA validation on IBGP, this working group
would need to specify/standardize a means to signal (via IBGP) the exact
relationship between the far-end ASBR node and the remote EBGP peer.

    (reminder: in order to be able to perform the ASPA verification
     algorithm, the device at hand needs as input parameter the role of
     the remote EBGP peer - one of customer, provider, lateral peer,
     Route Server RS-client, or mutual-transit).

This working group, or IDR, in the future can take up the work to dot
all i's and cross all t's in order to standardize how to do ASPA
verification on IBGP, but I deem it best to first focus on EBGP, and
potentially later on specify how it all could work for IBGP.

This version of the draft does not close the door on future work to make
ASPA verification possible on IBGP.

Kind regards,

Job