Re: [Sidrops] Making ASPA AFI-Agnostic - coordination (Was: WGLC = draft-ietf-sidrops-aspa-verification - ENDS 03/22/2023 (Mar 22 2023))

[Ties de Kock <[e-mail]>]

Hi Job,

This is a very big last minute change we are proposing. It feels ironic to do
this now given that profile changes last July were “too late”. But better late
than never I guess :).


> On 6 Jun 2023, at 23:13, Job Snijders <job=[e-mail]> wrote:
> 
> Dear Chris, others,
> 
> Let me start of by responding to "Are there complaints you'd like to
> swing my way? :)" - Quite the opposite! I very much appreciate your
> co-chairing work (and Russ, and Keyur, you all serve as volunteer!).
> Developing an understanding of the movements in the sidrops@ working
> group can take up considerable time and attention: the mailing list is
> very active, and the stakes are high: problems in products produced by
> SIDROPS usually mean problems for the whole Internet.
> 
> On Tue, Jun 06, 2023 at 04:41:07PM -0400, Christopher Morrow wrote:
>> So, first I think we pull this draft back from the edge of publication
>> and address at least one point which seems to have gotten some fair
>> time at the mic:
>> "Should the ASPA content be AFI specific? or AFI Agnostic?"
>> 
>> It seems to me that there are both sides being discussed with what
>> looks like a reasonable end at: "AFI Agnostic please" This makes some
>> sense to me, at least, since generally though we MAY have disjoint
>> (not the same?) forwarding paths for v4/v6 we probably have reasonable
>> ideals that our v4/v6 transit/customer relationships are fairly well
>> aligned. It may be the case that there are folks with this sort of
>> deployment, they should be able to publish correct ASPA records, I
>> believe.
>> 
>> I think a side effect of this decision (AFI agnostic ASAP) is that we
>> need to rethink/redo a bit of 8210bis, which I think was shipped at
>> IESG for publication 'just recently' :(
>> 
>> Does the above make enough sense to roll forward with? :)
> 
> Yes, it does for me. Below is a (perhaps incomplete) todo-list of what
> needs to happen next to swiftly move to AFI-agnostic ASPA. I've taken
> the liberty to assign names to each task (as suggestion... :-)).

For the RIPE NCC, our validation, object signing, web API, and testing setup
need to change. The change will delay our production release significantly (for
v0, our implementation is complete, while the new work needs to be planned).
 
> 
> * draft-ietf-sidrops-aspa-profile needs changes to the ASN.1, the
>  DER-encoded examples, and some blurps of text. As part of this change 
>  the ASPA profile version will be increased to 1 to avoid clashes with
>  existing work. Note: this will be the first Signed Object profile with
>  a explicit non-zero version in the eContent. [JOB]
> 
> * draft-ietf-sidrops-aspa-verification needs changes to align with the
>  new profile. [AZIMOV or SRIRAM?]
> 
> * draft-ietf-sidrops-8210bis-10 needs to be pulled back out of the RFC
>  Editor queue, I suspect that our AD needs to arrange that [WARREN]
> 
> * Either the authors of draft-ietf-sidrops-8210bis-10 (or newly
>  assigned volunteers) need to update the 8210bis specification, taking
>  into account lessons-learned from the 8210bis implementation efforts
>  (StayRTR, OpenBGPD, Routinator, etc).
>  The RTR version number needs to be bumped.
>  I hope Randy and Rob want to continue work on 8210bis, but if not - me
>  and Claudio would be available as co-authors to specify the required
>  changes.
> 
> * Signers need to be updated so RP implementations have something to
>  test against. Tim's earlier work in which he made a test TAL with some
>  test objects was massively helpful.
>   - krill / krill testbed [TIM]
>   - rpkimancer [BEN]
>   - any others?
> 
> * RP implementations with ASPA support need to be updated
>  - rpki-client [JOB]
>  - Routinator [MARTIN]
>  - RPSTIR2 [DIMA]
>  - rpki-prover [MIKHAIL]
>  - others?
> 
> * RTR server implementations need to be updated:
>  - StayRTR [BENCOX or JOB?]
>  - RTRTR [MARTIN]
>  - any others?
> 
> * BGP implementations need to be updated both in RTR handling and in BGP
>  UPDATE verification:
>  - OpenBGPD [CLAUDIO]
>  - BGP-SRx [NIST]
>  - any others? (I am not aware of other BGP implementations with ASPA)
> 
> * Existing deployments need to be updated when the above are completed
>  - YYCIX [JOB]
>  - not aware of any other ASPA-verification deployments
> 
> Did I miss anything in the above?
> 

I think rpki-prover is missing from the list. Furthermore, there are some
private implementations of 8210bis. I agree with Claudio's strong preference
not to complicate version negotiation in the RTR protocol more.

What is also lacking (and does not exist for all objects after ROAs) is a
conformance test cases for the objects. We have recently seen issues where
_valid_ ASPA configurations caused an RP implementation to create broken JSON:
If we want to make changes on a compressed timeline, I think having conformance
tests is key.


Kind regards,
Ties