Re: [savnet] SAVNET WG charter

[Dan Li <[e-mail]>]

Hi Ben,

 

I really enjoy the discussion with you. Your concerns/challenges actually help us make the high-level contribution more clear. So I am highly appreciated for them.

 

For intra-domain case: 

1) the key problem of routing asymmetry in multi-connection is the information mismatch between multiple connecting routers. Extending IGP protocol is the easiest way to automatically share the information among them. This can be part of DSAV. Manually solving this problem by ACL-based ingress filtering should also work, but we think that a protocol-based automatic mechanism will be always better; 

2) yes partial deployments will remain partial, but we used examples to show that deploying DSAV-like protocol in a group of routers will bring additional benefit compared with deploying uRPF in the same group of routers; 

3) yes a compromised router can forge SAV protocol messages, but note: if using ingress filtering, a compromised edge router will cause all the corresponding attached hosts spoof whatever addresses; while DSAV-like protocol can prevent this from happening, because other normally behaved routers will notify their prefixes along the real forwarding path and thus these prefixes can be protected by normally behaved intermediate routers.

 

For inter-domain case:

1) Yes you are right that “an island of cooperating and mutually-trusting networks to enforce a common border policy that prevents spoofing of on-island addresses from outside of the island.” But the destination addresses of such DDoS attack can be far away. If the outside-island hosts spoof the on-island addresses to attack a remote target, these packets can be filtered by the island (if the traffic traverse the island). The island has incentive to do this, because otherwise these source addresses may be blocked by the attacking target and the island would be the innocent victim.

2) Our approach is not limited to a single “island”. As I said: if disconnected “deployed areas” can be logically connected (by crossing the “undeployed areas”), we can do even more. Specifically, multiple disconnected islands can form an “alliance” to protect their addresses from being forged by “outside-alliance” networks. But of course there is more challenge than a single island, because the real forwarding paths in the intermediate “undeployed areas” are block boxes. 

 

Anyway, we are not arguing that our current solution is complete. But based on the current works we are confident that we can do more than existing uRPF-based technology, in both intra-domain and inter-domain scenarios. So in the charter, we do not want to set the “limit” to what we currently have done. We are also looking forward to widely cooperating with colleagues in the community for the final solutions. That said, your suggestion about making the charter more clear is really helpful. We will make the modification after learning more feedbacks.

 

Best,

Dan

 

发件人: Ben Schwartz <[e-mail]> 
发送时间: 2022年5月2日 22:33
收件人: Dan Li <[e-mail]>
抄送: Joel M. Halpern <[e-mail]>; [e-mail]
主题: Re: [savnet] SAVNET WG charter

 

Thanks for helping me understand this topic, Dan.  To summarize, it sounds like the main additional guarantee offered by a DSAV-like protocol is that it allows an "island" of cooperating and mutually-trusting networks to enforce a common border policy that prevents spoofing of on-island addresses from outside of the island.  Perhaps the charter could focus on this explicitly.

 

For the intra-domain cases, I don't see an advantage.  Multi-connection (1) can still be solved by ingress filtering at the edge, avoiding any concern about asymmetry.  We seem to agree that AS operators without ingress filtering are unlikely to participate in a new SAV protocol, so partial deployments (2) will remain partial.  A compromised router (3) could forge SAV table updates along with IP addresses.

 

An "island-oriented" approach does not appear to be a good fit for DDoS concerns, in which the source and destination addresses are generally far apart.  I think the charter should probably identify at least one specific class of attack that we hope to mitigate significantly by this work.

 

On Fri, Apr 29, 2022 at 9:40 PM Dan Li <[e-mail] <mailto:[e-mail]> > wrote:

Thank Ben for the detailed comments, and I feel glad that we have opportunity for detailed discussion which we do not have enough time to cover in the BOF meeting.

 

I use the term of “node” to represent a “router” in intra-domain network or an “AS” in inter-domain network. We defined this term in the framework draft for the BoF. Sorry for the confusion to people who did not read the draft.

 

Let’s first discuss the intra-domain scenario. To my knowledge, ingress filtering refers to BCP 38 or RFC 2827, which suggests static ACL at the edge routers to filter spoofed packets. uRPF is defined in RFC 3704. But let’s suppose the “best practice” as either deploying static ACL or deploying uRPF at edge routers for future discussions. The control-plane solution proposed in the BOF has the following advantages over the best practice.

 

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).

 

