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

[Lancheng <[e-mail]>]

Yes, it helps. I agree with you that a blocklist cannot contain all unallocated & unrouted IPv6 prefixes, which is a very huge IP address space. It seems to me that there would be two ways to improve the use of blocklist.

1)     Loose uRPF + bicone’s blocklist. It is recommended that an AS uses loose uRPF and bicone’s blocklist together to check data packets from a customer or lateral peer AS. Loose uRPF will block source-spoofed data packets using unallocated/unannounced source addresses and bicone’s blocklist will block source-spoofed data packets using provider cone’s source addresses.

2)     Manual configuration. Bicone SAV aims at generating a blocklist that contains prefixes only belonging to the provider cone. Network operators can add/remove prefixes (e.g., special purpose prefixes) to/from bicone’s blocklist according to their own needs. How to modify bicone’s blocklist is an operational issue and requires operations recommendations.

Overall, the advantage of the blocklist over the allowlist is that even though it is incomplete, it would not have improper blocks (if it would fix case 3.2 as mentioned earlier) while can block more source-spoofed packets than solely using Loose uRPF.

More comments and suggestions are welcome.




Best,

Lancheng




-----Original Messages-----
From:"Sriram, Kotikalapudi (Fed)" <[e-mail]>
Send time:Friday, 09/20/2024 06:33:41
To: Lancheng <[e-mail]>
Cc: "Lubashev, Igor" <[e-mail]>, "IETF SIDRops" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Re: Call for Adoption of draft-li-sidrops-bicone-sav-04



>Lancheng: Can we add these special prefixes (that would not be used as a source IP address) into the blocklist

 

It is not just the special purpose prefixes. Think about how you would add to your blocklist all the prefixes corresponding to the unallocated & unrouted (and allocated & unrouted) IPv6 address space. Relatively only a little IPv6 is allocated & routed currently. So, there may be a minimum on the order of 2^32 = 4 Billion unallocated/unrouted /32 IPv6 prefixes. Or, there may be a maximum on the order of 2^48 = 256 * Trillion unallocated/unrouted /48 IPv6 prefixes.  In any case, if one is able estimate and list them all (keep in mind it is quite dynamical), the number is many orders of magnitude larger compared to the number of prefixes in Loc-RIB (which is about a million at present).  

>> So, in the end, it is an allowlist SAV (not blocklist). It is essentially the loose uRPF method with some prefixes removed. IMO, there is no concept of “blocklist” that can work as a SAV method.

>Lancheng: I do not think I understand this. According to the definition in [1], I think bicone sav uses a blocklist instead of an allowlist.

Does the above help in understanding?

Sriram

 

From: Lancheng <[e-mail]>
Sent: Thursday, September 19, 2024 1:53 AM
To: Sriram, Kotikalapudi (Fed) <[e-mail]>
Cc: Lubashev, Igor <[e-mail]>; IETF SIDRops <[e-mail]>; [e-mail]
Subject: Re: Re: Call for Adoption of draft-li-sidrops-bicone-sav-04

 

Hi Sriram,

Thank you for the comments.

> Because it currently admits all special purpose prefixes (https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml ), unallocated prefixes, and allocated but unannounced prefixes (not intended to be announced; having no ROAs).  For fixing this issue, bicone must be modified to use the approach of allowing all prefixes that are in the Loc-RIB [RFC 4271] minus the list of prefixes that can be perceived to originate *only* from the provider cone. 

Lancheng: Can we add these special prefixes (that would not be used as a source IP address) into the blocklist?

> So, in the end, it is an allowlist SAV (not blocklist). It is essentially the loose uRPF method with some prefixes removed. IMO, there is no concept of “blocklist” that can work as a SAV method.

Lancheng: I do not think I understand this. According to the definition in [1], I think bicone sav uses a blocklist instead of an allowlist.

> Even after doing the above, bicone still has no real directionality property to speak of.  It is only marginally better than loose uRPF.  It will still have improper blocking – in some multihoming scenarios with prefixes that are invisible in the CC.

Lancheng: IMO, the primary goal of SAV is avoiding improper blocks and then reducing improper admits. In terms of avoiding improper blocks, bicone sav would be better than existing allowlist-based SAV. In terms of reducing improper admits, bicone sav is better than loose uRPF. We are improving the current design of bicone sav to further eliminate improper blocks.

[1] https://datatracker.ietf.org/doc/draft-huang-savnet-sav-table/

Best,

Lancheng







-----Original Messages-----
From: "Sriram, Kotikalapudi (Fed)" <[e-mail]>
Send time: Thursday, 09/19/2024 06:25:19
To: Lancheng <[e-mail]>, "Lubashev, Igor" <[e-mail]>
Cc: "IETF SIDRops" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: Call for Adoption of draft-li-sidrops-bicone-sav-04

Hi Lancheng and coauthors,

 

[Igor wrote:] “… The “cost” is an improper admit of all prefixes originated solely by the AS’s customers and peers as well as an improper admit of all unannounced prefixes (although the latter can be easily fixed).”

 

In the process of fixing this, you’ll see that bicone SAV turns into an “allowlist” proposal as well.  To me it feels incorrect to position bicone as a “blocklist” SAV.  Because it currently admits all special purpose prefixes (https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml ), unallocated prefixes, and allocated but unannounced prefixes (not intended to be announced; having no ROAs).  For fixing this issue, bicone must be modified to use the approach of allowing all prefixes that are in the Loc-RIB [RFC 4271] minus the list of prefixes that can be perceived to originate *only* from the provider cone.  So, in the end, it is an allowlist SAV (not blocklist). It is essentially the loose uRPF method with some prefixes removed. IMO, there is no concept of “blocklist” that can work as a SAV method.

 

Even after doing the above, bicone still has no real directionality property to speak of.  It is only marginally better than loose uRPF.  It will still have improper blocking – in some multihoming scenarios with prefixes that are invisible in the CC.  OTOH, I think no improper blocking can be achieved in BAR-SAV through appropriate recommendations, certainly for ASes doing SAV that are one to two levels above the stubs where SAV is most effective.  We’ll provide details in the next version of the BAR-SAV draft.

 

Thanks.

 

Sriram