IETF 115 SAVENET Meeting Minutes Chairs: Aijun Wang (wangaijun@tsinghua.org.cn) Joel M. Halpern (jmh@joelhalpern.com) Secretary: Haoyu Song (hsong@futurewei.com)             09:30-11:30   Friday, 11 November 2022 Session I Room: Richmond 4 1. Source Address Validation in Intra-domain Networks (Intra-domain SAVNET) Gap Analysis, Problem Statement and Requirements (Dan Li) @ 9:35AM * Roland Dobbins: should we focus on inter domain instead of intra domain? * Dan: will talk inter-domain part later * Joel: charter covers both * Antoin: Removed the part for misaligned incentive, why? * Dan: Incentive problem mainly exists in inter-domain * Antoin: It also exists in intra domain. Not technical, but a commercial one. * Dan: Have discussion in email list and two presentations later. We’d like to translate these requirements to technical problem. Need more discussion on how to split it into intra and inter-domain parts. * Jared: SAV may break more things than it can preventing, because the largest attack today doesn’t come from spoofed packets. * Nan: Issues discussed in mailing list and documented on Github. We cannot solve the incentive problem but can improve it. 2. Source Address Validation in Inter-domain Networks (Inter-domain SAVNET) Gap Analysis, Problem Statement, and Requirements (Lancheng Qin) @9:59AM * Sriram: If you do SAV for your customers, reflection attack originated in your customer cone will be detected and mitigated, unlike what you said in general. * Lancheng: If attacks are from provider and peer interfaces, they cannot be detected. * Sriram: EFP-uRPF can protect the victim in your peer customer cone. * Lancheng: More details in the next presentation. * Igor: Misaligned incentive is an overstatement. In many cases they are aligned and there is value. If you can detect attacks form your customer cone, you can protect your IP list from being blacklisted. Also benefit for customers to detect compromised machines. * Lancheng: We acknowledge EFP uRPF can provide incentive comparing to BCP38. We want to new mechanism to provide better incentive to prevent reflection attack on all directions. * Alvano: Slide #12, if we build solutions based on these requirements, these requirements are not specific enough. E.g., the small overhead requirement, we need to quantify. If this document is going to be adopted, we need to be able to use it to evaluate the solutions. For a longer discussion for the WG, the charter says the WG is not going to extend existing mechanisms, but it doesn’t say it will not use the existing mechanisms as part of the bigger solution. * Roland: On misaligned incentive, there are incentives for operators to NOT deploy SAV. There are different categories of incentive; there is a push in operational community to push deploying SAV using existing mechanisms. We’ve seen the shift of DDOS attack landscape because of it. DNS reflection attack down significantly. Also true for the direct attack and spoofed attack. Perceiving on incentive can change when success is seen with existing mechanisms. 3. SAVNET's Incentive Consideration for Defense Against Reflection Attacks (Lancheng Qin) @10:18AM * Roland: 1, Reflection amplification is over emphasized. Direct path boost attack is under emphasized. 2, Insufficient differentiation between the spoofed attack initiator traffic and the amplified attack traffic. 3, Reflection attackers choose cites topologically near the target because of fewer administrative boundaries the attack traffic needs to traverse. 4. EPF uRPF hasn’t be implemented and deployed. How about this new SAVNET mechanism? * Lancheng: Maybe Igor can explain the deployment of EFP uRPF. We talk about technical analysis between EFP uRPF and SAVNET and assume SAVNET could meet the requirements. * Roland: This is a theoretical hypothetic opinions, not based on facts. * Sriram: Call me Sriram. Quick comment to Roland. A request is posted on the comment box to ask for the report on the measurement showing the DDoS attack reduction due to SAV deployment. Slide #7, when moving in higher hierarchical chain level, the SAV become less effective, unless you do a lot of addition things. You will have to resort to a feasible solution. At lower levels, if it’s implemented on both sides, it works much better. * Lancheng: provider interface is more difficult to achieve accurate SAV than customer interface. RFC8704 recommends to deploy loose uRFP at provider and peer interfaces, and deploy EFP uRPF algorithms B at customer interfaces. But to simplify manual configuration, we need one mechanism to validate traffic from all directions instead of deploying different stuff at different directions. We should pay more attention on provider and peer interfaces. It’s difficult but necessary. * Sriram: You haven’t described what SAVNET is. That’s more about the architecture. For requirements, why old mechanism can’t meet the requirements and the SAVNET can. You don’t have a solution yet unless you point to the architecture document. I would be careful to state that SAVNET is better at this point. * Nan: This is a working document. We do not give implementation. 4. Source Address Validation Table Abstraction and Application (Nan Geng) @10:43AM * Jared: Slide on sampled packet. Operators are already doing that through netflow, ipfix or sflow. For multi-tenant environment, for L3 VPN, not all source IP addresses are known. Do you mean all the routing protocols and VPNs contribute to this SAV table? * Nan: We don’t assume all the routing protocols will work for SAVNET. We can take a sampling action into consideration to help us analyze the source of attack. * Jared: You need IBGP for example to make sure that your route gets into the SAV table. We do need create a contributing table out of all the routing protocols. We need to ensure the exception packets could still flow through the networks. That’s important for debugging. Need to make sure there is way to contribute from all routing protocols to build a superset list from all the data sources. * Nan: We just provide several validation modes options, but we need to classify which can be used in a target network. We give some suggestions in the draft. 5. Intra-domain Source Address Validation (SAVNET) Architecture (Fang Gao) * Roland: In the intra domain case, the majority spoofed attack traffic is generated by server-class machines in data centers. An informational RFC (in chat box) called IP source guard is a mechanism works at switch level. It’s not discussed in this WG. Second, in cable type of access systems, another mechanism called cable source verify is very similar. It’s not documented and patented. We need to look at it. Finally, a typo: convergence ends with ‘e’ not ‘y’. * Alvano: The tables here seem to be the focus of the architecture. However the table descriptions are based on the assumption of a specific solution. Architecture can be met by different solutions. This document should be a general and high level document. 6. Inter-domain Source Address Validation (SAVNET) Architecture (Nan Geng) @11:13AM 7. Lowering Improper Block and Improper Admit for SAV – the BAR-SAV Approach (Igor Lubashev) 11:20AM * Roland: This solution is aligned with the WG charter (using but not extending existing mechanisms). This one has higher potential than some of the others. 8. Analysis of Source Address Validation Data Plane Performance (Mengxiao Chen) @11:27AM * Darren: SPD stuff may look like a solution but not an architecture. Any comparison has been done in the WG? * Mengxiao: This data plane SAV table can be used by different control plane mechanisms. Not limited to a specific solution. * Roland: Are the source code and implementation details public available? * Mengxiao: Currently unavailable. * Roland: It would be very helpful to make it public available.