RE: [savnet] WG Review: Source Address Validation in Intra-domain and Inter-domain Networks (savnet)

["Dan Li" <tolidan@xxxxxxxxxxxxxxx>]

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