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

[Russ Housley <[e-mail]>]

Sriram:

I do not think that we should tell implementers the reasons for using one table or two.

OLD:

For purposes such as computational efficiency, memory savings, etc.,	
an implementation may make its own choice regarding maintaining a	
single VAP-SPAS table or two separate tables (i.e., one per AFI).

NEW:

Implementations can maintain a single VAP-SPAS table or maintain a
separate table for each AFI.

Russ


> On Apr 19, 2023, at 6:14 PM, Sriram, Kotikalapudi (Fed) <[e-mail]> wrote:
> 
> Hi Igor, Claudio, Yangyang, Zhibin, and all,
> 
> I just uploaded version-14 of the ASPA verification draft.
> https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification
> Diff: https://author-tools.ietf.org/iddiff?url1=draft-ietf-sidrops-aspa-verification-13&url2=draft-ietf-sidrops-aspa-verification-14&difftype=--html 
> 
> This revision (v-14) takes into consideration the comments shared on the sidrops list since publication of v-13 -- from Claudio, Igor, Dai Zhibin, and Yangyang. 
> 
> Igor read the entire draft (pre-release v-14) and offered many editorial comments and also offered refinements to the Properties in Sec. 8. Thank you, Igor.
> 
> I have also carefully re-read and edited it for any remaining typos and grammatical errors, etc. 
> 
> Many thanks to all who have participated in the WGLC for very helpful suggestions, comments, and the insightful discussions.
> 
> Sriram
> 
> ============================
> -----Original Message-----
> From: Lubashev, Igor <[e-mail]> 
> Sent: Tuesday, March 28, 2023 10:43 PM
> To: Sriram, Kotikalapudi (Fed) <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: [Sidrops] WGLC = draft-ietf-sidrops-aspa-verification - ENDS 03/22/2023 (Mar 22 2023)
> 
> Thanks, Sriram.  Yes, some additional clarification for the properties would be helpful.
> 
> I think it would be valuable to mention another "mitigation property".  When an AS generates ASPA, it makes it less likely that prefixes belonging to its customers will be hijacked, if the customers also generate ASPA.
> A hijack attack that resists ASPA validation requires the hijacker to prepend its AS_PATH with a prefix containing the shortest possible sequence of ASNs identified as Providers in ASPA (transitively), starting from the hijacked ASN up to the first Provider ASN not in ASPA. When a provider generates ASPA, it forces attacker's AP_PATH to be one ASN longer, which reduces the likelihood of success of such hijack.
> 
> I think this could be a great business driver for ASPA adoption -- customers would be seeking out providers with an ASPA registration (and especially those whose providers also have ASPA registrations), since that would make their prefixes more resistant to hijacks. 
> 
> - Igor
> 
>