Subject: Re: [tcpm] rfc5961 and suggested updates.

From: Loganaden Velvindron <[email-masked]>
Date: Tue, 2 Oct 2018 14:22:52 +0400

On Fri, Aug 24, 2018 at 6:07 PM Mirja Kühlewind
<[email-masked]> wrote:
>
> Hi,
>
> my personal opinion:
>
> I agree that documenting the problem and recommending the implementation of per-socket limits would be a useful thing to do.
>
> I don’t think it is appropriated or needed to update or even deprecate RFC5961, therefore I would strongly support the changes to this draft as you described below.
>
> Mirja
>

Gentle reminder.

---

From: Loganaden Velvindron <[email-masked]>
Date: Thu, 4 Oct 2018 10:10:49 +0400

On Tue, Oct 2, 2018 at 7:38 PM Zhiyun Qian <[email-masked]> 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?
>
Understood.

> Best,
> -Zhiyun
>
>
> On Tue, Oct 2, 2018 at 3:23 AM Loganaden Velvindron <[email-masked]> wrote:
>>
>> _______________________________________________
>> tcpm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Thu, 4 Oct 2018 08:04:16 -0700

> On Oct 3, 2018, at 11:10 PM, Loganaden Velvindron <[email-masked]> wrote:
> 

To clarify, are you talking about a per “socket pair” (i.e., per connection) limit? For TCP, the term should be “socket pair” or “connection”. A socket could include one local side of IP/port and many remote IP/ports, and I don’t think that’s what you intend.

(if you mean “unix socket” then  you’re writing recommendations for unix implementers, which is much less useful as an Internet doc).
…

>> - 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…

FWIW, all of this basically highlights the issue that simply receiving these messages is not an “attack”; the attack is inferred from some threshold of activity. It’s difficult to understand how to usefully set that threshold in any way that isn’t trivial or arbitrarily heuristic (and I haven’t found the draft you’re referring to).

It seems like you’re arguing largely that this threshold should be per connection rather than per IP address. If so, that’s such a minimal issue it’s hard to understand this as more than an errata to RFC5961.

Joe

---

From: Neal Cardwell <[email-masked]>
Date: Thu, 4 Oct 2018 12:42:58 -0400

> > - 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…

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

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 4 Oct 2018 10:13:24 -0700

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=
[email-masked]> wrote:

> > > 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?
> > >
> >
> > > - 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:

---

From: Joe Touch <[email-masked]>
Date: Thu, 4 Oct 2018 17:29:51 -0700

> On Oct 4, 2018, at 9:26 AM, Zhiyun Qian <[email-masked]> wrote:
> 
> Last time I checked, FreeBSD/macOS and Windows have not fully implemented RFC5961 yet.

That seems correct to me.

This mechanism is relevant only for on-path attackers and useful mostly for long-lived services. Neither is typical for end users.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 4 Oct 2018 17:30:19 -0700

FWIW, that makes the most sense to me.

> On Oct 4, 2018, at 9:42 AM, Neal Cardwell <ncardwell=[email-masked]> wrote:
> 
> Re:
>  https://tools.ietf.org/html/draft-lvelvindron-ack-throttling-03 <https://tools.ietf.org/html/draft-lvelvindron-ack-throttling-03>
>

---

From: "Smith, Donald" <[email-masked]>
Date: Fri, 5 Oct 2018 16:40:37 +0000

Has anyone done the math to show this wouldn't be a 64k increase in counters/buffers/challenge ACKs?
Intuitively I know it isn't, in most cases you only have a few open ports/services, so probably 2x, 3x... ?

Is there any value to saying only OPEN sockets, ports or services or is that implied?
Is open socket the same as if it would have been allowed by a filter?
Clearly the OS doesn't know if a middle box would have filtered it, but it could in theory know if a host based filter would have stopped it.

"2.  Recommendation for ACK throttling mechanism
An implementation SHOULD have a per-socket ACK throttling mechanism
which is not shared across the system."

