Subject: [Tsvwg] ACK DOS & Eifel (also F-RTO, DSACK-based schemes)

From: Reiner Ludwig <[email-masked]>
Date: Tue, 18 Feb 2003 13:52:52 +0100

during the current IESG review of <draft-ietf-tsvwg-tcp-eifel-alg-07.txt>, 
the following comment was made by an IESG member:

 > > **** The Eifel Detection Algorithm for TCP (Experimental)
 > > <draft-ietf-tsvwg-tcp-eifel-alg-07.txt>
 >
 >I have read this briefly. To me this seems ok, but I am somewhat
 >worried that this would open up a new type of ACK DOS as you could
 >potentially guess timestamps and attack the algorithm. The 2' and 5'
 >suggestions work around this, so I am (thinking out loud) if that
 >should not be the default. OTH it's easier to take out the session by
 >simply DoSing either the sender or the receiver...

How do people think about this? This issue is probably not only relevant to 
Eifel Detection & Response, but also to F-RTO, and DSACK-based alternatives.

Below is what I had responded ...

///Reiner

----------------------------------------------

I would argue against the view of the reviewer:

* This is only a detection algorithm that does not alter TCP sender nor 
receiver state. Thus, no danger here.

* When used together with a response algorithm, e.g., 
draft-ietf-tsvwg-tcp-eifel-response-02.txt, this is a different story. I 
don't know what the reviewer means with "take out the session". But 
clearly, by manipulating ACKs at the TCP receiver or by a flow-state-aware 
box in the middle, congestion control at the TCP sender could be pretty 
much disabled. So, one could argue along the lines of the reviewer when 
combining the Eifel Detection algorithm with a response algorithm that 
alters TCP state. On the other hand, we know (see Savage paper in ACM CCR, 
Oct. 99) that even a "standard conformant" TCP sender's congestion control 
is easily disabled. So, why be extra strict here?

This is actually a relevant issue for the mailing list. Since, if we would 
follow the reviewer's suggestion, we raise the bar quite high also for the 
alternative schemes like F-RTO and DSACK-based schemes. Those should then 
also be comparably safe against misbehaving TCP receivers, I think.

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Mark Allman <[email-masked]>
Date: Tue, 18 Feb 2003 12:35:19 -0500

> This issue is probably not only relevant to Eifel Detection &
> Response, but also to F-RTO, and DSACK-based alternatives.

Yes.  In draft-blanton-dsack-use-02.txt we have the following text:

4   Security Considerations

    It is possible for the receiver to falsely indicate spurious
    retransmissions in the case of actual loss, potentially causing a
    TCP or SCTP sender to inaccurately conclude that no loss took place
    (and cause inappropriate changes to the senders congestion control
    state).  Consider the following scenario:

    A receiver watches every segment or chunk that arrives and
    acknowledges any segment that arrives out of order by more than
    some threshold amount as a duplicate, assuming that it is a
    retransmission.  A sender using the above algorithm will assume
    that the retransmission was spurious.

    As a more trivial example, a receiver could simply acknowledge
    every segment or chunk received as a duplicate as they arrive.
    This approach is more easily defeated by heuristics, but would
    nonetheless cause the algorithm in this document to come to
    an incorrect conclusion.
    
    The ECN nonce sum proposal [WES01] would help mitigate the ability
    of the receiver to hide real losses from the sender.

Not sure what the right answer is... "ignore it completely" seems
wrong.  But, "ignore it after some thought" might be right.  Is
coupling the whole thing with the ECN nonce right?  Probably
not... hmm...

And, I'll note that the attacks from the CCR paper you quote are
getting cleaned up slowly.  ABC certainly helps ACK division.  I
have a note that says one of the things I'd like to see in
RFC2581.bis is a limit on the number of duplicate ACKs a sender will
accept (which would mitigate the bogus-dup-ack-generation attack).
The third attack ("optimistic ACKing") does not seem as troubling to
me because it is such a pain to get going.

allman

--
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Yogesh Prem Swami <[email-masked]>
Date: 18 Feb 2003 17:39:24 -0600

Reiner,

> is easily disabled. So, why be extra strict here?

