Re: [savnet] Some words about the BoF

[Aijun Wang <[e-mail]>]

Hi, Igor:

Understand, Thanks!

Separate the advertisement of Anycast prefixes(via BGP for example) and establishment of SAV filter table(via DSAV control message) will solve your request then.

 

Best Regards

 

Aijun Wang

China Telecom

 

From: [e-mail] <[e-mail]> On Behalf Of Lubashev, Igor
Sent: Wednesday, March 30, 2022 1:26 PM
To: Aijun Wang <[e-mail]>cn>; [e-mail]; 'Eric Vyncke (evyncke)' <evyncke=[e-mail]>
Cc: [e-mail]
Subject: Re: [savnet] Some words about the BoF

 

Aijun,

 

Unfortunately, no, advertising real prefixes from edge locations is not enough.  To ensure that DSR works, the edge servers must originate TCP packets with Anycast as a Source Address.  But since they never advertised those prefixes, an intermediary ISP router with strict uRPF would block these packets before they reach the user.  (If real edge prefixes and anycast prefixes were using the same ASN, and the ISP doing SAV were using rfc8704 algorithms, there would be a higher change for the DSR packets to reach users.)

 

-          Igor

 



 

 

From: Aijun Wang <[e-mail] <mailto:[e-mail]> > 
Sent: Monday, March 28, 2022 9:27 PM

Hi, Igor:

Would you like to provide one diagram to show the situation?

>From your description, my understanding is that if you advertise the prefixes(real IP address of the server, not anycast address, ) from each edge locations, then the upstream ISP that turned on strict uRPF will not block your DSR traffic.

Is that right?

 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: Lubashev, Igor <[e-mail] <mailto:[e-mail]> > 
Sent: Tuesday, March 29, 2022 6:11 AM
To: [e-mail] <mailto:[e-mail]> ; 'Aijun Wang' <[e-mail] <mailto:[e-mail]> >; 'Eric Vyncke (evyncke)' <evyncke=[e-mail] <mailto:evyncke=[e-mail]> >
Cc: [e-mail] <mailto:[e-mail]> 
Subject: RE: [savnet] Some words about the BoF

 

Indeed, uRPF has a limited set of deployments where it can work well. But elsewhere it can cause harm.

 

For one of the services we have, anycast IPs are announced only from some locations with a lot of connectivity, and then packets are tunneled to edge locations, where the content is, and the edge locations do direct server return (DSR) sending the content to the users.  We do not want to announce anycast IPs from the edge locations, since we would not be able to control the incoming traffic.  In effect, we have an asymmetric routing situation, and our DSR traffic from some edge locations is blocked by upstream ISPs that turned on strict uRPF.  That results in those ISPs’ customers served from locations further away.  It is a pity that ISPs that are trying to do the “right thing” are getting penalized. (Such situations are usually solved with an email or a phone call, but the resulting manual configurations are fragile.)

 

Costs-wise, DSAV looks on-par with uRPF for the data plane.  Relative to no SAV at all, however, uPRF and DSAV are costly (they require an extra lookup for the source address), so you need more ASIC and RAM for the same data plane throughput.  But when ISPs decide to use SAV for whatever reason, it would be great if the system actually worked well and caused no harm.  I would be happy to work on this.

 

-          Igor

 

From: [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> > 
Sent: Thursday, March 24, 2022 9:45 PM

Thanks Aijun. Indeed, DSAV wants to find a general solution to the source address spoofing problem, since uRPF is only effective in certain scenarios. It is inevitable to introduce additional cost. But note that: 

1) all the costs are in the control plane plus a SAV table in routers. DSAV does not modify the packet or reduce the packet forwarding speed. So the data-plane traffic are not affected at all.

2) Even for the control-plane cost, we are trying to minimize the number of protocol messages. The computation operation is simple, so there is not much computation cost.

3) We are designing incremental deployment ways, and operators can get benefit from incremental deployment. So they have incentive.

 

An obvious advantage of DSAV is that it well matches the MANRS Initiative, i.e., blocking spoofing traffic as close to the source as possible. If the access networks cannot block, then we hope the spoofing traffic can be blocked by intermediate routers, instead of processing them at the final destination. If we only rely on the final destination to resist DDoS attack, actually DDoS attack is successful.

 

Best,

Dan

 

发件人: [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> > 代表 Aijun Wang
发送时间: 2022年3月24日 20:26
收件人: Eric Vyncke (evyncke) <evyncke=[e-mail] <mailto:evyncke=[e-mail]> >
抄送: [e-mail] <mailto:[e-mail]> 
主题: Re: [savnet] Some words about the BoF

 

Hi, Eric:

For the problem space, I think SAVNET wants just to find the general solution for validating the source, which can be deployed incrementally and in wider scenarios than the current existing mechanisms.

If we can finalize such solutions, the network operators will be free of DDoS attack for the services that runs on their networks.

There are challenges to accomplish this aim, but it deserves us to achieve it.

Aijun Wang

China Telecom

 

On Mar 24, 2022, at 20:09, Eric Vyncke (evyncke) <evyncke=[e-mail] <mailto:evyncke=[e-mail]> > wrote:

 

As the responsible AD for this BoF, I would like to thank the chairs and presenters for a well-run BoF and clear and articulated presentations. I also appreciated the many questions, i.e., there is interest in this domain.

 

Just to clarify what I said in the mike, as an individual contributor [1]:

1)      Well-defined problem space

2)      Are there only 2 solutions in this problem space ?

 

So, my *personal* conclusion is that it is too early to create a WG but this decision is not mine but IESG one.

 

Regards

 

-éric

 

[1] as we were running out of time, I forgot to mention that those comments were without my AD hat. Sorry for the confusion.

-- 
savnet mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/savnet <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/savnet__;!!GjvTz_vk!G5x2uVJD_F-BwblnY_WhCkjntUTXeSA2MEv_hV5HhlWMIz7RK8MVk49TNLBf1Lk$>