Socket implies open port/service, but if a port is open at the OS level but closed or limited to a specific set of source addresses via ACL, Iptables, IPF  (HFW)… or even a middle box should that be taken into account Packet could be filtered at a higher level than basic OS socket creation so no challenge ack nor counter needed unless it could have been allowed?

If you only send challenge acks for open ports/services would this provide a way to do negative scans?
The src is spoofed, so I don't think so, as the blind reset sender isn't seeing the challenges.

Metric System < +000 > -000
Extra People's Terribly Good Meals Kept mY uNCLE    Ned   Purring For     Ages
Exa   Peta        Tera     Giga   Mega  Kilo milli Micro(u) Nano Pico    Femto Atto
[email-masked]

From: tcpm [[email-masked]] on behalf of Joe Touch [[email-masked]]
Sent: Thursday, October 04, 2018 6:30 PM
To: Neal Cardwell
Cc: Eric Dumazet; [email-masked]
Subject: Re: [tcpm] rfc5961 and suggested updates.

Re:

neal
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 5 Oct 2018 16:50:04 -0700

Hi Zhiyun,

OK. So, in my understanding, this attack infers the lower bound at first,
then repeating the process to expect eventually the target selects the
lower bound value again everytime they narrow down to identify the proper
seqno or ackno.
I also think this could be a potential risk, but we can easily increase the
difficulties by using wide random range or probability-based response
without increasing the complexity of the implementations much.
Anyway, if many implementors think having per-connection/address limit is
easier and inexpensive, I don't have any more opinions on it.
Thanks for the info!
--
Yoshi

On Thu, Oct 4, 2018 at 11:07 PM Zhiyun Qian <[email-masked]> wrote:

> Yoshifumi,
>
> Linux did implement the fix to randomize the global limit for each
> 1-second interval (I think Eric made the patch if I am not mistaken).
> However, such randomization can be tricky to analyze and is not fool-proof.
> In fact, there is still information leakage in the current Linux
> implementation (albeit much more difficult to exploit). Hence I'd still
> vote for the per-connection rate limit.
>
> Let us imagine the random range of the limit to be 100 to 200 (Linux uses
> a larger range but let us use it just for the sake of discussion). To infer
> whether a spoofed packet triggers a challenge ACK, the attacker can do the
> following: it sends 1 spoofed packet and 100 non-spoofed packets (the sum
> of which would be 101, just slightly over the lower bound of the limit).
> Whenever the spoofed packet triggers a challenge ACK from the victim
> server, and the server happens to choose 100 as the limit of the current
> interval, the attacker will see exactly 99 challenge ACKs back to itself
> --- this is the only time the attacker should see 99 (all other times the
> attacker will see 100, which doesn't leak anything because it could either
> be the case that spoofed packet does not triggger a challenge ACK, or
> perhaps it did but the server's limit at the moment is higher than 100).
> This still allows the attacker to infer whether a spoofed packet does
> trigger a challenge ACK. It just needs to guess 50X more times (on average)
> compared to the original attack. Obviously here this is just an example.
> The larger the random range, the longer it will take the server to pick the
> lower bound as its limit by chance.
>
> In terms of how expensive it is to implement this, Linux seems to have the
> per-connection rate limit even before the challenge ACK was introduced. So
> it doesn't seem to be a lot of overhead?
>
> Best,
> -Zhiyun
>
>
> On Thu, Oct 4, 2018 at 10:13 AM Yoshifumi Nishida <[email-masked]>
> wrote:
>
>> Hi, I am personally wondering if per-connection or per-address based
>> limit is the best way for this.
>> [email-masked] <[email-masked]>> wrote:
>>
>>> ACKs. However, to be honest, I am not sure why this is considered harmful..

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 5 Oct 2018 16:51:49 -0700

Just in case..
The errata 4772 https://www.rfc-editor.org/errata/eid4772 has mentioned
this issue and 793bis already refers it.
--
Yoshi

On Thu, Oct 4, 2018 at 5:30 PM Joe Touch <[email-masked]> wrote:

> On Oct 4, 2018, at 9:42 AM, Neal Cardwell <
> ncardwell=[email-masked]> wrote:
>
> Re: