Hi Robert,
I just quickly reply to the concerns you mentioned as follows. Actually many of these issues have been discussed in the BOF or the mailing list. I also agree with Joel that the final technical conclusion will be made in the WG meeting. To help people who neither attended the BOF nor subscribed the mailing list better understand the SAVNET WG charter, I will summarize the discussion process of SAVNET WG charter in the SAVNET mailing list and send it out soon later.
[1] One thing to correct: SAVNET DOES NOT use a “block forwarding unless allowed” model. If some prefixes are not learned in a SAV table, the corresponding source addresses will not be filtered. In other words, only when a router successfully matches a source prefix and finds that the incoming interface is invalid, will it filter the packet. This model is the same as ROV filtering in RPKI. In this way, only after a router/AS announces its prefixes towards other routers/ASes by SAVNET, its prefixes can be protected from being forged by other routers/ASes. It can be viewed as an incentive for a router/AS to participate in SAVNET. This issue has once been clarified in the mailing list.
[2] Given path precomputing to avoid routing convergence upon failure, SAVNET can easily set the incoming interfaces of backup paths as valid, so there is no convergence problem in SAVNET, either. We once discussed this issue in the BOF, and you can refer to page 35 of the framework slides.
[3] For the reason why we think uRPF filtering at the edge is not enough, we also widely discussed in the mailing list. I just directly copy the previous paragraphs here.
For intra-domain:
1) For multi-connection. An access network can have multiple connections to different routers, and there may be routing asymmetry among the links (we have many such cases in Tsinghua campus network, and if you have interest I will give detailed examples for the reasons). In this case, uRPF cannot work because of routing asymmetry. Of course we can use static ACL to let each connected router only allow the source addresses belonging to the access network, but we need to manually do that at each connected router, which is error-prone. By the control-plane protocol, we can automatically synchronize the information among multiple connected routers by extending IGP protocol, which neither requires manual configuration nor has the improper block problem caused by routing asymmetry.
2) For partial deployment. In some cases, an AS is operated by multiple administrators. A typical example is AS 4538 (CERNET), which is managed by multiple universities. Some operators deploy ingress filtering while some not. In this case, if we still want to block the spoofed traffic from the operators who do not deploy ingress filtering, we have to launch uRPF in intermediate routers, which is easy to cause improper block problem. By the control-plane protocol, we have the advantage that “access networks in the undeployed area cannot spoof the source addresses of the deployed area”, which uRPF cannot provide. We used examples to show the benefit in the BOF meeting.
3) For router’s misbehavior. Another advantage of the control-plane protocol over ingress filtering is that, every router checks the SAV table to validate the incoming interface of a packet. This kind of “multi-facet” defense can help handle the cases where there are routers with misbehaviors along the path (e.g., compromised routers).
For inter-domain:
The best practice for inter-domain SAV is RFC 8704 (EFP-uRPF). We agree that “if a network does not deploy internal ingress filtering, then we cannot suppose that it will deploy the control-plane protocol”. But there are still many cases we can do better than RFC 8704. In the BOF meeting, we also use an example to show the benefit. Simply speaking, neighboring ASes who would like to deploy SAV mechanisms can form a “deployed area”, and the advantage of our solution over the current practice is that “ASes within the deployed area cannot spoof each other, and ASes in the undeployed area cannot spoof the source addresses of the deployed area”. If disconnected “deployed areas” can be logically connected (by crossing the “undeployed areas”), we can do even more.
Best,
Dan
发件人: savnet-bounces@xxxxxxxx <savnet-bounces@xxxxxxxx> 代表 Robert Raszuk
发送时间: 2022年6月6日 15:35
收件人: Aijun Wang <wangaijun@xxxxxxxxxxxxxxx>
抄送: Joel Halpern <jmh@xxxxxxxxxxxxxxx>; Adrian Farrel <adrian@xxxxxxxxxxxx>; Alvaro Retana <aretana.ietf@xxxxxxxxx>; Stephen Farrell <stephen.farrell@xxxxxxxxx>; The IESG <iesg@xxxxxxxx>; IETF-Discussion <ietf@xxxxxxxx>; savnet@xxxxxxxx
主题: Re: [savnet] WG Review: Source Address Validation in Intra-domain and Inter-domain Networks (savnet)
Aijun,
Your statement is way too broad and general.
The protection should apply to all prefixes and not to "some".
The foundation of SAVNET is to block forwarding unless allowed and to do it in many network locations. That to me is a main blocker to proceed with such an idea any further if this work is to see any production deployment(s).
Best,
R.
On Mon, Jun 6, 2022 at 5:35 AM Aijun Wang <wangaijun@xxxxxxxxxxxxxxx> wrote:
Hi, Robert:
I think the routing optimization mechanisms that you mentioned can also apply to SAVNET mechanisms, for example, some important source addresses can be pre-installed at the interlink ports/fallback path, which can work together with the redundant underlay routing information, to get the fast fallback based on local failure detection time.
Anyway, such considerations belongs to the solutions scope and I think we can investigate it deeply later.
According to the proposed SAVNET charters, the proposed WG should first determine the “Problems Statements, Use Cases and Requirements” and then the “SAVNET Architecture Documents”. The last is the “ Definition of routing protocol-independent operation and management
mechanisms to operate and manage SAV-related configurations.”
There certainly exists other solutions to mitigate your concerns, but I think we should first focus on the previous steps.
Aijun Wang
China Telecom
On Jun 4, 2022, at 18:15, Robert Raszuk <robert@xxxxxxxxxx> wrote:
Aijun,
[WAJ] SAVNET can utilize the ECMP path in the network. Upon the event of network failures, the SAVNET messages should be triggered again to update its SAVNET table to let the traffic pass the fallback path, done as that the convergence of IGP protocol, which I think can solve your concerns.
Here we touch the most important thing I am concerned about.
Building networks which depend on protocol convergence in the event of failure is worst possible choice.
We have learned that lesson many years ago and solved it by precomputing and pre installing repair paths based on redundant routing information. Connectivity restoration here only depends on local failure (full or partial) detection time. Some new designs can go even further and predict the failures too before they even happen.
It would be a huge disservice to any network to go back to medieval times to wait for convergence upon network failure.
No thank you !
Best,
R.
--
savnet mailing list
savnet@xxxxxxxx
https://www.ietf.org/mailman/listinfo/savnet
Hi Dan,
Thank you for extensive response. However unfortunately it does not address the major obstacle I see with SAVNET idea.
Namely:
Issue 1 - adding backup path to the mix of SAVNET filters does not help to address the issue. Backup paths say in the case of LFA (or TI-LFA) are computed dynamically and often change as frequently as topology changes. Likewise for EBGP peers same path may be received from may peers and picking randomly one may not be the one selected by BGP.
Issue 2 - There were some suggestions to use BGP to propagate SAVNET rules. Well for intradomain IBGP sessions are attached to loopbacks hence session does not determine the actual data plane interface. For EBGP we have very othen either multihop or disable-connected-check cases where multiple underlaying ASN to ASN links are used through recursion. Again eBGP session does not indicate interface. Last in many IXes RS is used and again information received via RS is by design not congruent with actual topology.
Issue 3 - The entire concept of SAVNET seems to be based on the new layer of per src + per interface filters. Well how would those filters work in cases of multi topology routing, multi instance IGP or even use of flex-algos ?
Issue 4 - As I am sure you are aware, the vast majority of transit networks use some form of encapsulation. That means that original src address is no longer visible in the packet. How does SAVNET idea works in such common deployments ?
Issue 5 - Number of network services use bypass of egress IP lookup. Examples could be L3VPNs with per CE or per prefix VPN labels or EPE for any traffic. Is SAVNET going to attempt to overwrite those applications and change the forwarding model in egress nodes ?
And this is just the tip of the iceberg here.
Best,
Robert
PS. And if possible for the issues which were already discussed and addressed please provide the pointer (URL) instead of a verbal statement.
On Mon, Jun 6, 2022 at 5:24 PM Dan Li <tolidan@xxxxxxxxxxxxxxx> wrote:
