Re: [savnet] Fw: New Version Notification for draft-li-sidrops-bicone-sav-00.txt

Thank you for your explanation. It is a good question.

Before responding to your question, I would like to clarify that Bicone SAV does not intend to replace allowlist with blocklist. It suggests to use an additional blocklist to avoid improper block caused by the allowlist. When the allowlist is proven to reach 0 improper block, allowlist alone will suffice. Therefore, I think Bicone SAV would be a good solution in transitional period until we ensure that the allowlist can achieve 0 improper block.

> [Sriram]: The Bicone proposal makes source address (SA) in the prefixes that are not in the blocklist or the allowlist to be "allowed". That means that effectively only the SA in prefixes in the blocklist are blocked on ingress on a customer interface and any other SA is permitted. So, the allowlist is not really used. Improper admits would increase a lot. This points to the design flaw. Simple example: Consider AS A and AS B are lateral peers. AS A is doing Bicone on its customer interfaces. Bicone makes SA in the prefixes in the customer cone of AS B allowed on AS A's customer interfaces.

[Lancheng]: The primary design goal of SAV is avoiding improper block while maintaining directionality. Your example is correct and avoiding improper block is the first goal of Bicone SAV. Using both allowlist and blocklist can avoid improper block while preventing ASes in the customer cone from using source addresses in the provider cone. So, I think this aligns with the design goal. In addition, checking the allowlist first can avoid improper block when a source prefix is in both allowlist and blocklist. So, the allowlist is actually used.

> [Sriram]: In trying to solve the NO_EXPORT situation, a much more important thing is overlooked by Bicone. I think BAR-SAV gets it right. If an AS has the unusual NO_EXPORT on all prefixes towards a provider, it should have an ASPA. This fixes the issue. Also, we may be making a bigger issue of "all prefixes having NO_EXPORT" than what might be true. I mean it might be very rare or non-existent. Usually, when more-specific prefixes have NO_EXPORT, there would be a covering less-specific prefix that propagate everywhere.

[Lancheng]: I agree this situation might be less usual. But once it exists, SAV solutions solely using an allowlist may block legitimate traffic. I think this is why RFC8704 particularly analyses this situation in Section 3.3 and proposes the EFP-uRPF Algorithm B. I also agree that the improper block problem of allowlist can be addressed if we can get ASPAs of some ASes. But determining which ASes must deploy ASPAs and waiting for those AS to do so takes time and effort, because having an ASPA is optional, not mandatory. 

Next, I am planning to make some measurements to analyze the feasibility of Bicone SAV. Thank you.

Best,
Lancheng

> -----原始邮件-----
> 发件人: "Sriram,
>  Kotikalapudi (Fed)" <kotikalapudi.sriram=40nist.gov@dmarc.ietf.org>
> 发送时间:2024-03-19 23:18:58 (星期二)
> 收件人: "Lancheng Qin" <qlc19@mails.tsinghua.edu.cn>, "savnet@ietf.org" <savnet@ietf.org>
> 抄送: "Ben Maddison" <benm@workonline.africa>
> 主题: Re: [savnet] Fw: New Version Notification for draft-li-sidrops-bicone-sav-00.txt
> 
> Hi Lancheng,
> 
> You requested me to explain in more detail my comment yesterday during your presentation on this draft in the SAVNET meeting.
> 
> The Bicone proposal makes source address (SA) in the prefixes that are not in the blocklist or the allowlist to be "allowed". That means that effectively only the SA in prefixes in the blocklist are blocked on ingress on a customer interface and any other SA is permitted. So, the allowlist is not really used. Improper admits would increase a lot. This points to the design flaw. 
> 
> Simple example: Consider AS A and AS B are lateral peers. AS A is doing Bicone on its customer interfaces. Bicone makes SA in the prefixes in the customer cone of AS B allowed on AS A's customer interfaces.
> 
> In trying to solve the NO_EXPORT situation, a much more important thing is overlooked by Bicone. I think BAR-SAV gets it right. If an AS has the unusual NO_EXPORT on all prefixes towards a provider, it should have an ASPA. This fixes the issue. Also, we may be making a bigger issue of "all prefixes having NO_EXPORT" than what might be true. I mean it might be very rare or non-existent. Usually, when more-specific prefixes have NO_EXPORT, there would be a covering less-specific prefix that propagate everywhere.
> 
> Thanks.
> 
> Sriram
> -- 
> savnet mailing list
> savnet@ietf.org
> https://www.ietf.org/mailman/listinfo/savnet