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

From: Mitesh Dalal <[email-masked]>
Date: Thu, 22 Apr 2004 16:36:11 -0700 (PDT)

>From: Carlos Jess Bernardos Cano <[email-masked]>
>
> Hi Mark and all,
>
> 	Thanks for the draft. We have been working on a similar TCP attack to
> the ones pointed in this draft. We submitted an Internet-Draft to the
> TSVWG (the TCPM WG had not been created yet), and we are working on it
> to provide a new version. Current release can be downloaded from
> http://www.it.uc3m.es/cjbc/drafts/draft-azcorra-tsvwg-tcp-blind-ack-dos-01.=
> txt
>
> 	We think (and we have also performed some tests proving it) that the
> attack pointed in our draft is also a very dangerous threat and that the
> proposed changes (server-side changes) eliminate or at least minimise
> the treats to a more acceptable level.
>
> 	Please provide any comment. If the discussion results in this attack
> being interesting to take into account, we can provide a contribution to
> the tcpsecure draft in the form of a section.
>

I had a cursory look at the paper and the paper
seem to be making 3 HUGE assumptions:

1. The server will establish a connection with you.
2. The server has obscene amount of data to send.
3. The application has no authentication of its own.

I have no idea what application you have in mind.
Lets talk about ftp. ftp has username/password
protection. Lets talk about rcp. Client has to
be in the trusted database. Clearly, I cannot
see opening a http connection to a web portal
generating 25MB of data.

I do not even want to go into the solution, but
for starters:

"
 The proposed changes are the following:
   1.  A server SHOULD reset the TCP connection (i.e. send a RST) if it
       receives an ACK for data that is in SND.NXT <= SEG.ACK <=
       (SND.UNA + SND.WND).
"

so you are saying that an attacker needs to hit your
window to hose your legit connection ?

thx
Mitesh

> 	Kind regards,
>
> 	Carlos J.
>
> El mar, 20-04-2004 a las 22:03, Mark Allman escribi=F3:
> > Just announced internet-draft:
> > >  Title           : Transmission Control Protocol security consideration=
> s
> > >  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
> > =20
> > Hi folks!
> >=20
> > 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. =20
> >=20
> > 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.
> >=20
> > A few notes since this I-D got adopted as a WG item with zero public /
> > open input:
> >=20
> >   * Until the vulnerability was announced we didn't want to entertain a
> >     huge discussion on the public mailing list for obvious reasons.
> >=20
> >   * 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.
> >=20
> >   * 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.
> >=20
> >   * 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.
> >=20
> > Any other comments folks have on this draft / issue are very welcome.
> >=20
> > Thanks!
> >=20
> > Mark & Ted
> >=20
> --=20
> Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/
> GPG FP: 1880 80D3 8004 25C7 6537  8E02 252A D295 9CFF DEAF
>
> --=-ByOBr8IpRPQzNa01R822
> Content-Type: application/pgp-signature; name=signature.asc
> Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada
> 	digitalmente
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQBAiAQMJSrSlZz/3q8RAlzRAKDIDArBJnagxolXThkwDwuwMbOBDACfb0Po
> 8b12ChJx9PkrmIu4N2B5X2g=
> =2JHQ
> -----END PGP SIGNATURE-----
>
> --=-ByOBr8IpRPQzNa01R822--
>
>
>
> _______________________________________________
> 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: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 23 Apr 2004 10:24:58 +0200

Hi Mitesh,

	Thanks for your comments. Please, see in-line.
	
> see opening a http connection to a web portal

	The attack can be performed with several tcp connections at the same
time, so it is feasible to get an http server to send this rate (we
tested it with an http server, you can see the numbers we got in the
draft). Notice also, a lot of http servers provide access to quite big
files.

> window to hose your legit connection ?

	No, we aren't. An attacker has to forge the origin IP address and the
ports numbers, not only the window. This is not new, because this can be
done with a RST.

	Kind regards,

	Carlos J.

-- 
Carlos Jesús Bernardos Cano - http://www.it.uc3m.es/cjbc/
GPG FP: 58C3 4227 AF8D 01D4 5A09  A617 E6F2 B23E DAD6 AA40

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Fri, 23 Apr 2004 08:28:07 -0400

>       receives an ACK for data that is in SND.NXT <= SEG.ACK <=

Actually would not this make a RST attack possible to
a blind attacker?

All I have to do is send in a ACK to a connection from
one endpoint to the other... and in a few short segments
I can get one that the SEG.ACK is above SND.NXT and thus
the peer will send a RST to its fellow...

Not good..

R

-- 
Randall R. Stewart
ITD - Transport Technologies
815-477-2127(o) or 815-342-5222(c)

---

From: Yogesh Prem Swami <[email-masked]>
Date: Fri, 23 Apr 2004 08:36:29 -0500