This is a wrong argument for not being extra strict. Just becase
standard TCP is less secure right now, doesn't mean we should keep
making it worse. To give an anology, someone can steal my car in 1000
ways; leaving it unlocked would be 1001st. Does this mean I should leave
my cars open all the time (I'm not going to, even if you say so). And,
yes, this argument applies to every new scheme as you already pointed
out.

I, however, don't like the fact that anyone making a small change to TCP
has to put himself into the minds of attackers and think of one zillion
possibilities of what an attacker could or could not do. It's also not
prudent to have individual protection schemes for every feature (very
soon, as any one in security community can tell, the interaction between
these schemes will become so complex that it will be hard to analyze and
assess the strength of the overall schemes). That's one reason why I was
(and I'm still) not a big fan of ECN nounces. A protection scheme MUST
protect every scheme in all circumstances (not just one)! [I, however,
don't want to discuss ECN nounce anymore. Please. I've already spent too
much time on this for no reason. If everyone is happy, then so am I :-)]

I think one can devise a single, well though out, future proof scheme
that can protect against *all* possible attacks. In addition, these
schemes need not be invoked all the time, but only when the sender
thinks it's under attack (for example by looking at the number of open
TCP connections it has). This should appease those who are overly
concerned about performance. This will allow people to focus more on
transport layer problems rather than on security issues (which are quite
time consuming).

--yogesh

---

From: Pasi Sarolahti <[email-masked]>
Date: Wed, 19 Feb 2003 11:57:34 +0200

Hi,

On Tuesday 18 February 2003 14:52, ext Reiner Ludwig wrote:

>  >potentially guess timestamps and attack the algorithm. The 2' and
>  > 5' suggestions work around this, so I am (thinking out loud) if
>  > that should not be the default. OTH it's easier to take out the
>  > session by simply DoSing either the sender or the receiver...
>
> How do people think about this? This issue is probably not only
> relevant to Eifel Detection & Response, but also to F-RTO, and
> DSACK-based alternatives.

As for F-RTO, I don't quite see how this comment relates to it, since 
it can be used without any TCP options. Of the attacks given in Savage 
CCR paper, earlier there was a problem related to "ack division" that 
was raised on this list last fall, and I believe it to be fixed. 
"optimistic (& false) acking" could cause wrong response with F-RTO, 
but in that case it would break the state at any TCP sender, so I'm not 
very much worried about it concerning the F-RTO draft. But some 
discussion regarding these in F-RTO security considerations would 
probably be in place.

Timestamps surely provide an additional tool for malicious hosts, with 
or without Eifel. A receiver could subtract something from every 
timestamp echo, causing reduced RTO estimate at the sender and 
eventually a spurious RTO. This would trigger unnecessary 
retransmissions in slow start (unless detected), possibly congesting 
the network with useless segments.

> This is actually a relevant issue for the mailing list. Since, if we
> would follow the reviewer's suggestion, we raise the bar quite high
> also for the alternative schemes like F-RTO and DSACK-based schemes.
> Those should then also be comparably safe against misbehaving TCP
> receivers, I think.

Fully agree. I'd still like to stick to the requirement we had set for 
our work: Never falsely declare a retransmission spurious (but not 
catching all spurious retransmissions is ok).

- Pasi

---

From: Reiner Ludwig <[email-masked]>
Date: Wed, 19 Feb 2003 13:33:43 +0100

At 18:35 18.02.2003, Mark Allman wrote:
>4   Security Considerations [...]
>

I think this needs to be discussed in general. If we are proposing ways to 
reverse congestion control state, we need to decide how secure (if at all) 
such schemes need to be. And a consensus should probably apply to any such 
proposal.

Maybe the ECN nonce is already the consensus on the required level of 
security for such schemes? I.e., congestion-control-reversing proposals 
would be required to have security that is "equivalent" to the ECN nonce. 
Is that what we want?

>me because it is such a pain to get going.

True. But what do say with this? Do you think that, e.g., Eifel 
Detection/Response needs to be made safe against misbehaving receivers?

///Reiner

---

From: Reiner Ludwig <[email-masked]>
Date: Wed, 19 Feb 2003 13:38:36 +0100

At 10:57 19.02.2003, Pasi Sarolahti wrote:
>I'd still like to stick to the requirement we had set for

That's the point. Don't you think that a TCP receiver or a middle-box could 
play "ACK games" that would make F-RTO falsely believe a timeout was spurious?

///Reiner

---

From: Mark Allman <[email-masked]>
Date: Wed, 19 Feb 2003 07:55:34 -0500

> I think this needs to be discussed in general. 

Yep.

> If we are proposing ways to reverse congestion control state, we
> need to decide how secure (if at all) such schemes need to be. And
> a consensus should probably apply to any such proposal.

Yep.

> Maybe the ECN nonce is already the consensus on the required level
> of security for such schemes? I.e., congestion-control-reversing
> proposals would be required to have security that is "equivalent"
> to the ECN nonce.  Is that what we want?

??

> Do you think that, e.g., Eifel Detection/Response needs to be made
> safe against misbehaving receivers?