Then let’s go to the inter-domain scenario. 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.

 

For better understanding the motivations and solutions, I attach the slides presented in the BOF meeting. Actually, in the BOF presentation we have listed almost 10 open questions, which we expected to widely discuss with the community. But it seems that a 2-hour meeting is too short to cover the details. We plan to summarize all the questions proposed in the BOF meeting as well as our thoughts, and send it to the mailing list soon later.

 

Best,

Dan

 

 

发件人: Ben Schwartz <[e-mail] <mailto:[e-mail]> > 
发送时间: 2022年4月29日 23:51
收件人: Dan Li <[e-mail] <mailto:[e-mail]> >
抄送: Joel M. Halpern <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
主题: Re: [savnet] SAVNET WG charter

 

I don't understand this taxonomy, because I don't understand what a "node" is.

 

As noted in the MANRS documentation (https://www.manrs.org/isps/guide/antispoofing/), IP spoofing is most easily prevented by ingress filtering.  To my understanding, this is essentially uRPF at the source, where uRPF is safe.

 

Inter-domain SAV only matters if there are some networks that are not doing straightforward ingress filtering internally. If a network is not willing to do this, then surely it will not participate in any fancier SAV or BGPSEC scheme.  Thus, conditions "a" and "b" are both false in the only case we care about, and the mitigations in point 3 seem unlikely to be applied.

 

Against this backdrop, I don't see how control-plane SAV is worthwhile in an inter-domain setting.  If the charter is restricted to control-plane SAV, I would encourage it to use stronger language emphasizing that only intra-domain SAV is in scope.

 

I would also appreciate a clearer description of what the intra-domain SAV problem is.  At present, I know of two intra-domain SAV problems:

 - Preventing sources inside the network from spoofing addresses not allocated to them.  This is solved by ingress filtering at the source (allowing only source IPs allocated to this port).

- Preventing sources outside the network from spoofing addresses of this network on packets that traverse this network.  This is solved by dropping any incoming packets at the border whose source IP is inside the network.

 

Neither of these defenses seems to require a new SAV protocol.

 

On Fri, Apr 29, 2022 at 4:05 AM Dan Li <[e-mail] <mailto:[e-mail]> > wrote:

Dear Joel,

 

Thanks for your explanation. 

 

As for the “guarantees we can get from a control plane solution”, what we can provide by the current design is as follows. 

1)       If a) all the nodes participate, and, b) nodes behave properly, and, c) in the steady state (there is no topology/routing/prefix dynamics), then the control-plane solution can guarantee there is no improper permit and no improper block. This is what uRPF cannot achieve.

2)       If assumption a) is broken, i.e., only partial networks deploy, then we can guarantee that the deployed networks get benefit. IOW, the solution supports incremental deployment and incentive.

3)       If assumption b) is broken, i.e., some nodes misbehave, then we can leverage the BGP security related mechanisms to address the problem. This is also explained in my previous email.

4)       If assumption c) is broken, i.e., there is inconsistency between the routing sates and the SAV states during the converging interval, improper block may occur. But it is similar as packet drop from temporal loops during the convergence of routing protocols, and we will also use various ways to minimize improper block. I remember we have largely discussed this issue with Jari in the mailing list before the BoF meeting.

 

That said, I think more complete solutions can come out in the potential WG.

 

Best,

Dan

 

 

发件人: savnet [mailto:[e-mail]] 代表 Joel Halpern
发送时间: 2022年4月29日 10:51
收件人: Dan Li <[e-mail] <mailto:[e-mail]> >; 'Ben Schwartz' <[e-mail] <mailto:[e-mail]> >
抄送: [e-mail] <mailto:[e-mail]> 
主题: Re: [savnet] SAVNET WG charter

 

Thank you for continuing to move this work forward.

 

I do think that focusing on the control plane, and initially on the intra-domain aspects, is the better path.  Once we know what we can achieve in the intra-domain parts, we can then build from there for inter-domain.

I do sympathize with the implicit concern in Ben's email that it will be hard to formalize and quantify the guarantees we can get from a control plane solution.  On the other hand, redesigning IP packet headers and forwarding to solve the SAV problem seems to be the wrong approach.

 

Yours,

Joel

On 4/28/2022 10:35 PM, Dan Li wrote:

Thank Ben for the reply.

 

