Hi Dan, And thanks for this!
For what it is worth, I think this is starting to be in the right shape and should move forward. I do have some suggestions still, see below. I also appreciated the email thread with Ben, he had really good questions. I also agree with what Joel had written about this topic earlier. > 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. I agree with the goal, but the logic in the text seems a bit odd. I guess the real issue is that you want both (a) blocking as close to sources as possibl, (b) cannot guarantee checking elsewhere, and (c) cannot know where spoofers are, could be for instance inside the network and not just on the user access links, etc. Maybe … to improve effectiveness, SAV should be performed both close to the most potential attack sources to limit damage, and at multiple levels to guard against situations where another network may not be doing SAV or does it in a limited fashion. Or maybe just delete the sentence and just say that you wish to perform it both intra- and inter-domain to guard against different situations. > 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. Again, I agree with the goals but they may be promising too much. This goes to the heart of the discussion we had prior to the BOF and also some of the discussion now more recently: you may not be able to guarantee improper block/permit under dynamic network conditions. But it is no use arguing about it, why don’t we just say, for instance, ”… sometimes improperly permit ….. or block …. The SAVNET working group willl define a protocol-independent architecture and procedures to improve the accuracy of the actions taken by current SAV mechanisms." > 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. Good. > 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. Ok. > > 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. Perhaps you could add ”, and the conditions under which such an architecture improves the accuracy or performance of the existing SAV mechanisms, without assuming that current networks that have not deployed existing mechanisms will use the new mechanisms” or some other words to the same effect. It is crucial to be able to talk about what specific improvements can be provided, > 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 > > 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. Jari
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
