Re: [savnet] SAVNET WG charter

[Ben Schwartz <[e-mail]>]

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]> 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]>
> *发送时间:* 2022年4月29日 23:51
> *收件人:* Dan Li <[e-mail]>
> *抄送:* Joel M. Halpern <[e-mail]>; [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]> 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] <[e-mail]>] *代表
> *Joel Halpern
> *发送时间:* 2022年4月29日 10:51
> *收件人:* Dan Li <[e-mail]>; 'Ben Schwartz' <[e-mail]
> >
> *抄送:* [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 <[e-mail]> <[e-mail]>
> *发送时间**:* 2022年4月29日 9:33
> *收件人**:* Dan Li <[e-mail]> <[e-mail]>
> *抄送**:* [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]> 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]
> 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]
> https://www.ietf.org/mailman/listinfo/savnet
>
>