Sorry that I omitted some details about the decision process from the ADs. Yes in the BOF we presented both control-plane and data-plane solutions. The pros and cons of the two directions of solutions are clear as you described. There is only one more issue I want to add. In the MANRS initiative, it is called upon that SAV should be deployed as close to the source as possible, so as to better defend against DDoS attack. If the SAV mechanism is deployed at the destination, actually the DDoS attack is already successful. So one more advantage of control-plane solution over data-plane solution is that, there is opportunity to filter the spoofed traffic in the intermediate networks, instead of processing at the destination network.

 

Even so, we did not make any justification or selection between the two directions of solutions. The ADs think that the control-plane solution is more close to the Routing Area (because we need to make extensions to existing routing protocols), so it is suggested to apply for a WG in the Routing Area, which focuses on the control-plane solution. That’s why in the first email we said “forming a WG with a relatively narrower scope”. As you said, the discussions about security related issues are inevitable for the control-plane solution. Our current thought is that, any solution to BGP security can be leveraged to solve the security problem in SAV protocols, such as BGPSEC, RPKI, etc. Anyway, we will modify the charter to add these issues. I believe the discussions will also be interesting.

 

Considering the cost, data-plane solutions may be a relatively longer-term direction. But it has rare relationship with routing protocols, so we did not include it in this Routing-Area WG. Maybe proposals for data-plane solutions can go to other Areas? Of course, we also would like to get more feedback from our community.

 

Best,

Dan

 

发件人: Ben Schwartz  <mailto:[e-mail]> <[e-mail]> 
发送时间: 2022年4月29日 9:33
收件人: Dan Li  <mailto:[e-mail]> <[e-mail]>
抄送: [e-mail] <mailto:[e-mail]> 
主题: Re: [savnet] SAVNET WG charter

 

I see that this draft charter proposes to exclude data plane solutions, focusing only on the control plane.  I understand the rationale for this, but I think the charter should not impose this restriction.

 

Data plane solutions are potentially expensive to deploy (perhaps requiring new hardware, which could take many years to roll out), but their security properties are very easy to analyze.  If Networks A and B both adopt data plane address validation, then endpoints in both networks are entirely protected from reflection attacks off of amplifiers in the other network.  Amplifier-heavy networks (e.g. those containing large open DNS resolvers) and target-heavy networks (e.g. gaming services) could accept the expense of implementing data-plane SAV as early adopters and immediately gain significant protection, even if they do not peer directly and the intermediary networks are unmodified.  Once a small number of networks are participating, each new network that activates this system gains more protection than the last, regardless of topology.  This "snowball effect" could help to counter the challenges to adoption.

 

Control plane solutions are less expensive, but I find their security guarantees quite obscure.  It seems to me that even if all but one of the world's networks implement a control-plane defense, the one misbehaving network can still hijack routes and forge source addresses.  Perhaps control-plane SAV is sufficient if we also assume universal deployment of BGPSEC, but this seems like a poor assumption.  (The charter should include threat modeling to explain what the security guarantee is.)

 

As a matter of working group management, control-plane and data-plane solutions are sufficiently independent that the discussions shouldn't interfere with each other.  The development of documents can proceed in parallel.  They require the attention of the same pool of experts, so it makes sense to share a working group.

 

As a process matter, both data-plane and control-plane solutions were presented at the BoF, and I don't see a justification for selecting one and ignoring the other.

 

On Thu, Apr 28, 2022 at 4:49 AM Dan Li <[e-mail] <mailto:[e-mail]> > wrote:

Dear colleagues,

 

One month has passed since the SAVNET BOF in IETF 113. In the IESG/IAB meeting, it was concluded that the problem is well-defined and was suggested that SAVNET be moved to the Routing Area.

 

After discussing with the ADs in the Routing Area, we decide to apply for forming a WG with a relatively narrower scope. Specifically, the potential WG will focus on intra-domain and inter-domain SAV mechanisms by extending existing routing protocols.

 

Enclosed please find the drafted WG charter. We would like to get the feedback from our community.

 

Best,

Dan

-- 
savnet mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/savnet

 

-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, which is 
intended only for the person or entity whose address is listed above. Any use of the 
information contained herein in any way (including, but not limited to, total or partial 
disclosure, reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender 
by phone or email immediately and delete it! 

-- 
savnet mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/savnet