IETF123 SAVNET Meeting Minutes

1. Agenda Bashing and WG Update by Chairs

* 6 WG documents

* 19 active I-Ds

* Clarify the goals of the meeting

2. Updates on Source Address Validation in Intra-domain Networks Gap Analysis, Problem Statement, and Requirements (Lancheng Qin)

Jim: What’s the outcome of the suggestions? Requirements may need protocol changes. A conversation on list about the WG consensus on the separation of the document is needed. Emails weren’t copied to the WG.

Lancheng: The document doesn’t assume IGP extensions are necessary.

Sriram: The slide on intra-domain SAV for traffic from rest of the Internet. How is that different from inter-domain on a provider interface?

Lancheng: We make the boundary based on the capability. Intra-domain can only check the spoofed data packets using an internal sourced IP address.

3. General Source Address Validation Capabilities (Mingqing Huang) 

No discussion

4. Intra-domain Source Address Validation (SAV) Solution Based on BM-SPF (Wei Wang)

Peter: I don’t understand the BM-SPF proposal. What’s the purpose of it. What if I want a symmetric metric? You can’t assume you can fix it. Second, I believe the subnet should be done at the border of AS because of many issues. 

Wei: We have uploaded the document in LSR, but we haven’t presented it yet. 

Aijun: We haven’t determined where to deploy the algorithm. We are discussing it with other operators. The deployment is not only on the border routers. Second, BM-SPF just inserts traffic following the same path with the IGP domain which is easy to accomplish within the domain. 

Perter: You just avoid the problem but not fix it.

Aijun: I know the traffic asymmetry exists and we can solve it. 

Perter: Will continue the discussion on the email list.

Jeffrey Haas: Problem should not exist and needs to solve at border routers. Firewall is an example. You can’t change how IGPs are used.

Aijun: We provide motivation and new solutions in some simplified ways.

Dan: Many debates on the deployment points. Most prefer border routers. We can achieve consensus on this. 

Aijun: Discuss on list.

5. Intra-Domain On-Demand Source Address Validation(SAV) Mechanism (Xueting Li) 

Peter: How do you want to dynamically instantiate a rule in cases like FRR?

Aijun: It's the same as we utilize some specific information. If we deploy the FRR the router will calculate the backup path and propagate it to open the interface.

Peter: Don’t see how you can do that. How do you activate it before the traffic hit the box?

Xueting: Will answer on the email list.

6. Source Address Validation in Inter-domain Networks Gap Analysis, Problem Statement, and Requirements (Libin Liu) 

No discussion

7. Update on the BAR-SAV Draft (K. Sriram)

Mingqing: Good work. Pg8, now we need the complete knowledge of the custom cone size. Some cases are not listed here?

Sriram: If you have an example, we can discuss.

Mingqing:  Are we considering to use ToA or RoA for discovering more prefixes that may be hidden?

Sriram: Hidden prefixes are only used for source addresses but never routed. If TOA is the right object we can accommodate that in the solution. 

8. Considerations for SAV-specific information and the need of Traffic Origin Authorizations (TOAs) (Lancheng Qin) 

Sriram: How many prefixes that are only used for source address but never routed?

Some audience: minuscule.

Sriram: Good to know. It is possible to define a special purpose ROA, could also assign a special purpose AS number. We could include the small number prefixes in any SAV table anywhere. 

Lancheng: Need to ask experts.

Sriram: Don’t want to further paly with the semantics of ROA. Stick to TOA

9. Updates on Bicone Source Address Validation (Lancheng Qin) 

Sriram: Same comment made before. You have a large number unallocated IPv6 addresses. How to ensure those are blocked in case spoofed.

Lancheng: Loose URPF can block those spoofed packets.

Sriram: If you propose the allow list solution, unallocated addresses are not in the allow list and they would not be blocked. 

Lancheng: I don’t understand your question.

Sriram: You means to use loose URPF and block list together. How do you implement that?

Lancheng: We can first check packet with loose URPF. If the packet uses an unallocated source address, it will be blocked. Then we recheck the packet using the block list.

Sriram: Your block list won’t include the large number of unallocated prefixes. You can simply subtract the block list from the loose URPF in which case it is no longer a block list solution. You have a allow list. 

Lancheng: Understand. I call it blocklist because of the data structure of the list. 

Sriram: You still have a large table. It’s basically an allowlist solution. 

Antion: Difficult to maintain ACL, but you require manual updates. It’s a lot of work and unscalable. 

Lancheng: The block list can be generated automatically but network operators can modify it.

Antion: We want to prevent that. Anytime I see spoof traffic on an interface, I need to add something to the list.  

Aijun: Discuss on the email list.

10. Inter-domain Source Address Validation based on AS relationships (Shuqi Liu) 

Nan: Pg6. The neighbors means AIS?  

Shuqi: It means validation routers of the neighbor AS.

Nan: Why does not neighbor AS generate the rules locally?

Shuqi: I got your idea. Our scheme generates SAV rules through exchanging but not calculation. Will discuss offline. 

11.  Source Prefix Advertisement for Inter-domain SAVNET (Nan Geng) 

No discussion

12. Benchmarking Methodology for Source Address Validation (Libin Liu) 

No discussion

13.  The asymmetric contract and the broken promise (Jeffrey Haas)

Aijun: should be reflected in the intra- and inter-domain documents. 

Time up