Hi, I would like to make an observation that lots of attacks these days have moved to overlay and are being transported using legitimate addresses/ports in the underlay.
So while I appreciate efforts to make underlay more strict and to enhance current methods of source address spoofing detection, let's keep in mind that it is trivial to bypass it. It is therefore highly recommended to make cost vs benefit judgement before we embark to go on with changes or extensions to lot's of routing protocols. Best, Robert. 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. > > > > 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 working groups 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. This includes > 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 extensions of > existing routing protocols. These will be done in coordination with the WGs > supervising those protocols. > > > > The SAVNET WG will coordinate and collaborate with other WGs as needed. > Specific expected interactions include (but may not be limited to): lsr and > idr. > > > > > > > > *From:* Dan Li [mailto:[email protected] <[email protected]>] > *Sent:* Monday, May 2, 2022 11:30 PM > *To:* [email protected] > *Cc:* Lizhenbin <[email protected]>; [email protected] > *Subject:* RE: [savnet] SAVNET WG charter > > > > Thank Robin for the remind. I am sending this email to colleagues in the > RTGWG to introduce the SAVNET work. > > > > In IETF 113, we held the SAVNET BOF in the INT Area , with a focus on > intra-domain and inter-domain source address validation (SAV) technologies. > The basic motivation is to overcome the problem of improper block or > improper permit in uRPF-based SAV mechanisms. A control-plane solution was > presented in the BoF. The basic idea is: 1) each node notifies its attached > source prefixes along the real forwarding path, and the routers along the > path accordingly build the correct SAV table; 2) the notification messages > are processed in the control-plane via a hop-by-hop manner, and various > methods are used to reduce the message overhead; 3) following the routing > architecture, the notification is divided into an intra-domain part and an > inter-domain part. Given that this solution is highly related to routing > architecture, after the BoF it was suggested to apply for a WG in the > Routing Area. > > > > More materials of the BOF can be found from > https://datatracker.ietf.org/meeting/113/materials/agenda-113-savnet-01. > Enclosed please find the drafted WG charter, which will be improved based > on the feedback we get from the community. > > > > I also hope that RTGWG colleagues who have interest in this topic can join > the SAVNET mailing list (https://www.ietf.org/mailman/listinfo/savnet), > which will be the main channel for future discussions. > > > > Best, > > Dan > > > > > > *发件人:* Lizhenbin <[email protected]> > *发送时间:* 2022年5月2日 17:34 > *收件人:* Dan Li <[email protected]>; [email protected] > *主题:* RE: [savnet] SAVNET WG charter > > > > Hi Dan, > > Since the BOF was held in the INT area, maybe not all of the experts from > the RTG area register the mailing list of SAVNET and they are not aware of > the work. > > I suggest you could forward it to the mailing list of RTGWG and briefly > introduce the design concept and progress of the SAVNET work. > > > > > > Best Regards, > > Zhenbin (Robin) > > > > > > > > *From:* savnet [mailto:[email protected] <[email protected]>] *On > Behalf Of *Dan Li > *Sent:* Thursday, April 28, 2022 4:50 PM > *To:* [email protected] > *Subject:* [savnet] SAVNET WG charter > > > > Dear colleagues, > > > > One month has passed since the SAVNET BOF in IETF 113. In the IESG/IAB > meeting, it was concluded that the problem is well-defined and was > suggested that SAVNET be moved to the Routing Area. > > > > After discussing with the ADs in the Routing Area, we decide to apply for > forming a WG with a relatively narrower scope. Specifically, the potential > WG will focus on intra-domain and inter-domain SAV mechanisms by extending > existing routing protocols. > > > > Enclosed please find the drafted WG charter. We would like to get the > feedback from our community. > > > > Best, > > Dan > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
