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

[Claudio Jeker <[e-mail]>]

On Thu, Mar 23, 2023 at 04:20:51PM +0100, Martin Hoffmann wrote:
> Claudio Jeker wrote:
> > On Thu, Mar 23, 2023 at 01:22:32PM +0000, Amreesh Phokeer wrote:
> > > Hello,
> > > 
> > > Thank you to all those involved in this draft. We have reviewed the
> > > document and here are our comments:
> > > 
> > >   1.  Section 4: “An AS SHOULD NOT have more than one ASPA”
> > >      *   It should be clarified that one ASPA per AFI is tolerated  
> > 
> > In general this is a bad adivice and therefor should not be further
> > clarified.
> 
> I don’t think that’s what the comment is about. Rather, there is an
> inconsistency in the document. Section 4 first RECOMMENDS against using
> the AFI limit and then proceeds to say you SHOULD only have one ASPA
> objects. This can be interpreted that if you are using the AFI limit
> (which you are allowed to, it is just not recommended), you still can
> only have one ASPA object. So, if you use the AFI limit, you can only
> use ASPA for IPv4 or IPv6 but not for both. Surely that is not the
> intention?

Please check how the profile is specified. The AFI is per provider
AS. So there is no real concept of "only use ASPA for IPv4 or IPv6 but
not for both" (only RTR 8210bis does that).

My point is that if you have an ASPA object then the hop function no
longer returns "no Attestation" for your AS. It can only return "provider"
or "not provider". The path down a road where that is not the case is an
operational nightmare.
 
> > As with all ASPA objects the RP software and router must
> > build the union of all providers per CAS. Now one could issue an
> > object per provider and AFI but it is not a very sensible thing to do.
> > 
> > The CAS is the primary lookup key.
> 
> Is it? In RTR, an ASPA entry contains both a mandatory customer AS and
> a mandatory AFI -- you cannot say “this entry is for both.” This means
> that in RTR land, the ASPA sets for IPv4 and IPv6 are distinct. The
> primary key is the pair of customer AS and AFI.

The thing is RTR is not ASPA. It is just a transport protocol to move
data and it is optional (our first implementation did not use RTR and most
of my routers do not use RTR either but do ROA and ASPA validation).
So RTR should follow the ASPA profile and validation standards and not the
other way around.

> This is the disconnect I mentioned earlier -- perhaps I posted this to
> the wrong thread. The verification draft talks about things in terms of
> the ASPA objects published but a router actually implementing it has to
> build its data structures based on RTR.

I know about this disconnect and I argue the way to fix this is in 8210bis.

I have a major issue with duplicating the CAS lookup table. The
implication for BGP implementations is twice the memory consumption and
more then double the computational cost and that in the most latency
sensitive portion of the code. A lot of time is spent in getting the most
performance out of BGP and so this should be a major consideration when it
comes to ASPA validation.
 
> Thus, the verification draft follows your argument: Don’t use the
> afiLimit, have one ASPA object for your customer ASN. But 8201bis then
> twists that around and has a mandatory AFI field on the RTR PDU.

Yep. 8210bis is at fault here.

> Given that this is already leading to confusion here, it should
> probably be resolved before publishing.

Absolutly agree with that.
 
> > >   2.  VAP: it is unclear whether how the VAP will be merged but
> > > grouped by AFI in the case of multiple ASPAs?  
> 
> That the sets of provider AS of multiple ASPA objects for the same
> customer AS should be merged is only mentioned in 8210bis but at no
> point in either the profile or verification drafts. One of them should
> probably spell out how the (on or two) VAPs for a customer AS are to be
> created from a the set of ASPA objects.

In draft-ietf-sidrops-aspa-verification-12 Section 3:
If a CAS has a single ASPA, then the SPAS for the CAS are the Provider
ASes listed in that ASPA. In case a CAS has multiple ASPAs, then the SPAS
is the union of the Provider ASes listed in all ASPAs of the CAS.

Now this is not perfect but VAP are Verified ASPA Payloads and by that the
above statement still applies to them since VAPs are still ASPA objects.
In the end a router must support multiple sources that provide Verified
ASPA Payloads and will need to build the union of all these sources. This
is how ROA works and I see no other way for ASPA.

The situation right now is a mess and I fear that I caused this sudden
rush because I implemented all three drafts. I would prefer to not rush
and instead use the feedback from this implementation and fix the
remaining issues.

-- 
:wq Claudio