Subject: Re: [tcpm] [saag] Linux flaw from RFC5961 implementation

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

Hi, all,

Moving this thread back to TCPM where it is ongong...

I'll address the note below.

Joe

On 8/13/2016 10:45 AM, Yoav Nir wrote:
>> On 13 Aug 2016, at 6:35 PM, Joe Touch <[email-masked]> wrote:
>>
>> 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.
> 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. 
That is demonstrably false on many levels. My students just found a two
significant bugs in the Linux TCP code just this summer.

Then again, RFC5961 exists because Linux was all to happy to take
over-eager "security" fixes that could impact normal TCP operation.

> The fact that Microsoft got it right is not proof that any competent developer will get it right.
And the fact that Linux got it wrong is not proof that others will as well.

> 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. 
The entire doc is written in the context of a single connection except
where it indicates otherwise (per-machine values for per-connection
limits). Anyone who thinks that an attack on one TCP connection implies
an attack on another is already incorrect. The document is already
written to take that into account.

> 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. 
If the CPU and bandwidth are that limited, then TCP won't function well
either.

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

The RFC doesn't mention not to put your credit card information in the
header too - hopefully we don't need to explain everything you shouldn't do.

Joe

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Sun, 14 Aug 2016 14:54:23 +0000

According to https://www.ietf.org/iesg/statement/errata-processing.html, the condition for "verified" errata is:

  "Only errors that could cause implementation or deployment problems or significant confusion should be Verified."

As an individual contributor to TCPM, in this case I believe there is empirical evidence that the wording of RFC 5961 can cause "significant confusion". To me, the conditions for a "verified" errata can thus be fulfilled in this case. BTW, the other two potential states for erratas are "hold for document update" or "rejected".

Also, I don't believe that an errata with some additional explanation or implementation guidance would cause harm to the RFC series.

Michael

> -----Original Message-----
> From: tcpm [mailto:[email-masked]] On Behalf Of Joe Touch
> Sent: Saturday, August 13, 2016 8:47 PM
> To: Yoav Nir
> Cc: [email-masked]
> Subject: Re: [tcpm] [saag] Linux flaw from RFC5961 implementation
> 
> Hi, all,
> 
> > 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.
> > 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.
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Mon, 15 Aug 2016 09:01:39 -0700

Hi, Michael,

The key question is whether there are actually *errors* in the RFC that
cause this problem.

AFAICT, this is just an incorrect misreading, not based on an error in
the text. I'm not sure why we want to address every one-off incorrect
misreading this way, but an errata seems like a better way to handle
this than a new RFC.

FWIW, the errata should be clear that this isn't based on an *error* in
the text.

Joe

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Mon, 15 Aug 2016 17:02:56 +0000

Sure, the wording in RFC 5961 may not really be erroneous, but RFC wording that is not bullet proof is also an issue, in particular if the security implications are not really obvious. TCPM had to deal with ambiguities in RFC wordings in the past already (e.g., RFC 6429). 

It is up to the working group to decide whether an errata is sufficient in this case (i.e., https://www.rfc-editor.org/errata_search.php?rfc=5961&eid=4772). We can certainly discuss the exact wording.

Michael

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Monday, August 15, 2016 6:02 PM
To: Scharf, Michael (Nokia - DE); Yoav Nir
Cc: [email-masked]
Subject: Re: [tcpm] [saag] Linux flaw from RFC5961 implementation

Hi, Michael,

The key question is whether there are actually *errors* in the RFC that cause this problem.

AFAICT, this is just an incorrect misreading, not based on an error in the text. I'm not sure why we want to address every one-off incorrect misreading this way, but an errata seems like a better way to handle this than a new RFC.

FWIW, the errata should be clear that this isn't based on an *error* in the text.

Joe

On 8/14/2016 7:54 AM, Scharf, Michael (Nokia - DE) wrote:
>>> I’ve read the thread, but I disagree with your conclusion there 
>>> ([1])
>> for several reasons.
>> That is demonstrably false on many levels. My students just found a 
>> two significant bugs in the Linux TCP code just this summer.
>>
>> 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.
>> The entire doc is written in the context of a single connection 
>> except where it indicates otherwise (per-machine values for 
>> per-connection limits). Anyone who thinks that an attack on one TCP 
>> connection implies an attack on another is already incorrect. The 
>> document is already written to take that into account.
>>
>> connections sets a per-connection limit is too low for the mechanism 
>> to function well.
>> If the CPU and bandwidth are that limited, then TCP won't function 
>> well either.
>>
>> connection starve other connections for challenge-acks. But it’s not 
>> so obvious that the RFC did not need to mention it.
>>
>> The RFC doesn't mention not to put your credit card information in 
>> the header too - hopefully we don't need to explain everything you 
>> shouldn't do.
>>
>> Joe
>>