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

[Ben Maddison <[e-mail]>]

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.

    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.

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.

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.

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.

Cheers,

Ben

[1]: https://github.com/benmaddison/aspa-fuzz/blob/master/aspa/heitz_maddison/procedure.md