Hi Robert,
1) Yes we consider ECMP. We just take all ECMP paths as valid paths. Because a “valid” path for a “source address” refers to that at least one packet with the “source address” can traverse the path based on the data-plane tables. 2) For the churn issue, we are already under discussion in the other email thread. 3) For the necessity of such a protocol in intra-domain. The reason is that policy based routing (such as ACL, static routing, etc.) may change the path calculated by link state routing protocol. So we need to extend existing routing protocol to calculate the “real” data-plane forwarding path. Best, Dan 发件人: Robert Raszuk <[email protected]> 发送时间: 2022年5月6日 16:24 收件人: Dan Li <[email protected]> 抄送: Ben Schwartz <[email protected]>; Weiqiang Cheng <[email protected]>; [email protected]; Lizhenbin <[email protected]>; RTGWG <[email protected]> 主题: Re: [savnet] Regarding reusing existing routing protocols for SAV//RE: SAVNET WG charter Hi Dan, > The key idea of the currently proposed control-plane solution is to discover > the real forwarding > path in the data plane and carry this information by routing protocols. Interesting ... Two quick questions: * Does this include ECMP hashing awareness ? And if so based on what key (s) you are going to distribute path awareness ? * Don't you think that if we do that we will introduce to routing protocols the level of churn never seen before ? Especially if you are planning to do that in BGP. For link state protocols I am not sure this is needed as even today any node can compute path between any two points in the network. So modulo ECMP that information is known and number of solutions are already using it today in production. Thx, R. On Fri, May 6, 2022 at 3:18 AM Dan Li <[email protected] <mailto:[email protected]> > wrote: Hi Robert, I agree that in the bigger picture, DDoS attack can be launched by either legitimate addresses or spoofed addresses. But we know that, as one of the major DDoS attacks, reflective DDoS attack is primarily based on spoofed addresses. Actually RFC 6959 made a very good summary of the potential threats caused by spoofed addresses. So making a more strict underlay network will definitely help these cases. Besides, I can imagine another advantage of putting the SAVNET WG in the Routing Area. The key idea of the currently proposed control-plane solution is to discover the real forwarding path in the data plane and carry this information by routing protocols. If we can do this, we can not only address the source address spoofing problem, but also help other scenarios which requires the real forwarding path information. For instance, in multicast routing protocols like PIM-SM, when a router forwards a receiver join message, it also needs to know the actual data-plane forwarding path from the source to the receiver. Currently PIM-SM uses uRPF, but it bears the same problem as using uRPF to prevent source address spoofing. In one sentence, I think that sharing the information of real data-plane forwarding path among routers can help many network scenarios. Network diagnosis such as finding the routing loop or routing hole may be another case. Best, Dan 发件人: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > 代表 Robert Raszuk 发送时间: 2022年5月5日 22:28 收件人: Ben Schwartz <[email protected] <mailto:[email protected]> > 抄送: Weiqiang Cheng <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> ; Lizhenbin <[email protected] <mailto:[email protected]> >; RTGWG <[email protected] <mailto:[email protected]> > 主题: Re: [savnet] Regarding reusing existing routing protocols for SAV//RE: SAVNET WG charter 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] <mailto:[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] <mailto:[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]] Sent: Monday, May 2, 2022 11:30 PM To: [email protected] <mailto:[email protected]> Cc: Lizhenbin <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[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] <mailto:[email protected]> > 发送时间: 2022年5月2日 17:34 收件人: Dan Li <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[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]] On Behalf Of Dan Li Sent: Thursday, April 28, 2022 4:50 PM To: [email protected] <mailto:[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] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/rtgwg -- savnet mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/savnet
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
