Hi Ben, I have seen lot's of attacks anchored on zombi processes installed on internal infra by hackers (bots, worms etc ...) So no - nothing to do with VPNs. The attackers (including DDoS) encrypt their packets and tunnel it (transparently) between those anchors.
TOR is another one but I did not mention it here as I have not seen (yet) auto installed TOR nodes attacking from the inside. Again I am not against protecting underlay in a more fine way. But let's not forget about bigger picture and "holistic" view. Many thx, R. On Thu, May 5, 2022 at 4:22 PM Ben Schwartz <[email protected]> wrote: > 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 >> >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
