Could you expand on this? What is "overlay" in your terminology?
Are you thinking of attacks that make use of a consumer VPN service? Or perhaps an anonymizing proxy like Tor or Apple Private Relay? On Thu, May 5, 2022 at 9:15 AM Robert Raszuk <[email protected]> wrote: > 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 >> > -- > savnet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/savnet >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
