Minutes IETF115: savnet
minutes-115-savnet-01

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.