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

From: Mark Allman <[email-masked]>
Date: Tue, 20 Apr 2004 16:03:40 -0400

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 20 Apr 2004 15:13:43 -0700

> A few notes since this I-D got adopted as a WG item with zero public /

Mark,

Er, well. Let's talk about that. Last I checked, we rejected kings, 
which includes input of this sort from the top down.

This draft should be withdrawn and resubmitted as individual 
immediately, since it is NOT YET a WG doc - not until _we_ start the 
process. The _WG_ - not the IAB, not the IESG, etc. - should decide for 
ourselves whether we want the individual item (after we READ it) as a WG 
item.

Also, temporal order is important - i.e., 'it's a WG doc if the 
IESG/chair decide and THEN we get to nix it'. This is a bottom-up 
process. _THEN_ the hierarchy gets to decide whether we can work on it. 
Not the other way around.

(FWIW, I would concur that this should be a WG doc anyway; this isn't 
about the doc, it's about the recurring abuse of process).

Joe

---

From: Mark Allman <[email-masked]>
Date: Tue, 20 Apr 2004 20:27:49 -0400

Joe-

> which includes input of this sort from the top down.

I agree.

I also hope that we can agree that within the IETF we can drop the
rigidity and can, on ocassion, trust the leadership to chart a
reasonable *course* (note I *did not* say "make the correct
*decision*").  We all chatted about this late last week and felt that it
would be good to show that the IETF is actively interested in fixing one
of its core protocols when the vulnerability was announced.  Maybe that
was the right call, maybe it was not.  But, it was a call we made.  To
elaborate...

  * There are no black helicopters here, Joe.  As soon as the draft was
    announced I sent a note that Ted and I drafted explaining things.
    We did not try to sneak this by the WG or the broader community.  We
    were as up-front as we could be given the constraints.

  * I agree that this is not the right process in general.  The WG
    should get first crack at determining whether a particular document
    will be a WG work item or not.  That is the process the IETF uses.
    That will be the process this WG uses.  I believe the chairs
    understand that quite well.

  * That said, I hope that we can allow for a little flexibility in
    certain situations.  This is clearly not a normal situation any way
    you look at it.  I hope that the community can withstand a little
    process bending in such cases.  One can argue that a little bending
    leads to a lot of bending, of course.  And, so it's fine with me
    that you think we have made the wrong call and that you have
    recorded the dissent.  If it turns into a pattern we should be
    flogged in the plenary.

  * As indicated in the previous mail, we did not finalize anything.
    There was no RFC approved and queued up behind the scenes.  We
    charted a course, we did not make a decision.  There is a difference
    and I hope you can recognize that.  Sometimes decisions need to be
    made.  We have selected leadership to, among other things, lead.

> (FWIW, I would concur that this should be a WG doc anyway; 

Good.  I am glad we can agree on that.

> this isn't about the doc, it's about the recurring abuse of process).

I'd like you to elaborate because as that stands it smells like so much
hyperbole and bullshit from where I am sitting (which is the target of
your email).

Thanks!

allman

--
Mark Allman -- ICIR -- http://www.icir.org/mallman/

---

From: Joe Touch <[email-masked]>
Date: Tue, 20 Apr 2004 17:45:16 -0700

Mark Allman wrote:
> *decision*"). ...
> ...   We have selected leadership to, among other things, lead.

Mark (and this will be the last post, primarily to elaborate as 
requested below; I'll be glad to take this offline otherwise),

That's where we disagree. IMO, the 'leadership' is here to help the WGs 
get work done, not to lead us.

...
> hyperbole and bullshit from where I am sitting (which is the target of

This is driven by the "leadership" at the last TSVWG meeting, where a 
presentation on yet-another (IMO) QoS system was presented. The WG gave 
the presentation a resounding thud (IMO), i.e., when people were asked 
to review the doc, a standing-room-only crowd couldn't offer the 
requested 3 volunteers sufficiently interested to participate.

That smacked of the IESG deciding what was important for the WG; this 
does to. From where I sit, as Jose Wales said, "Don't piss down my back 
and tell me it's raining" (to continue the scatology).

There were no helicopters, and thus there also was no URGENT need to 
usurp the process of the WG by side-stepping procedure. There was plenty 
of time to show that doc to the WG and get feedback; it would have taken 
a day or two. That's still the IETF "reacting to the situation".

You didn't need to make a decision on behalf of the WG to appear to be 
acting quickly. Whether I trust you or not (and generally, you in 
particular I do) isn't the point.

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 21 Apr 2004 02:14:53 +0100 (BST)

> and tell me it's raining" (to continue the scatology).

Fletcher (John Vernon) said THAT - to the Senator. Josey Wales did
not.

what's in a (draft) name?

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 20 Apr 2004 18:32:09 -0700

A clarification, in case it was ambiguous:

...
> about the doc, it's about the recurring abuse of process).

By "recurring" I am referring to other actions by the IESG and other WG 
chairs, some of which are addressed in the process update revisions 
already underway.  I am not referring to either Mark or Ted, in case 
that was not clear.

Joe

---

From: David Borman <[email-masked]>
Date: Wed, 21 Apr 2004 11:57:33 -0500

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

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

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.

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]

---

From: Florian Weimer <[email-masked]>
Date: Wed, 21 Apr 2004 23:59:50 +0200

I don't qyite like sending ACKs for RSTs.  This might result in a loop
when one side generates an ACK, the other side replies with an RST,
and the first side sends the next ACK.  Of course, the sequence and
port numbers have to match.  But if there are implementations out
there that interact in this way, you might create a cure that is far
worse than the disease.  At least you should mention the requirement
of rate-limiting those ACKs.  (It's implicit for IOS because of the
limits on the RST processing, but not for general implementations.)

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: atlas.cz, bigpond.com, postino.it, tiscali.co.uk,
tiscali.cz, tiscali.it, voila.fr.

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 21 Apr 2004 18:10:39 -0700

> fields.  If that happened, you could get into an RST/ACK war...

Yes.  What I am worried is interaction with middlebox.  I've
seen broken stateful middlebox causing ACK war.  With this kind
of "subtle" change, I think it will hit someone.  And since this
kind of attack is mostly targeted at a specific type of TCP
traffic, such as long lived, I think most implementors are not
comfortable in making these changes.

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

Again, ACK is used as a form of challenge/response.  It can be
considered as "ingenious" or a "hack."

> On  the item of data injection, I haven't totally convinced myself of 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 

As you mentioned, can this happen in bidirectional transfer
with delayed out of order segments and one side is sending
faster than the other side?  And the probability increases
as the number of outstanding segments get big (large window) in both
sides.

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

As people have already asked, should we have a more general solution?
RFC 2385 is a solution, but it can be expensive and there needs to be
a key exchange.  Can a simple mechanism similar to SCTP verification
tag be used?  Randy already explained the mechanism in another mail.
It can be enabled by a socket option so that only app protocol
vulnerable to this type of attack will use it.  And it is simple
enough for header compression, if it is needed.  What is the issue
with that?

-- 

						K. Poon.
						[email-masked]

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Thu, 22 Apr 2004 06:43:21 -0500

>limits on the RST processing, but not for general implementations.)

So you are saying that the receiver of the ACK, which
in theory sent the RST and has no state, is going to
send a subsequent RST with a different value than
is in the ACK? If this were true would it not be a
bug in the implementation?

R

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

---

From: Florian Weimer <[email-masked]>
Date: Thu, 22 Apr 2004 14:50:06 +0200

> bug in the implementation?

It would certainly be a bug, but it's something to consider
nevertheless, IMHO.

---

From: Mitesh Dalal <[email-masked]>
Date: Thu, 22 Apr 2004 09:23:46 -0700 (PDT)

> comfortable in making these changes.

could you please elaborate on a scenario which you think might
potentially happen and could cause more problem with this fix
than without this fix ? It would be nice to fix any scenario
that we might have overlooked.

Lets consider the scenario where we have a firewall B sitting in
between peers A and C. C sends a RST that is not an exact match.
B however does not have the current fix and cleanups its state
and asks A to do the same. A however does not like the RST and
sends an ACK. Since the firewall does not have an entry, it will
drop the same. No harm done except that A is left holding the
bag. Here your personal paranoia comes into picture. Is it better
to be left holding a dead connection or get reset on a potential
DOS RST packet. The same will hold true for the SYN part.

and yes  the firewall vendors need to catch up with the
new RFCs. Example in point ECN. When ECN was standardized,
most firewalls didnt even understand TCP ECN.

thx
Mitesh

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 22 Apr 2004 19:42:36 +0200

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.

	Kind regards,

	Carlos J.

-- 
Carlos Jesús Bernardos Cano - http://www.it.uc3m.es/cjbc/
GPG FP: 1880 80D3 8004 25C7 6537  8E02 252A D295 9CFF DEAF

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 22 Apr 2004 13:14:34 -0700

> that we might have overlooked.

The problem with middlebox, especially those targeted at home

> DOS RST packet. The same will hold true for the SYN part.

If you were the programmer for the firewall, I am happy (-:  But
the truth is that firewall code is sometimes not that good.  A sends
back the ACK and the firewall B does not have a state.  But B may try
to  "optimize" traffic and generate a RST on its own.  Now that B may
also do NAT.  Somehow there is a mix up when doing all the NAT/RST
generation (or it is not a mix up as B is a NAT and it is "clever"
enough to save up RSTs for exactly this kind of scenario) that it
also sends a RST which A does not like.  Oops...

> most firewalls didnt even understand TCP ECN.

The issue with ECN is easier to see, TCP connection just cannot be
established.  And the workaround is easy, disable ECN.  But the
changes we are discussing here is very fundamental and cannot be
disabled, at least this is how I understand the draft.  So I think
we should be very cautious in moving forward.  This is one reason why
I prefer to have an option so that it can be disabled in case we find
something bad happen later.  Or reuse the timestamp option if feasible.

-- 

						K. Poon.
						[email-masked]