Re: [tcpm] rfc5961 and suggested updates.

Hi, I am personally wondering if per-connection or per-address based limit
is the best way for this.
In my reading of the usenix paper, it says using fixed value for global
limit would be vulnerable. So, it seems to me that it would be ok if the
value is not fixed,
I think there're several ways to do this such as 1) keep changing global
limit at certain interval. 2) after exceeding a certain threshold, send
challenge ACKs with a certain probability. I am thinking this might be
relatively inexpensive rather than having per-connection/address limit.

Thanks,
--
Yoshi

On Thu, Oct 4, 2018 at 9:42 AM Neal Cardwell <ncardwell=
40google.com@dmarc.ietf.org> wrote:

> On Thu, Oct 4, 2018 at 2:11 AM Loganaden Velvindron <loganaden@gmail.com>
> wrote:
> >
> > On Tue, Oct 2, 2018 at 7:38 PM Zhiyun Qian <zhiyunq@cs.ucr.edu> 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
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>