[Sidrops] Re: Call for Adoption of draft-li-sidrops-bicone-sav-04

[Lancheng <[e-mail]>]

> OTOH, in the allowlist approach (e.g., BAR_SAV), the requirement for the AS operators using NO_EXPORT is to register ASPA and if a customer AS of a provider AS is doing NO_EXPORT then the provider must require the customer to have ASPA.  (In general, all compliant ASes are anyway required to have ASPA.)  


IMO, a SAV solution can use existing third-party data (e.g., IRR route object, RPKI ROA object, RPKI ASPA object), but it is difficult to force certain AS to register this data. Even RPKI does not force some ASes to register ROAs or ASPAs. 


As a result, we must consider the incremental or partial deployment scenario when some ASes do not register ROAs or ASPAs. In this scenario, as I analyzed in my last email, blocklist is better at reducing improper block than allowlist. Even if we could enhance the blocklist/allowlist by encouraging some ASes to register ROAs or ASPAs, using bicone SAV would require fewer AS to register ROAs or ASPAs, which would be more likely to be achieved.







Lancheng



-----Original Messages-----
From:"Sriram, Kotikalapudi (Fed)" <[e-mail]>
Send time:Tuesday, 09/03/2024 10:45:21
To: Lancheng <[e-mail]>
Cc: "Russ Housley" <[e-mail]>, "IETF SIDRops" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: [Sidrops] Re: Call for Adoption of draft-li-sidrops-bicone-sav-04



Considering your four scenarios, it makes no sense to tell the network operator doing SAV, “take a chance, deploy bicone, and hope that scenario #4 does not happen”. They have no way to know that only your scenarios #1, #2, or #3 could happen in their surroundings and scenario #4 does not (will not) happen.  The solution must address all scenarios (involving NO_EXPORT). Otherwise, it is not a solution at all for scenarios involving NO_EXPORT.

 

OTOH, in the allowlist approach (e.g., BAR_SAV), the requirement for the AS operators using NO_EXPORT is to register ASPA and if a customer AS of a provider AS is doing NO_EXPORT then the provider must require the customer to have ASPA.  (In general, all compliant ASes are anyway required to have ASPA.)  This ensures the completeness of the allowlist.  Including said requirement as part of an overall security hygiene is doable. 

 

Sriram      

 

From: Lancheng <qinlc=[e-mail]>
Sent: Thursday, August 29, 2024 4:36 AM
To: Sriram, Kotikalapudi (Fed) <[e-mail]>
Cc: Russ Housley <[e-mail]>; IETF SIDRops <[e-mail]>; [e-mail]
Subject: Re: [Sidrops] Re: Call for Adoption of draft-li-sidrops-bicone-sav-04

 

Hi Sriram,

 

I would like to clarify the goal and rationale for the bicone sav. 

 

If the allowlist is complete, using allowlist is the best choice because it has the fewest improper admit (ideally 0). However, the presence of NO_EXPORT may result in an incomplete allowlist (RFC8704 also points out this problem and tries to address this problem). If using an incomplete allowlist, it will block data packets using a legitimate source address, i.e., improper block. Bicone SAV aims at reducing improper block when the allowlist is incomplete. I hope we can first reach a consensus on this goal, then we can discuss the rationale and performance for Bicone SAV.

 

I summarized four different NO_EXPORT scenarios and analyzed allowlist and blocklist in terms of improper block (attached). In summary, compared to using allowlist (when it is incomplete), Bicone SAV helps reduce improper block in most NO_EXPORT scenarios (this is the gap which Bicone SAV fills). In the very corner case of NO_EXPORT (i.e., Scenario #4 where the prefix is using NO_EXPORT as well as multi-homed to provider cone and customer cone), both allowlist and blocklist have improper block problem (this is the gap which both blocklist and allowlist do not fill).

 

I do not think bicone sav is a perfect SAV solution that can address any problem. The main improvement by bicone save is to reduce improper block. Meanwhile, it does not lose directionality as loose uRPF does. It can prevent an AS in the customer cone from forging a source address belonging to the provider cone. As such it provides another way for network operators to deploy SAV before all ASes in the customer cone have registered ASPAs.

 

Best,

Lancheng







-----Original Messages-----
From: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram=[e-mail]>
Send time: Thursday, 08/29/2024 04:18:41
To: "Russ Housley" <[e-mail]>, "IETF SIDRops" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: [Sidrops] Re: Call for Adoption of draft-li-sidrops-bicone-sav-04




This is a *technical review* of the draft.
 
Top level comments:
 
I must respectfully decline to support its acceptance as a Working Group draft at this time. I appreciate the authors' understanding. My reasons are as follow:
 
(1)  Bicone seems to have a fundamental design flaw. It starts out saying that it seeks to fill a gap (a corner case of NO_EXPORT scenario) that the "allowlist" approach (e.g., BAR-SAV) may have, but then the draft acknowledges it cannot accomplish that with "blocklist" for multi-homed prefixes (Sec. 6.3) and it reverts to "allowlist" to try to fill the gap.  It is somewhat paradoxical. BAR-SAV (allowlist) has already proposed ways to fill the gap with the use of ASPA. If the BAR-SAV-recommended ASPAs are created by ASes in the customer cone for the NO_EXPORT cases, the gap would no longer exist.  Bicone needs this to function. But if the gap is filled by BAR-SAV, the rationale for proposing bicone seems to go away. I have included below a more detailed explanation of the design flaw in bicone with a figure (attached).  (Note: Nan Geng has also raised this issue.)
  
(2)  The bicone proposal essentially ignores the directionality goal. Bicone seems nearly equivalent to doing loose uRPF (no directionality) with a high rate of improper admits.  On customer facing interfaces, bicone disallows only the prefixes originated by the ASes in the provider cone (maybe about 50 ASes on the generous side) of the AS in consideration while it undesirably (loosely) permits the prefixes originated by much of all other ASes in the Internet (about 75,000 ASes).  The performance would be quite poor in terms of improper admits.   
 
(3)  The idea of gathering provider prefixes of an AS from ASPAs and ROAs can be used at best as a cross-check on how many of the same prefixes are in the customer cone (based on allowlist) and hence appear to be muti-homed.
----------
 
Detailed comments:    
 
#1 Performance modeling: There are about 1 million prefixes (v4 + v6) in the Internet.  Let us say that an AS doing bicone has 6 providers and each provider has 8 Tier-1 providers.  So, the provider cone has about 50 ASes (a generously high estimate).  If each AS (amongst the 50) originates 100 prefixes on average, then there would be 5,000 provider cone prefixes. There may be 10,000 customer cone prefixes (generously). Thus, only those 10,000 should be allowed for SAV but instead (1,000,000 – 5,000 -10,000) = 985,000 prefixes are undesirably (loosely) allowed by bicone. This indicates lack of directionality and high improper admit.
 
#2 Rationale for the bicone SAV is lacking: The bicone draft provides this text as the rationale for bicone in Sec. 3: “When some ASes in the customer cone do not register ASPAs or ROAs, the SAV solution will still fail to discover all prefixes in the customer cone. If the allowlist is not complete, it will improperly block data packets using legitimate source addresses.” In Sec. 6.3 it says, “To avoid improper block, the blocklist must remove prefixes that also belong to the customer cone. These prefixes can be identified by computing the overlap between blocklist and allowlist.”  So, when these two observations are put together in the NO_EXPORT scenario, the rationale for the bicone SAV falls apart with BAR-SAV implemented properly with ASPAs to include the prefixes with NO_EXPORT in the allow list. This is explained with a figure in the attached pdf.
 
Regards,
Sriram
_______________________________________________
Sidrops mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]