Hi Yingzhen, Thanks for your comments.
Other colleagues also expressed the concern that the milestones are aggressive. As I replied in previous email threads, we will update the milestones by taking these suggestions into consideration. For the routing protocol extensions, we think they should go to other WGs which supervise these routing protocols. So we did not put them in the milestones of the SAVNET WG. “Protocol-independent architecture" means that the SAVNET WG does not plan to make the extensions of the existing routing protocols. Instead, this WG focuses on the high-level architecture design. Specifically, we will focus on how to generate the SAV rules in routers by following the real data-plane forwarding path, for both intra-domain and inter-domain. As for the intra-domain DSAV protocol, in the last SAVNET BOF we did not determine whether to extend existing IGP protocols or to design a new protocol. After discussing with more colleagues after the BOF, many people think that it may be easier to deploy if we can extend existing routing protocols. Actually, there are indeed some overlaps between the DSAV protocol requirement and existing link-state routing protocol, such as advertising the prefixes attached to a router to the entire network. Best, Dan 发件人: Yingzhen Qu <[email protected]> 发送时间: 2022年5月13日 13:48 收件人: Dan Li <[email protected]> 抄送: [email protected]; RTGWG <[email protected]> 主题: Re: updated SAVNET WG charter Hi Dan, I have some questions about the charter: • The milestones are very aggressive, I’d suggest the architecture document should be after the problem and the use case documents. • For all the protocol extensions, they’re not in the milestones, will they be included in the corresponding architecture docs? • A couple of questions/comments below inline. Thanks, Yingzhen On May 8, 2022, at 6:26 AM, Dan Li <mailto:[email protected]> wrote: Dear colleagues, >From the feedback within and beyond the mailing list, we modify the SAVNET WG >charter by adding the specific cooperation with other WGs and adding some >tentative milestones. In what follows you can find the updated WG. We are >looking forward to further comments from the community. Best, Dan Charter for SAVNET Working Group Source address validation (SAV) is important to mitigate source address spoofing attacks. To improve the effectiveness, SAV mechanisms should be applied as close to the source as possible. Therefore, it is desired to deploy SAV in both intra-domain and inter-domain networks. However, existing SAV mechanisms like uRPF-related technologies may improperly permit spoofed traffic or improperly block legitimate traffic. The "Source Address Validation in Intra-domain and Inter-domain Networks (SAVNET)" working group will define a protocol-independent architecture and procedures to overcome the limitations of existing SAV mechanisms. [Yingzhen]: what does “protocol-independent architecture” mean here? Specifically, the SAVNET WG will define procedures that allow nodes to accurately determine valid incoming ports for specific source prefixes taking into account information not currently included in routing protocols. The scope of the SAVNET WG includes the SAV function in both intra-domain and inter-domain networks, and the validation of both IPv4 and IPv6 addresses. The WG is expected to address intra-domain solutions first. SAVNET should avoid packet modification in the data plane. Where possible, existing control and management plane protocols must be used within existing architectures to implement the SAV function. Any modification of or extension to existing architectures, or control or management plane protocols, must be done in coordination with the WGs responsible for the architecture, or control or management plane protocol. The SAVNET WG is chartered for the following list of items: 1) Description of problem statement and use cases for SAVNET, including the requirements that need to be taken into account by the SAVNET architecture. 2) Definition of SAVNET architecture and new procedures, including both intra-domain and inter-domain networks. 3) Definition of operation and management mechanisms needed to operate and manage SAV-related configurations. 4) Solutions to implementing SAVNET architecture by defining modification of or extensions to existing routing protocols. For those, the SAVNET WG will coordinate and collaborate with other WGs as needed. Specific expected interactions include (but may not be limited to): * lsr for OSPFv2, OSPFv3 and IS-IS extensions * idr for BGP extensions * lsvr for BGP SPF extensions * rift for RIFT extensions [Yingzhen]: I must have missed the discussion here. The DSAV framework presented at IETF 113 was not based on extensions to IGPs for intra-domain, I understand for inter-domain BGP may be used. Why is it "Where possible, existing control and management plane protocols must be used within existing architectures to implement the SAV function” ? This sounds very strict to me. Milestones: Jul 2022, Adopt the use case document; Jul 2022, Adopt the problem statement document; Jul 2022, Adopt the first intra-domain architecture document; Nov 2022, Adopt the first inter-domain architecture document; Mar 2023, submit the problem statement document; Mar 2023, Adopt the operational consideration document; Jul 2023, submit the intra-domain architecture document; Jul 2023, Adopt the YANG model document; Nov 2023, submit the inter-domain architecture document; Mar 2024, submit the operational consideration document; Mar 2024, submit the YANG model document. _______________________________________________ rtgwg mailing list mailto:[email protected] https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
