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

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

Hi Martin,

>Now, from the split into two documents, I conclude that as someone
>implementing an RPKI relying party software, you aren’t expected to
>read the verfication draft -- and will likely miss this subtlety. So,
>presumably, the conversion rules should be in the profile draft.

We'll make sure that it is clear in the verification draft, and 
also, some sections related to ASPA registration and VAP-SPAS 
creation will be repeated in the profile draft so that 
the latter is self-contained.

Regarding augmentation of VAP-SPAS with AS 0 SPAS for
the case of a CAS that has neglected to include one of the
AFIs in the ASPA, that is a thing that concerns the 
verification algorithm. Keeping that in mind, do you feel that
it might be OK if we simply take care of it on the router side
after the RTR ASPA PDUs have been received? Details follow.

That is, we do not worry about the augmentation when
the RTR cache server creates and sends the ASPA PDUs.
Instead, after all the RTR PDUs have been received,
any need for augmentation of the AS 0 SPAS (mentioned above) 
will be handled only on the router side.

Now there are two ways:

1. From the RTR PDUs, create a single VAP-SPAS table as follows: 

Col 1                  Col 2                                 Col 3
CAS       VAPS-SPAS for AFI=1       VAPS-SPAS for AFI=2

Either Col 2 or Col 3 entry may be empty in the scenarios when
an AFI has been neglected by a CAS in its ASPA.

This single table works just fine for the computation of the hop(...)
function in Section 5.

2. From the RTR PDUs (not augmented), create two VAP-SPAS tables 
one per AFI. Now the need for the augmentation may arise.
If there is a CAS in Table 1 (corresponding to AFI = 1) that 
does not show in Table 2 (corresponding to AFI = 2), then
that CAS is augmented in Table 2 with AS 0 SPAS, and vice-versa.

We can mention both of the above approaches as example
ways of implementation that would enable the path verification
algorithm to work correctly. We can include these descriptions
in both drafts so everyone one is well informed whether they read
only the profile draft or both.

Does this seem acceptable?

If not, then we need to talk about changing the processing
on the RTR cache server side or changing the RTR ASPA PDU format
(like what Claudio has been talking about). That would call
for a change in 8210-bis. 

Thank you.

Sriram

============================
Hi Sriram,

my apologies for continuously beating the same drum, but I am not sure
I can accept that the draft is quietly ignoring the different data
structure in RTR. Specifically, I just realized that I may or may not
have implemented the conversion from ASPA objects to RTR payload
wrongly in Routinator.

If for a given customer AS there are no provider AS for a requested
address family but there are for the other address family, the hop
function will result ‘no providers+’ rather than ‘no attestation.’
If the verification algorithm is implemented on individual per-family
provider sets, this means the provider set for that address family is
basically an AS0-only set.

Consequently, when transforming the provider set from an ASPA object
into its RTR payload, an AS0-only PDU should probably be added for a
customer AS that if the provider set for an address family turns out to
be empty. Otherwise a router keeping separate tables has to consult the
table for the other family any time there is no entry for a given
customer AS and that rather defeats the purpose.

Now, from the split into two documents, I conclude that as someone
implementing an RPKI relying party software, you aren’t expected to
read the verfication draft -- and will likely miss this subtlety. So,
presumably, the conversion rules should be in the profile draft.

But similarly, someone who only implements validation in a router and
starts out with the RTR payload data will be confused by the validation
algorithm working with something completely different. There’s a good
chance there are subtle and unexpected consequences there, too.

I feel that if we keep describing the validation algorithm in its
current form, the conversions should be addressed explicitly so that
it is clear how may ASPA RTR PDUs will there be for a given customer
AS, what will be in a provider AS set in each, and what that means for
the validation algorithm.

  -- Martin