Subject: [saag] Linux flaw from RFC5961 implementation

From: [email-masked]
Date: Sat, 13 Aug 2016 09:44:36 -0400

Hello,

Some of you may have seen the Linux flaw announced a couple of days ago from an implementation of RFC5961.  Here's a pretty good description with the text from those that found the flaw:

https://www.google.com/amp/www.theregister.co.uk/AMP/2016/08/10/linux_tor_users_open_corrupted_communications/

RFC5961 doesn't specify the use of a global counter.  Should we make that clear with errata or is it worth an update?  Since Stephen & I read it as an implementation problem (that might be an issue elsewhere), I think errata is fine.  It would be good to have some other opinions on this in case we are missing something.

Thanks,
Kathleen 

Sent from my iPhone

---

From: Yoav Nir <[email-masked]>
Date: Sat, 13 Aug 2016 17:56:49 +0300

> On 13 Aug 2016, at 4:44 PM, [email-masked] wrote:
> 
> Hello,
> 
> RFC5961 doesn't specify the use of a global counter.  

Well, not is no many words, but see section 7 [1]:

   In order to alleviate multiple RSTs/SYNs from triggering multiple
   challenge ACKs, an ACK throttling mechanism is suggested as follows:

   1) The system administrator can configure the number of challenge
      ACKs that can be sent out in a given interval.  For example, in
      any 5 second window, no more than 10 challenge ACKs should be
      sent.

   2) The values for both the time and number of ACKs SHOULD be tunable
      by the system administrator to accommodate different perceived
      levels of threat and/or system resources.

I think it’s pretty clear from both the above and the rest of the section that these rate-limits are intended to be global. Anyone following this spec would understand it that way. 

> Should we make that clear with errata or is it worth an update?  Since Stephen & I read it as an implementation problem (that might be an issue elsewhere), I think errata is fine.  

I don’t think this is a buggy implementation of RFC 5961. I think that’s RFC 5961 specifying a bug. According to guideline number 7 of [2] this should not be an erratum. Nevertheless, those guidelines are not immutable rules, so you and Stephen can decide that a verified erratum is fine. But I’m not convinced that implementers read errata. 

> It would be good to have some other opinions on this in case we are missing something.

I think this will affect every implementation by any implementer who hasn’t read the research by those “eggheads at the University of California, Riverside” or the Register article. I think an update is the correct path.

> Kathleen 

Just my 2 cents

Yoav

[1] https://tools.ietf.org/html/rfc5961#section-7
[2] https://www.ietf.org/iesg/statement/errata-processing.html

---

From: [email-masked]
Date: Sat, 13 Aug 2016 11:26:59 -0400

Sent from my iPhone

> On Aug 13, 2016, at 10:56 AM, Yoav Nir <[email-masked]> wrote:
> 
> 
Thanks, Yoav.  I'm happy to go with consensus and get this updated.

Kathleen

---

From: Joe Touch <[email-masked]>
Date: Sat, 13 Aug 2016 08:35:23 -0700

Hi, all,

This issue is already been discussed in TCPM. Please review the existing
thread and continue discussion there.

A quick summary from my viewpoint:

a) there already is a draft

b) IMO, the Linux code is just (and yet another) bug based on an
incorrect read of RFC 5961, not worthy of even an errata

All of this is in the thread on TCPM. Please discuss it there.

Joe

On 8/13/2016 6:44 AM, [email-masked] wrote:
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Yoav Nir <[email-masked]>
Date: Sat, 13 Aug 2016 20:45:27 +0300

> On 13 Aug 2016, at 6:35 PM, Joe Touch <[email-masked]> wrote:
> 
> Hi, all,
> 

Hi, Joe

I’ve read the thread, but I disagree with your conclusion there ([1]) for several reasons.

First, RFCs should be clear enough that reasonably competent implementers will get it right. I think it’s safe to say that Linux kernel developers are reasonably competent as a whole, so if they got it wrong the RFC is not clear enough and requires a clarification in one form or another. The fact that Microsoft got it right is not proof that any competent developer will get it right.

Second, section 7 talks about rate-limiting to prevent DoS. It talks about protecting bandwidth and CPU utilization. It states that "An implementation may take an excessive number of invocations of the throttling mechanism as an indication that network conditions are unusual or hostile.” All of this is global to the system, not specific to one connection or another. As far as bandwidth is concerned, there is no difference between sending 5 Challenge Acks on each of 20 connections, or 100 Challenge Acks on a single connection. 

Third, if a machine has enough CPU and bandwidth to allow X challenge acks per second, then dividing X by the number of concurrent connections sets a per-connection limit is too low for the mechanism to function well. 

Of course, now that we know about the attack it seems obvious that the limit should be per-connection and that we shouldn’t let one connection starve other connections for challenge-acks. But it’s not so obvious that the RFC did not need to mention it.

Yoav

[1] https://mailarchive.ietf.org/arch/msg/tcpm/nSdJbewUxer4GLfKJic924XXryE

---

From: [email-masked]
Date: Sat, 13 Aug 2016 13:59:49 -0400

Sent from my iPhone

> On Aug 13, 2016, at 11:35 AM, Joe Touch <[email-masked]> wrote:
> 
> Hi, all,
> 
Thank you, Joe!

---

From: [email-masked]
Date: Sat, 13 Aug 2016 14:02:09 -0400

Sent from my iPhone

> On Aug 13, 2016, at 1:45 PM, Yoav Nir <[email-masked]> wrote:
> 
> 

You may want to chime in on the TCPM thread to keep this in one place.

Thanks,
Kathleen

---

From: Daniel Migault <[email-masked]>
Date: Mon, 15 Aug 2016 14:04:57 -0400

Hi,

My understanding is that the current specification can lead - and has lead
to - to unsecured implementations on major systems. I am not either
convinced that it is an implementation specific issue, and in the worst
case, specifications should have provided more guidance. As a result,
specifications should be updated in some ways, and we should make sure
future implementers are aware of the update. I think an update is a safer
path than the errata.

BR,
Daniel

On Sat, Aug 13, 2016 at 2:02 PM, <[email-masked]> wrote:

> > First, RFCs should be clear enough that reasonably competent
> implementers will get it right. I think it’s safe to say that Linux kernel
> developers are reasonably competent as a whole, so if they got it wrong the
> RFC is not clear enough and requires a clarification in one form or
> another. The fact that Microsoft got it right is not proof that any
> competent developer will get it right.
> >
> > Second, section 7 talks about rate-limiting to prevent DoS. It talks
> about protecting bandwidth and CPU utilization. It states that "An
> implementation may take an excessive number of invocations of the
> throttling mechanism as an indication that network conditions are unusual
> or hostile.” All of this is global to the system, not specific to one
> connection or another. As far as bandwidth is concerned, there is no
> difference between sending 5 Challenge Acks on each of 20 connections, or
> 100 Challenge Acks on a single connection.
> >
> > Third, if a machine has enough CPU and bandwidth to allow X challenge
> acks per second, then dividing X by the number of concurrent connections
> sets a per-connection limit is too low for the mechanism to function well.
> >
> > Of course, now that we know about the attack it seems obvious that the
> limit should be per-connection and that we shouldn’t let one connection
> starve other connections for challenge-acks. But it’s not so obvious that
> the RFC did not need to mention it.
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 15 Aug 2016 11:33:22 -0700

Take this to TCPM. Again.