Re: [savnet] SAVNET WG charter

[Joel Halpern <[e-mail]>]

I think here you are asking very much the right questions.

I think that we actually need the WG in order to answer them properly.  
Whether the following goes in the charter, or is just accepted and 
understood is up to others.  I think that as part of any solution draft 
we need a clear description of

1) what threats it covers

2) and how it covers those threats better than just doing edge filtering 
in the domain (since, by assumption, an operator who knows how to put 
the right information into a control protocol also has the information 
to setup whatever BCP 38 filters can be setup, with whatever limitations 
that has.)

Yours,

Joel

On 4/29/2022 11:50 AM, Ben Schwartz wrote:
> 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]
>     <mailto:[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]>
>         <mailto:[e-mail]>
>         *发送时间**:*2022年4月29日9:33
>         *收件人**:*Dan Li <[e-mail]>
>         <mailto:[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
>