Subject: Re: [tcpm] new work item: TCP security issue

From: Mitesh Dalal <[email-masked]>
Date: Wed, 21 Apr 2004 14:48:25 -0700 (PDT)

>From: David Borman <[email-masked]>
>Hi,
>
>Well, all the discussion about process has been interesting, but I'd 
>like to discuss the actual changes suggested in the draft.  I received 
>initial information about this over a month ago, and I've already spent 
>a fair amount of time analyzing these 3 items.  They do change TCP's 
>behavior wrt SYN packets.
>
>To state the obvious, these only address blind attacks.  If the bad guy 
>can see any of the packets for the connection that is being attacked, 
>you can't do anything to the TCP protocol to protect things, except use 
>IPsec.  Using application level security like SSH does not secure the 
>TCP connection, and so they are still vulnerable to these types of 
>attacks.  What the draft addresses is the probability that an attacker 
>can forge a packet with a format that will be accepted as valid.  This 
>story has made a splash on the news wires, and I think there's a bit of 
>"the sky is falling" in them.  But then, that's what the news media 
>does, right?
>
>First, the RST issue.  RST packets can be used to reset a connection, 
>and you just have to get it anywhere in the window, not an exact 
>sequence match.  The additional check is that if the RST isn't exactly 
>what we expect it to be, generate an ACK, and if the original RST was 
>valid, another RST will be generated in response to that ACK with an 
>exact match and then the connection will be dropped.  If the original 
>RST was bogus, our ACK will be ignored and the connection stays up.  I 
>can think of some end-case scenarios where the second valid RST might 
>still not be exact, but that would just generate another ACK and it 
>should become deterministic at some point and the RST be accepted.  The 
>only way you'd get into trouble would be if someone was generating an 
>RST in response to an ACK, and not properly swapping the seq/ack 
>fields.  If that happened, you could get into an RST/ACK war...

that would be a buggy implementation and we would be doing them
a favor by exposing this bug :)

>The change for in-window SYN processing actually changes TCP's 
>behavior.  Currently, if you get a SYN in-window, you abort the 
>connection and send a RST back to the other side.  So, the attacker 
>just has to get the SYN in the window to blow the connection away.  The 
>change is to generate a current ÅCK in response to a SYN, and if the 
>SYN was legitimage, our ACK will cause a RST to be generated, which 
>will cause our half-open connection to be dropped.  The change to TCP 
>is that the other side is still up, and when the SYN gets 
>retransmitted, we'll establish a new connection.  This new connection 
>will have its sequence space overlapping the window of the old 
>half-open connection, so we now have the possibility that the new 
>connection will get and accept packets from the old connection...

From the above context by half open, I assume you mean in ESTAB from
your end. The problem you have described above can also happen in a
standard setup. Lets assume peering between 2 BGP systems. One end
sends RST. Connection is closed and comes up again (fast enough!) 
and happens to have the same sequence space. A packet delayed in 
network for the old connection lands up in the new connection. 
Same behavior should manifest, correct ?

>On  the item of data injection, I haven't totally convinced myself of 
>the
>	((SND.UNA - MAX.SND.WND) <= SEG.ACK < SND.NXT)
>check.  For a unidirectional data transfer, this isn't a problem, 
>because SEG.ACK remains constant.  I'm wondering about the 
>bi-directional data transfer case, but I haven't come up with an 
>example yet to either prove or disprove that this check will not throw 
>away legitimate packets (but if it did, it should be a transient issue 
>and the retransmitted packets should have more current ACK information 
>and get accepted).  Note that in the extreme case of using a window 
>scale of 14, and advertising the whole window (2^30), these changes 
>don't really provide much protection, since you'll have almost 1/2 of 
>the sequence space as being valid for the ACK check.  If they can guess 
>an in-window sequence number (easier, since it's 1/4 of the sequence 
>space), they just a couple of packets with different ACK values should 
>get one of them into the connection.  This protects things best when 
>the maximum window is kept small.

yes, the advantage decreases as the window size increases.

thx
Mitesh

>Anyway, those are my initial comments, I'm sure others will have other 
>insights into this.  (It's nice not to be under NDA anymore about this)
>
>			-David Borman, [email-masked]
>
>
>On Apr 20, 2004, at 3:03 PM, Mark Allman wrote:
>
>>
>> Just announced internet-draft:
>>>  Title           : Transmission Control Protocol security 
>>> considerations
>>>  Author(s)       : R. Stewart
>>>  Filename        : draft-ietf-tcpm-tcpsecure-00.txt
>>>  Pages           : 10
>>>  Date            : 2004-4-20
>>>  http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt
>>
>> Hi folks!
>>
>> We wanted to announce a new I-D and TCPM work item.  The draft is
>> "Transmission Control Protocol security considerations"
>> (draft-ietf-tcpm-tcpsecure-00.txt).  We believe we owe a bit in the way
>> of explanation since it seems that this is being foisted upon the WG
>> without much input.
>>
>> The brief story is that a bunch of folks were made aware of the TCP
>> security vulnerability outlined in the above draft.  (I think many
>> people have been aware of these things for a long time.  But, the 
>> driver
>> here is that there is a new conference paper that is going to show the
>> ease with which the vulnerability can be exploited.)  Many people from 
>> a
>> number of TCP implementers (vendors) have been busily working behind 
>> the
>> scenes to come up with reasonable fixes before the vulnerability was
>> announced.  The fixes are in the I-D.  The vulnerability has been
>> announced (via the standard security issues venues).  As part of this
>> process Randall Stewart wrote the above mentioned I-D for this WG to
>> ponder.
>>
>> A few notes since this I-D got adopted as a WG item with zero public /
>> open input:
>>
>>   * Until the vulnerability was announced we didn't want to entertain a
>>     huge discussion on the public mailing list for obvious reasons.
>>
>>   * The transport ADs, security ADs and TCPM WG chairs all agreed that
>>     this is an important problem to address and that TCPM is the 
>> correct
>>     WG in which to address it.  That said, if folks think we made the
>>     wrong call here, please feel free to speak up and tell us why we
>>     screwed up.
>>
>>   * The fixes suggested in the above I-D are not being pre-judged as
>>     *THE* answer.  Rather, they represent *A POSSIBLE* solution (and
>>     running code) that this WG will consider.  In other words, we are
>>     not trying to simply ram this document through the WG and produce 
>> an
>>     RFC.  This WG will deliberate on the I-D as it would any other.
>>
>>   * Alternate solutions are welcome.  We would like to encourage folks
>>     who have different solutions to the problems outlined in the draft
>>     to put those forward for consideration.
>>
>> Any other comments folks have on this draft / issue are very welcome.
>>
>> Thanks!
>>
>> Mark & Ted
>>
>>
>>
>
>
>_______________________________________________
>tcpm mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/tcpm

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

---

From: [email-masked]
Date: Fri, 23 Apr 2004 16:49:57 -0500

> 
> I do not think the comparison holds. In the attack as described in the
> draft, its most focuses on long lived connection where no data/ACK is
> inflight. Here the attacker has ample time to guess the window. He

Hoon... Now I understand better. 

Yogesh

> simply needs to systematically increase sequence by window 
> size. But if
> you are actively sending and receiving stuff, how does an 
> attacker keep
> up with this. What algorithm does he need to use ?
> 
> try this: setup a rcp connection between 2 boxes and do an active data
> transfer. Try to hose this connection with the ACK attack you mention.
> Now try the RST attack in the draft. You have a steady telnet (or bgp)
> connection and systematically send it RST with incremental sequences.
> 
> Which do you think will be harder to achieve ?
>