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

[Yangyang Wang <[e-mail]>]

Hi, 

> 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.

Yes, this AS_PATH will be checked as "Unknown" at other customers of the
hijacker's provider, although AS1 registers its ASPA. 
But, if the hijacker's provider (which does not register with ASPA) does
perform ASV, it can check AS_PATH (ASX, AS1)  as "Invalid" and detect this
hijacking.  This implies that an ASPATH attack may be detectable or
undetectable at different vantage points before all ASes register ASPA. So,
it is better to recommend the provider ASes at higher tiers to perform
ASPATH validation with ASPAs, which can prevent the further propagation of
forged-origin prefix hijacks before they become undetectable.

Best, 
Yangyang


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Lubashev, Igor
> Sent: 2023年3月25日 8:08
> To: SIDR Operations WG <[e-mail]>; Sriram, Kotikalapudi (Fed)
> <[e-mail]>
> Subject: Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-verification - ENDS
> 03/22/2023 (Mar 22 2023)
> 
> 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
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops