IETF 122 SAVNET Minutes Joel: SAVNET is restricted on solutions. Discussion should focus on general aspects but not the protocol-specific properties which might be in the scope of other WGs. 1. Shuai Wang - Source Address Validation Deployment Status Tobias: Do you validate that most ISAV is at an access network is not an artifact of the measurement methodology. Shuai: We evaluate it by combining different methods Tobias: Access networks shouldn’t find that many resolvers. Is there something about access networks which gives the methodology to make them more ISAV deploying? We can take this offline. 2. Mingqing Huang - General Source Address Validation Capabilities No live comments. Question on chat. 3. Lancheng Qin - A summary of discussions on intra-domain SAVNET architecture Aijun: About intra-domain deployment. Should give flexibility to operator to select where to deploy which is not limited to edge. Traffic engineering action should be deployed in advance. There are some solutions that can overcome the difficulty. Lancheng: Addressing such factors is challenging but not impossible. Computation would be complex, and the edge must be considered. Jeffrey Haas: The difficulty for intra-domain SAV is that you can’t do things across all of the network using the procedures. If you try to expand the access interface functions to solve the network-wide problem through like IGP that doesn't work well. Aijun: we can do email list discussion for deployment issues. 4. Wei Wang - New Intra-domain Source Address Validation (SAV) Solution Peter: Using the bidirectional metric SPF is unrealistic to assume we can equalize the metric from both sides. Should discuss if this is a good idea. Aijun: We want a general solution to cove all routers. Normally the routing is symmetric. Peter: That is not the reality. Aijun: We can use BMSPF in intra-domain if we can collect the router information. Peter: So you are trying to make it symmetric artificially. Sriram: pg. 4. Why R1 on outbound interface is doing intra-domain SAV which should just be doing inter-domains SAV and out of the allowed list it can simply remove p1 and p2 if they are known to be customer prefixes or internal prefixes? Wei: WG document said the intra-domain SAV procedure should solve three scenarios: AS border routers, customer/host-facing routers, and internal routers. Lancheng: pg. 5. Loose IPF can’t block spoofing traffic using a source IP address e.g., p2. A new solution is need for more accurate SAV here. Pg.6.  IPFR and T policies and more factors should be discussed in this case if you consider SAV on internal routers.  Aijun: we will update the doc to prevent customer spoofing. 5. Libin Liu - Source Address Validation in Inter-domain Networks Gap Analysis, Problem Statement, and Requirements Sriram: As a co-author, I suggest we should use feasible paths instead of active active paths as we cannot know the active paths. We can discuss offline. Libin: We have made revision in Section 6. Mingqing: Solutions we have are all based on feasible paths. Distance between user and network is farther and more flexible paths will be involved. Source spoofing can take advantage of it. We need do something. It’s challenging but valuable. 6. Libin Liu - Inter-domain Source Address Validation (SAVNET) Architecture No live comments 7. K. Sriram - An update on the "SAV using BGP UPDATE Messages, ASPA, and ROA" Question on chat Aijun: all possible prefixes owned by AS are put in a table even they are not advertised. It’s challenging for the solution. Better to have proposal to renew it. Sriram: BAR-SAV is directional.  it is fairly accurate in terms of only picking up the feasible paths that can arrive on a specific customer interface. Will clarity on email list. 8. Shuqi Liu - Inter-domain Source Address Validation based on AS relationships Question on chat Aijun: Sriram respond your question on the email list. There are overlaps between the two solutions. The authors should compare the docs and find a general solution. 9. Nan Geng - Inter-Domain SAVNET Solution Sriram: SPD message should only come from the customers in the AS customer cone. They should not be spoofed from AS outside of the customer cone. How does the AS that is doing the SAV know whether the SPD message is coming from an AS within the customer cone or not? Nan:  We do not limit that SPD must be advertised from the customer cone. It can be advertised from a provider direction. Sriram: There has to be some way for the AS to know whether the AS is doing the SAV on the customer interface side so the SPD messages must correspond to customer ASes and it should not be coming from an AS in a neighboring customer cone. Nan: It depends on use cases. We have different usage of SPD messages for different use cases. We can discuss it offline. Sriram: There’s a security problem. Let discuss offline. 10. Jing Zhao - Advertisement of Multi-Sourced SAV Rules using BGP Link-State Peter: Joel said we shouldn’t do any protocol extension in this WG. I don’t think BGPLS is the right thing to distribute this type of information. This doesn’t seem like the topology related stuff. Jing: We support this draft in IDR WG. We’ll consider you comments and plan to improve the document. Aijun: Normally we run BGPLS within one router in the AS. But SAV rules were distributed across every router. How can you distribute the SAV rules within the IGP domain? Jing: In 00 version, we design SAV rule TLV in section 2. Will consider other ways to distribute the SAV rules within IGP domain in the future. Jeff: The state you are trying to advertise is note appropriate to flood through the entirety of BGPLS domain. The state should only be sent to the SAV controller. That’s something to consider in your next version. 11. Haiyang Zhang/ Changwang Lin - YANG Data Model for Intra-domain and Inter-domain Source Address Validation (SAVNET) No time for comments Meeting adjourned