??

I am not sure what I think the right answer is here.... I think that
it could be Damn Hard to find a single solution.  One way to go that
gets you *some* protection is that the sender applies some scheme
where it is only allowed to revert CC state "every so often".  So,
even if the receiver could game things it would not cause the sender
to behave poorly each time the receiver tried to conceal something.
I.e., we could think about saying "a sender can only undo CC changes
once every 30 seconds" or "a sender can only undo CC changes in
every tenth 'loss events' throughout the connection.  I don't know
that those are right - they are just examples.

Of course, this does not really cure the problem so much as treat
the symptom -- i.e., we don't try to detect lying receivers (& thus
stop helping them) we just decide to not let it hurt too bad when we
are reacting to a malicious receiver.

I am not sure I like this idea... just throwing it out...

allman

---

From: Pasi Sarolahti <[email-masked]>
Date: Wed, 19 Feb 2003 14:58:49 +0200

On Wednesday 19 February 2003 14:38, ext Reiner Ludwig wrote:
> That's the point. Don't you think that a TCP receiver or a middle-box
> could play "ACK games" that would make F-RTO falsely believe a
> timeout was spurious?

Currently I'm in belief that F-RTO should be quite robust against 
these. To cause false declaration of spurious RTO at an F-RTO sender 
the other end (or midbox) should acknowledge a segment that was 
actually lost. If that is the case, the false F-RTO response is the 
smallest of problems the TCP sender has at that time, because the TCP 
end-to-end semantics are messed up anyway at that point.

Btw, I think this is a reason that speaks for not fully reverting the 
congestion control state after detecting a spurious retransmission. 
Should a malicious host find a way to cause false spurious RTO 
notifications at a sender, at least it would not be able to buy more 
congestion window by doing so.

- Pasi

---

From: Reiner Ludwig <[email-masked]>
Date: Thu, 20 Feb 2003 15:14:08 +0100

>that those are right - they are just examples.

On the other hand, we are discussing potentially-to-be *experimental* RFCs. 
Given that, one could argue that we could/should be a bit more relaxed 
about misbehaving TCP receivers and/or bad-mid-boxes. This is not saying 
that we should ignore easy protection mechanisms, but maybe during the 
"experimental phase" we do not have to put all possible engineering smarts 
into such protection schemes.

*If* at some stage we start discussing about advancing a proposal to 
*proposed standard* RFC, it is probably the right time to think harder 
about these security considerations.

So, my current opinion is that at least Eifel Detection/Response (and 
probably also the alternative schemes - I haven't reviewed then yet) should 
go ahead as defined in the current drafts.

///Reiner

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Feb 2003 07:28:07 -0800

Reiner Ludwig wrote:
> On the other hand, we are discussing potentially-to-be *experimental* 
> RFCs. Given that, one could argue that we could/should be a bit more 
> relaxed about misbehaving TCP receivers and/or bad-mid-boxes. This is 
> not saying that we should ignore easy protection mechanisms, but maybe 
> during the "experimental phase" we do not have to put all possible 
> engineering smarts into such protection schemes.
> 

Reiner (et al.),

Is Eifel intended/designed to be _more_ secure against such attacks than 
conventional TCP?

I.e., the metric (for proposed standard, not experimental yet) should be 
"no more insecure than TCP" unless Eifel is specifically trying to 
address these attacks (and that isn't my impression).

Joe

---

From: Mark Allman <[email-masked]>
Date: Thu, 20 Feb 2003 10:49:01 -0500

Joe-

> Is Eifel intended/designed to be _more_ secure against such
> attacks than conventional TCP?
> 
> I.e., the metric (for proposed standard, not experimental yet)
> should be "no more insecure than TCP" unless Eifel is specifically
> trying to address these attacks (and that isn't my impression).

But, that's still pretty fuzzy...  We know that TCP's congestion
control can be gamed (e.g., by ACK division).  And, we know that
adding eifel or DSACK adds an additional way for congestion control
to be gamed.  So, does that mean ...

  * the new schemes are "no more insecure than TCP" because we can
    trick a TCP sender now and we can trick a TCP sender with the
    new schemes, or

  * the new schemes are "more insecure than TCP" because they open
    new avenues for a receiver to trick the sender's congestion
    control

?

I can see it both ways.

allman

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Feb 2003 08:39:01 -0800

>     new avenues for a receiver to trick the sender's congestion

It depends primarily on whether the amount to which you can trick the 
sender (i.e., what you can trick the sender into doing) is worse with 
Eifel or not. Whether it's a new avenue is less significant than whether 
it causes more resultant instability.

Joe