Re: [tcpm] rfc5961 and suggested updates.

[Neal Cardwell <[e-mail]>]

On Thu, Oct 4, 2018 at 2:11 AM Loganaden Velvindron <[e-mail]> wrote:
>
> On Tue, Oct 2, 2018 at 7:38 PM Zhiyun Qian <[e-mail]> wrote:
> >
> > Loganaden and Mirja,
> >
> > Not sure if my previous email went through. I'm copying it here:
> >
> > Chiming in here. My name is Zhiyun Qian. We are the group of researchers from UC Riverside who invented the original side channel attack in 2016. Thanks Loganaden for initiating the changes to the specification and thanks Mirja for putting me in the loop. I've done much research in TCP security that I felt like this is home :)
> >
> > My 2 cents:
> >
> > - I fully support we make it explicit that per-socket rate limit (instead of global limit) should be implemented either in a separate draft or maybe RFC5961itself. I am not sure how people will come across a separate draft like this. Will there be a link from RFC5961?
> >
>
> That's a possibility if there is enough interest. Right now, I've
> received feedback only from you and Mirja. I was hoping to get
> feedback from more people.
> The draft is pretty small, and I've removed the "controversial" parts
> that some people disagreed with.
>
> > - BTW, to this day, Linux still has the global rate limit together with the per-socket limit (the latter will apply first), which still leaves some possibility for attacks (although very slim). I understand the global rate limit is to prevent the whole system from sending too many challenge ACKs. However, to be honest, I am not sure why this is considered harmful. Why don't we do something simple instead such as no limit at all or apply only the per-socket limit? I infer two reasons  (1) reflection attacks --- but the amplification ratio is only 1:1. (2) ACK loops --- but this can be mitigated by the per-socket limit already. Why do we need a global rate limit? The benefit seems very incremental to me. The only benefit is that when thousands of connections (perhaps on a server) all enter the "ACK loop state" and started flooding the network but this seems extremely unlikely?
> >

Re:
  https://tools.ietf.org/html/draft-lvelvindron-ack-throttling-03

I would support the suggestion to publish these recommendations (for
per-connection rather than per-IP-address rate limiting) as an errata
to RFC5961.

neal