>window to hose your legit connection ?
I haven't read this draft, but acking a lost packet is a potentially 
serious DoS attack as I pointed out in one of my previous e-mail. Once 
the sender receives the ACK (sent either by the attacker or by the 
receiver), the sender will throw away that packet from the send queue. 
But since the receiver has not received the packet (it was lost), it 
will keep generating duplicate ACKs (all of which will be discarded by 
the the sender). This deadlock will take numerous timeouts before the 
sender resets the connection and releases all resources. To perform this 
attack, the attacker has the same "sequence guessing" requirements as in 
the secure TCP draft.

Moreover, such attacks are hard to troubleshoot since the connection in 
one direction will go smoothly, but in the other direction there will be 
a deadlock. In other words, the attacker can render TCP into simplex 
protocol, which is highly unintuitive for troubleshooting. So if you 
posted a web form, the request will reach the server, but there won't be 
any response. (Or in case of BGP, one router will be able to send it's 
routing table to its neighboring router, but the other router won't.)

I don't think "tweaking" TCP will solve this problem but 
Cookies/Sigunatures will (more on that in next few e-mails).This makes 
me think if the problem described in the draft is same as the one I am 
pointing out... Maybe I should read the draft first :-)

Yogesh

---

From: Mitesh Dalal <[email-masked]>
Date: Fri, 23 Apr 2004 08:46:51 -0700 (PDT)

On Fri, 23 Apr 2004, Carlos [ISO-8859-1] Jesús Bernardos Cano wrote:
<snip>
> ports numbers, not only the window. This is not new, because this can be

you are missing my point. With the original spec, even if an attacker
could "guess" the ports and IPs and "hit" the sequences, he will still not
be able get the connection down. But with your change it can. Introducing
the very problem that we are trying to fix.

One important point to note is that in long lived connection, most of
the time (SND.UNA == SND.NXT) will hold true. An attacker will hence have
ample time to DOS your connection with the above strategy.

thx
Mitesh

---

From: Mitesh Dalal <[email-masked]>
Date: Fri, 23 Apr 2004 08:54:19 -0700 (PDT)

On Fri, 23 Apr 2004, Yogesh Prem Swami wrote:
<snip>
> attack, the attacker has the same "sequence guessing" requirements as in

I disagree that its as bad as you think it is. For causing an ACK
attack as above, the attacker has to be correct on 2 axis, on the
number axis and the time axis. Sequence numbers will change throughout
the life of the connection and hence the attacker has to keep up
with the time factor as well. But yes there is a small(very small :)
window of attack possible.

thx
Mitesh

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 23 Apr 2004 21:06:21 +0200

Hi Mitesh,

Please, see in-line

El vie, 23-04-2004 a las 17:46, Mitesh Dalal escribió: 
> On Fri, 23 Apr 2004, Carlos [ISO-8859-1] Jess Bernardos Cano wrote:
> <snip>

Let's see if I get your point. If there is a TCP connection between A
and B, and there is a malicious node M that wants to make A to reset the
connection with B, it may do:

- (TCP stack in A with the modification we propose to make more
difficult the DoS attack described in our draft). M has to send a ACK
with SEG.SEQ:

RCV.NXT =< SEG.SEQ < (RCV.NXT + RCV.WND)

Besides, the SEG.ACK has to match:

SND.NXT <= SEG.ACK <= (SND.UNA + SND.WND)

But notice that with a standard RFC793 TCP, M can send a RST with
SEG.SEQ:

RCV.NXT =< SEG.SEQ < (RCV.NXT + RCV.WND)

and this attack is easier to perform than the first one, isn't it?. So
it doesn't seem that our proposal increases the feasibility of this kind
of attack.

Kind regards,

Carlos J.

---

From: Yogesh Prem Swami <[email-masked]>
Date: Fri, 23 Apr 2004 15:35:58 -0500

>window of attack possible.

I agree that the probability is smaller, but not as small as you seem to 
suggest (How small is "very small" in your definition?).  The 
probability of guessing  a valid sequence number within advertised 
window is as much as is pointed out in the draft. An attacker can just 
keep sending an ACK with ACK sequence number ACK_guessed + rcv_wnd. At 
some point, the tcp congestion window will slide over this sequence 
number, and if there happens to be a packet loss, the connection will 
get deadlocked. So there is no time axis ...

The fact that there is a need for packet loss, is what reduces the 
probability of an attack. But on the other hand, once attackers have 
achieved their goal, it will take ~hours (depending upon RTO_MAX and 
other parameters) before anyone will notice something is wrong. I don't 
know if you would consider this as a worrisome situation.

Yogesh

---

From: Mitesh Dalal <[email-masked]>
Date: Fri, 23 Apr 2004 13:53:00 -0700 (PDT)

> suggest (How small is "very small" in your definition?).  The

to the point of being negligible.

> window is as much as is pointed out in the draft. An attacker can just

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

> number, and if there happens to be a packet loss, the connection will

for this you have to send ACKs much faster than the data transfer
actually underway.

thx
Mitesh