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

["Lubashev, Igor" <[e-mail]>]

Hi all,

I have two comments after reading the draft.

Comment 1.

ASPA Profile draft (3. ASPA eContent) says: "all Provider ASes MUST be registered in a single ASPA object".
ASPA Verification draft (4. ASPA Registration Recommendations) says: "An AS SHOULD NOT have more than one ASPA".

Since the two drafts are both in the WGLC, it is best if they adopt the same recommendation and choose a MUST or SHOULD here.  My view is that a SHOULD is more appropriate, since the Verification draft already specifies taking the union of ASPA registrations, so multiple registrations could work, albeit in a more fragile way (hence a SHOULD). But agreeing on SHOULD/MUST seems more important than which one is picked.


Comment 2.

I think the document would benefit from more discussion of security benefits during partial ASPA deployment (which is expected to be the case for many years to come).
Sections 8 and 12's optimism about being able to detect malicious hijacks from customers is premature during partial ASPA deployment.

Let's says Hijacker AS X (your customer) wants to hijack prefix P.  If there is no ROA for P, hijacker can just originate P from X.
Otherwise, the hijacker will perform a breadth-first search in ASPA to identify the shortest valid AP_PATH suffix that ends with a provider AS that did not register an ASPA and use that suffix for the hijack.

Detailed procedure:
Step 1. Let APS(n) be a AP_PATH Set (contain AS_PATHs of length n).
Step 2. For each AS (ASi) authorized to originate P in ROA, inset single-AS AS_PATH (ASi) into APS(1)
Step 3. Initialize LastAPS = 1
Step 4. For each AS_PATH ("APi") in APS(LastAPS):
Step 4.1.     Let "ASi" be left-most AS is in APi.
Step 4.2.     If ASi does NOT have an ASPA registration, announce P with AS_PATH constructed by appending X to APi. Done.
Step 4.3.     For each AS ("ASj") listed as a provider for ASi in ASPA, construct AS_PATH by appending ASj to APi and insert it into APS(LastAPS+1)
Step 5. Increment LastAPS by 1 and go to step 4.

If the hijacker is able to find a sufficiently short AS_PATH suffix that ends with a provider AS without an ASPA registration, the hijack is likely to succeed.

This attack allows anyone to hijack prefixes belong to ASes whose providers (transitively) did not register with ASPA.  This attack makes it important for providers who wish to make it more difficult to hijack their customers' prefixes to register with ASPA (and to request their own providers to do the same).  This is a great incentive for ASPA adoption, since the pressure would be coming from the customers.


The alternative attack is possible if the hijacker's own provider does not register with ASPA (and does not perform ASV).  The hijacker can set AS_PATH to (ASX, AS1), where AS1 is one of the ASNs in ROA for P. That announcement will reliably hijack traffic from other customer of the hijacker's provider, since it would effectively simulate ASX as a provider for ASX's own provider and as a lateral peer of AS1.

Best,

- Igor