Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-verification - ENDS 03/22/2023 (Mar 22 2023)

[Claudio Jeker <[e-mail]>]

On Sat, Mar 18, 2023 at 09:41:44PM +0200, Ben Maddison wrote:
> Hi all,
> 
> On 03/08, Sriram, Kotikalapudi (Fed) wrote:
> > Hi all,
> > 
> [..]
> > 
> > Version 12 is significantly updated. So, please take a fresh look at
> > it for your response to this WGLC. 
> 
> Thanks to everyone involved for all the hard work getting -12 out.
> It is a substantial improvement over previous versions.
> 
> However, I think that a number of fairly fundamental issues remain
> (which go beyond just individual wording suggestions).
> 
> I'm happy to provide patches for any/all of these, once the WG has made
> a call on the principles.
> 
> 1.  None of the ASPA drafts (verification, profile and 8210-bis)
>     describe the transformation between the set of ASPA signed-objects
>     for a given CAS and the resulting VAP objects transmitted in the
>     payload of the 8210-bis "ASPA PDU".
> 
>     The mapping between the set of ASPA objects issued by a given CAS,
>     and the resulting VAPs is not trivial (as is the case for ROA/VRP),
>     and needs to be specified somewhere.

It is trivial. The VAP is equal to the ASPA object / profile. 
Plus draft-ietf-sidrops-aspa-verification-12 is very clear that objects
need to be merged:
    In case a CAS has multiple ASPAs, then the SPAS is the union of the
    Provider ASes listed in all ASPAs of the CAS.

The problem is that 8210-bis jumped the gun, invented its own
representation and now people think they need to invent new things because
of this.  I see no point in that. RTR is optional.

>     I'm unsure which of the three drafts is the best fit?
>     My feeling is that it should probably go in 8210-bis, but that might
>     be tricky given that it is already in the editor queue.

Maybe it is time to hit the breaks, unqueue it and fix it. 8210-bis has
some additional issues. The version negotiation is a mess.
 
> 2.  The above issue manifests in the context of this document in the
>     form of confusion about whether the data that the verification
>     considers is the ASPA object or the VAP.
>     For example in section 3, the structure of the ASPA is described as
>     being:
> 
>       { CAS, [PAS1, ... ], afiLimit }
> 
>     This is incorrect - in the ASPA profile, the afiLimit is a field on
>     *each* ProviderAS.
>     
>     The structure that should be described here is the VAP:
> 
>       { AFI, CAS, [ PAS1, ... ] }
> 
>     Similarly, section 5 talks about the content of the ASPA issued by 
>     ASi, when it should talk about the contents of the VAP.
> 
>     The document needs to be explicit in this distinction and consistent
>     in its terminology throughout.

See my mail to this list. I complain exactly about the same issue.

But I do not agree on your VAP structure.  CAS is the primary key.
 
> 3.  I still find the special-casing of IXP route-servers and other
>     specific business arrangements unhelpful and confusing. 
> 
>     My suggestion is that we have a section dealing with what
>     constitutes a BGP transit provider, in which we make it clear that
>     this includes IXP route-servers, siblings, geographical partial
>     transit, etc, etc. The remainder of the document can then simply
>     deal with whether one AS has authorised another as transit or not.

IXP route-servers are not providers and must not be included.
The only exception are non-transparent RS (the few that are still around)
because these RS act like providers.
 
Adding transparent RS to ASPA objects is just plain wrong and only blows
up the object which makes ASPA checks more (computationally) costly.

> 4.  I still find the algorithms as set out in sections 5 and 6
>     unintuitive and unnecessarily complex.
> 
>     I would like to suggest again that the WG re-considers the
>     "triple-wise" version previously proposed by Jakob and myself
>     some time ago [1].
> 
>     The algorithms are fundamentally equivalent, but the formulation in
>     terms of authorisation by left and right neighbors of each transit
>     in the AS_PATH is in keeping with operators' intuitive understanding of
>     the problem space, and is therefore far easier (in my experience) to
>     explain.
> 
>     To be clear - I can live with the current formulation if that's what
>     the WG decides. I just find it clunky.
> 
> 5.  In section 8, paragraph 1, the MUST is problematic.
> 
>     It will result in vendors implementing filters auto-magically and
>     preventing operators from using ASPA verification state in their own
>     filters.
> 
>     This is what happened in some implementations of ROV, and led to RFC
>     8481. Let's not make that mistake again.

I agree that the MUST is very strong there. I guess it was a reaction to
how ROA invalids were (mis)handled for a long time.
 
-- 
:wq Claudio