Subject: [tcpm] [Technical Errata Reported] RFC5961 (4772)

From: RFC Errata System <[email-masked]>
Date: Wed, 10 Aug 2016 11:36:54 -0700 (PDT)

The following errata report has been submitted for RFC5961,
"Improving TCP's Robustness to Blind In-Window Attacks".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5961&eid=4772

--------------------------------------
Type: Technical
Reported by: Stéphane Bortzmeyer <[email-masked]>

Section: 7

Original Text
-------------
[The entire section]

Corrected Text
--------------
No suggested text because it requires a much more serious analysis. 
May be adding that the rate-limit counter SHOULD be per-connection, 
in the spirit of RFC 6528?

Notes
-----
It appears the section does not specify that the counter for ACK throttling SHOULD be per-connection. In Linux, it is apparently global, which allowed its use as a side channel enabling nasty attacks (CVE-2016-5696 and the paper "Off-Path TCP Exploits: Global Rate Limit Considered Dangerous" <http://www.cs.ucr.edu/~zhiyunq/pub/sec16_TCP_pure_offpath.pdf>)

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5961 (draft-ietf-tcpm-tcpsecure-13)
--------------------------------------
Title               : Improving TCP's Robustness to Blind In-Window Attacks
Publication Date    : August 2010
Author(s)           : A. Ramaiah, R. Stewart, M. Dalal
Category            : PROPOSED STANDARD
Source              : TCP Maintenance and Minor Extensions
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

---

From: Loganaden Velvindron <[email-masked]>
Date: Thu, 11 Aug 2016 20:27:51 +0400

I submitted this draft, yesterday.:

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

It's a work-in-progress, but I welcome feedback.

On Wed, Aug 10, 2016 at 10:36 PM, RFC Errata System
<[email-masked]> wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Praveen Balasubramanian <[email-masked]>
Date: Thu, 11 Aug 2016 19:28:51 +0000

The Windows TCP implementation does per-socket throttling instead of global and was found in the paper to be not vulnerable to the exploit. I think we do need an errata to 5961.

-----Original Message-----
From: tcpm [mailto:[email-masked]] On Behalf Of Loganaden Velvindron
Sent: Thursday, August 11, 2016 9:28 AM
Cc: [email-masked]
Subject: Re: [tcpm] [Technical Errata Reported] RFC5961 (4772)

On Wed, Aug 10, 2016 at 10:36 PM, RFC Errata System <[email-masked]> wrote:
> The following errata report has been submitted for RFC5961, "Improving 
> TCP's Robustness to Blind In-Window Attacks".
>
> May be adding that the rate-limit counter SHOULD be per-connection, in 
> the spirit of RFC 6528?
>
> Notes
> -----
> It appears the section does not specify that the counter for ACK 
> throttling SHOULD be per-connection. In Linux, it is apparently 
> global, which allowed its use as a side channel enabling nasty attacks 
> (CVE-2016-5696 and the paper "Off-Path TCP Exploits: Global Rate Limit 
> Considered Dangerous" 
> <http://www.cs.ucr.edu/~zhiyunq/pub/sec16_TCP_pure_offpath.pdf>)
>
> Instructions:
> -------------
> use "Reply All" to discuss whether it should be verified or rejected. 
> When a decision is reached, the verifying party (IESG) can log in to 
> change the status and edit the report, if necessary.
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 11 Aug 2016 12:36:37 -0700

FWIW, I see nothing in RFC5961 that implies that ACK throttling - or
anything in the doc - should be across connections.

This new doc can claim to clarify Sec 7 of that RFC, but I see no reason
to deprecate it.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 11 Aug 2016 12:40:47 -0700

FWIW, I don't really see the need for this new doc at all.

Everything in 5961 is within the context of a single connection. The
misreading of this doc doesn't warrant updating, clarifying, etc.

The behavior of Linux should be treated simply as the bug that it is and
corrected, but there's no reason to pollute the RFC stream or increase
the complexity of TCP requirements on the basis of a bug.

Joe

---

From: Loganaden Velvindron <[email-masked]>
Date: Thu, 11 Aug 2016 20:24:36 +0400

Hi folks,

I submitted this, independently:

---

From: Yuchung Cheng <[email-masked]>
Date: Fri, 12 Aug 2016 09:54:07 -0700

> FWIW, I don't really see the need for this new doc at all.
+1
> misreading of this doc doesn't warrant updating, clarifying, etc.
I think an errata on recommending per-connection limit and cite the
research finding is worthy.

---

From: Neal Cardwell <[email-masked]>
Date: Fri, 12 Aug 2016 12:17:09 -0700

> research finding is worthy.

I agree that it's worthwhile to have an errata to clarify that a
per-connection limit is best. At the very least there seems
some risky ambiguity here.

In fact, AFAICT RFC 5961, Section 7, page 13 --

  https://tools.ietf.org/html/rfc5961#section-7

-- has several passages that seem to implicitly suggest that
the rate-limiting mechanism it specifies as a SHOULD is not
per-connection but rather global.

First:

   ... an
   administrator who is more interested in faster cleanup of stale
   connections (i.e., concerned about excess TCP state) may decide to
   set a higher value thus allowing more RST's to be processed in any
   given time period.

If this is a single-connection rate limit, then what practical reason
would an administrator have to allow "more RST's to be processed in
any given time period"? I can't think of a case where a legit live
connection would send more than one RST. If this is about a single
connection, then allowing one mid-window RST (and responding to that
one with a single challenge ACK) should be enough, in most cases, to
send a challenge ACK that elicits a proper RST from the remote
endpoint. It's not clear to me what the motivation would be for
intentionally sending a challenge ACK in response to more than one
mid-window RST in a single connection.

Thus AFAICT "allowing more RST's to be processed in any given time
period" suggests that the rate limit is across connections.

Second:

   The time limit SHOULD be tunable to help timeout brute force attacks
   faster than a potential legitimate flood of RSTs.

I may be missing something, but if this rate-limiting mechanism is
only about a single connection, then what is a "legitimate flood of
RSTs"? Why would it be important for a single connection to allow a
"legitimate flood of RSTs" destinted for itself? A single legitimate
live connection should not send out a flood of RSTs; it should send
out one. Once there is one legitimate RST that arrives and is
processed, the receiver deletes the connection, and any other arriving
RSTs don't match any existing connection, so are ignored and
dropped, in which case is no challenge ACK to rate-limit.

By contrast, if this rate limit applies across connections then "a
potential legitimate flood of RSTs" makes sense, since a group of
legitimate live connections that all close in a burst may, in certain
cases, generate a legitimate flood of RSTs. So tuning the limit
upward would make sense.

Sorry if I'm missing something obvious. But it seems like there are at
least real ambiguities there, on a point significant enough to be worth
clearing up.

neal

---

From: Joe Touch <[email-masked]>
Date: Fri, 12 Aug 2016 13:19:15 -0700

> some risky ambiguity here.

I disagree, as per below...
> per-connection but rather global.

There's plenty of benefit to setting a single configuration for an
entire system vs. setting per-connection limits. That's completely
different from whether the ACKs are tallied globally or per connection.

> connection would send more than one RST. 
A single connection might process many RSTs because some can be out of
window (they'd be dropped) or not at the end of the window (dropped
under some configurations). I.e., receiving and evaluating RSTs doesn't
always result in resetting the connection.

> If this is about a single
> one with a single challenge ACK) should be enough, 
It would be IF the other end issued a legitimate RST. If this is a
spoofing attack, the data can still keep coming which means that the
window might still be moving forward by the time the next attack RST
arrives. As a result, this sort of 'catch up' can go on until the
connection ends. The point of the text here is to avoid wasting
resources in such cases.
> in most cases, to
Protecting against that case is the motivation *of the entire document*.

> period" suggests that the rate limit is across connections.

There's no benefit to doing this across connections at all, unless you
think that there's some reason that legitimate connections shouldn't be
reset by valid RSTs (there's no benefit to that).

> RSTs"?
A sequence of RSTs that pick different values, as described in RFC 4953.

Or a sequence of RSTs aimed at responses to the ACK-after-RST that is
chasing legitimate data, as described above.

>  Why would it be important for a single connection to allow a
> "legitimate flood of RSTs" destinted for itself? 
It wouldn't - that's the point of this text. You should treat a flood of
RSTs for a single connection as an attack and throttle them accordingly.

> A single legitimate
Again, the point of this document are attacks, not legitimate connections.
> cases, generate a legitimate flood of RSTs. So tuning the limit

There's no case I can imagine where a set of attacks on one connection
should be cause for concern on another necessarily.

Yes, there's no real need to set per-connection limits (i.e., a global
per-connection limit seems fine), but counting them as a group serves no
purpose against any threat, unless you think that "if I'm attacked on
one connection, I will be attacked on another" - but that's an incorrect
inference IMO.

> least real ambiguities there, on a point significant enough to be worth

I think you're missing the point of the document, but that's just my
interpretation of the exchange.

Joe

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 16 Aug 2016 15:07:44 +0200

Hi all,

let me try to wrap this up:

To me this does not seem to be a case for an errata. For sure some 
clarification seems to be helpful here but that's not what erratas are for.

Therefore, I would suggest to simply set this into "Held for Document Update" 
state such that it is noticed in case we decide to update the document at 
some point. Does that make sense?

Thanks,
Mirja

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 16 Aug 2016 10:42:49 -0700

On Tue, Aug 16, 2016 at 6:07 AM, Mirja Kühlewind <
[email-masked]> wrote:

> Therefore, I would suggest to simply set this into "Held for Document
> Update" state such that it is noticed in case we decide to update the
> document at some point. Does that make sense?
>
sounds fine with me but do documents really get updated?

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 19 Aug 2016 15:43:37 +0200

> sounds fine with me but do documents really get updated?
That depends on the working group. However the point here is, if the doc gets updated, then this is still listed.

Mirja

> Am 16.08.2016 um 19:42 schrieb Yuchung Cheng <[email-masked]>:
> 
> 
> 
> On Tue, Aug 16, 2016 at 6:07 AM, Mirja Kühlewind <[email-masked]> wrote:
> Hi all,
> 
> To me this does not seem to be a case for an errata. For sure some clarification seems to be helpful here but that's not what erratas are for.
> 
> Therefore, I would suggest to simply set this into "Held for Document Update" state such that it is noticed in case we decide to update the document at some point. Does that make sense?