Subject: RE: FW: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt

From: [email-masked]
Date: Wed, 21 Apr 2004 17:30:38 -0500

Mitesh-

> -----Original Message-----
> From: ext Mitesh Dalal [mailto:[email-masked]]
> Sent: Wednesday, April 21, 2004 4:22 PM
> To: [email-masked]; Swami Yogesh (Nokia-NRC/Dallas)
> Subject: Re: FW: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt 
> 
> 
> 
> >>  -----Original Message-----
> >> From: 	Swami Yogesh (Nokia-NRC/Dallas)  
> >> Sent:	Wednesday, April 21, 2004 10:59 AM
> >> To:	[email-masked]
> >> Subject:	
> >> 
> >> [Few late comments]
> >> 
> >> Although I have not read the draft thoroughly, I believe 
> it's probably a good 
> idea to fist define the scope of the problem that this 
> working group should try 
> to solve. TCP has a lot of vulnerabilities -- lot more than 
> what this draft 
> identifies -- and it's better to first define which problems 
> should be solved 
> and which one should not be. (Also, if the problem exists 
> only because of BGP, 
> which I don't think is the case, then maybe routers can use 
> IPSec with a well 
> known permanent shared key with different session keys. This 
> will be more 
> secure, compared to this draft, and faster to deploy.)
> >> 
> 
> Yogesh,
> the idea is to address blind attack from an attacker sitting 
> outside your
> path to the peer. The current problem is critical because it 
> takes fewer
> packets than originally believed. 
> 

I don't know if the problem is critical or not and I wasn't questing that. Sending 65,535 RST messages might be a problem for BGP, but in the broader context of TCP it might not be. A very simple intrusion detection system can (and already do) detect and drop such bursts of packets, especially when each packet has the same socket attribute.

> By lots of vulnerabilities I assume you mean brute force attacks such 
> as SYN attack, reflection attacks and man in the middle kind 
> of attack. 

No, by lots of vulnerabilities, I don't mean brute force attacks. Resetting a TCP connection might be a problem for BGP but might not the best MO for other kinds of blind attacks. For example, an attacker who wants to do blind DDoS attacks, might want to use exploit other TCP vulnerabilities (e.g., use ECN to reduce data rate) to reduce the connection handling capacity of the server than resetting the connections altogether. 

If the draft tries to make TCP more secure, as the title suggests, it needs to take a broader look than just BGP. Or it should explicitly say: "we are not looking at ..." (which is also perfectly alright with me). That's why I said it's better to define the scope of the problem.

> We are clearly not addressing these. I would be glad to hear 
> if you have
> come across similar vulnerabilities as the current draft 
> tries to address.
> 

Although I have not come across these problems myself, conventional wisdom says that if there is a security vulnerability in a protocol, it will be exploited sooner or later. The fact that this draft exists today and did not exist 10 years back, is a good evidence.

> >> Moreover, it will also be useful to specify if the 
> proposed solutions can use 
> cryptography or not. Many people are not comfortable with 
> cryptographic 
> techniques partly because of throughput reasons. But in many 
> cases it might be 
> useful to have a low computation cryptographic methods to 
> solve the problems 
> without hurting the throughput. For example, a TCP sender 
> with Time Stamp option 
> could just encrypt the 32 bit timestamp using AES, and 
> practically solve all the 
> problems in this draft. (I am not saying we should do this). 
> Encrypting a 32 bit 
> number doesn't take a lot of time/computation and the 
> receiver doesn't need to 
> keep states to make this work. And, in principle it's not 
> different from having 
> a challenge response cookie.)
> 
> Cryptographic solutions have their own limitations. They have 
> to be setup
> at both ends and have to be agreed upon. In the current 

Not necessarily. You need setup/key-exchange only if both ends need to perform cryptographic operations on the same data fields. For TCP we might not need that. Or we might, depending upon what the working group considers as a secure solution. And, that exactly what my point was in the last e-mail. 

BTW, I doubt you will get easy consensus on the solutions without precisely defining what "secure TCP" means. Security means different things to different people at different times of the day.

--Yogesh

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

---

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

Yogesh:

A few comments...

First.. the draft name was quickly hacked together.. we
can always change the name to reflect that it is
a tweak to TCP to tighten things against blind
attacks...  Does it solve all problem.. no of course
not...

More comments below...

>I don't know if the problem is critical or not and I wasn't questing that. Sending 65,535 RST messages might be a problem for BGP, but in the broader context of TCP it might not be. A very simple in…
Hmmm... it does not have to be a burst of packets.. they can
be paced out to not cause alarm... and in practice it is
far less than 64k packets... in general sending a a paced
50pps I was able to reset most TCP connections in a very
very short time.. when I first started testing this thing...

Now as to BGP and others.. what about H.323 and some
of the other VoIP stuff .. I believe not all of them have
went with SCTP ... many use TCP.. and these are all
vulnerable... and I am sure there are a LOT of other
apps that do database connections and such...

I don't think this problem is limited to just BGP...

>If the draft tries to make TCP more secure, as the title suggests, it needs to take a broader look than just BGP. Or it should explicitly say: "we are not looking at ..." (which is also perfectly al…

The lets pick a new name... and yes, I have no problem
adding limitation text at the beginning...

To quote Scott..

Send text ....

R

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

---

From: Yogesh Prem Swami <[email-masked]>
Date: Thu, 22 Apr 2004 09:59:50 -0500

Hi Randall,

Please see my comments inline:

>I don't think this problem is limited to just BGP...

I agree.

>adding limitation text at the beginning...

Not the exact text.... But here are my thoughts.

Three different kinds of attacks are possible on TCP.

1.  Premature Resource Release (PRR) attacks: Attacks that are described 
in this draft fall in this category. The impact of these attacks are 
limited to a few connections, but if these few connections are very 
important as in case of BGP or H.323 (I am taking your word for H323), 
then the attacker can create a havoc. (BTW, in BGP when the connection 
is reset, the state machine restarts the connection withing some time 
period. Also, on my zebra/bgpd router running on Linux,  the router did 
not immediately advertize that the link is down. I had the impression 
that bringing the TCP connection down will cause new route 
advertizements which will delay the convergence of routing tables, but 
this doesn't seem to be the case. Is this because I only have 6 routers 
in my lab? I am just trying to undertsand what the problem is. But back 
to attacks...)

2.  Forced Resource Saturation (FRS) attacks: SYN flooding (without SYN 
cookies) is the most common example of FRS attack, but FRS is not 
limited to SYN flooding attacks. For example, an attacker can send an 
ACK for a data packet that was actually lost in the network. Since the 
receiver did not receive the packet, it will keep sending the duplicate 
ACKs for the lost packet, but since the sender has received an ACK, it 
will never retransmit the data packet (it doesn't have that packet in 
the send queue). This is a very expensive deadlock. (There are other 
similar--not necessarily as expensive--attacks possible. I can't exactly 
recollect them so early in the morning.)

3.  Inappropriate Congestion Window (ICW) attacks: These attacks are 
mainly possible by a cheating sender or a middle box (but it can also be 
done by blind attackers with low success rates). Eifel detection  
algorithm could easily fall prey for this kind of attack in which the 
receiver never sends the timestamps for the recent most packet, but of 
the last packet received. This attack will allow the receiver to never 
go into slow start after real-timeout.

There might be other attacks which I might not be aware of.

So now my question is, which of these categories of attacks should be 
solved and which ones should not be. (I'd vote for 1 and 2, and leave 3 
out). Also, there are different routes that one can take to solve these 
problems.

Route-1: Fix individual vulnerabilities in the protocols by changing the 
protocol mechanism itself. "TCP secure" draft has taken this route.

Route-2:  Have a single protocol mechanism (e.g., by defining a new 
option or reusing an old one) that solves most of the problems.(I'd 
personally prefer this over Route-1). For Route-2, again there are 
couple of options.
   
          Route-2-a: Use crypto methods to solve the problem, but 
without doing key exchange. (Got my vote)
          Route-2-b: Use crypto, but with key exchange.

I guess the working group needs to decide what is the best way forward.

Yogesh

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Thu, 22 Apr 2004 10:23:27 -0500

Yogesh Prem Swami wrote:

>>>> path to the peer. The current problem is critical because it takes 
>>>> fewer
>>> I don't know if the problem is critical or not and I wasn't questing 
>>> that. Sending 65,535 RST messages might be a problem for BGP, but in 
>>> the broader context of TCP it might not be. A very simple intrusion 
>>> detection system can (and already do) detect and drop such bursts of 
>>> packets, especially when each packet has the same socket attribute.
>>>
>>>
>>>
>>>   
>>
> 1.  Premature Resource Release (PRR) attacks: Attacks that are 
> described in this draft fall in this category. The impact of these 
> attacks are limited to a few connections, but if these few connections 
> are very important as in case of BGP or H.323 (I am taking your word 
> for H323), then the attacker can create a havoc. (BTW, in BGP when the 
> connection is reset, the state machine restarts the connection withing 
> some time period. Also, on my zebra/bgpd router running on Linux,  the 
> router did not immediately advertize that the link is down. I had the 
> impression that bringing the TCP connection down will cause new route 
> this doesn't seem to be the case. Is this because I only have 6 
> routers in my lab? I am just trying to undertsand what the problem is. 
> But back to attacks...) 

I am no BGP expert... but if I remember my BGP reading a year or
so back the spec requires that when the connection breaks the routes
are withdrawn... Zebra, If I remember right, is not a full complete BGP
implementation.. and also different vendors do it differently.. some will
pretend for some time that the connection stays up while a re-connect
attempt is done.. others will not..

>
>
> 2.  Forced Resource Saturation (FRS) attacks: SYN flooding (without 
> SYN cookies) is the most common example of FRS attack, but FRS is not 
> receiver did not receive the packet, it will keep sending the 
> duplicate ACKs for the lost packet, but since the sender has received 
> an ACK, it will never retransmit the data packet (it doesn't have that 
> packet in the send queue). This is a very expensive deadlock. (There 
> are other similar--not necessarily as expensive--attacks possible. I 
> can't exactly recollect them so early in the morning.)
>
> mainly possible by a cheating sender or a middle box (but it can also 
> be done by blind attackers with low success rates). Eifel detection  
> solved and which ones should not be. (I'd vote for 1 and 2, and leave 
> 3 out). Also, there are different routes that one can take to solve 
> these problems.
>
> Route-1: Fix individual vulnerabilities in the protocols by changing 
> the protocol mechanism itself. "TCP secure" draft has taken this route.
>

> I guess the working group needs to decide what is the best way forward. 

I agree the wg needs to decide this... using route-2 normaly means you
are adding more stuff in the options space... and some would not like
this.. I am not sure I have an opinion as yet.. I would need to see
details of the various proposal...

Having been involved in this for quite some time... the draft puts
forward simple small fixes that can be implemented quickly and
close up most of the holes... is it the best solution probably not.. but
considering the trade-offs it seemed the correct way to go... so
I guess you know I vote for route-1 :-D

R

---

From: Joe Touch <[email-masked]>
Date: Thu, 22 Apr 2004 16:56:27 -0700

Randall Stewart (cisco) wrote:
...
> attempt is done.. others will not..

It would, FWIW, be useful to nail this down and cite something specific 
about it in the draft. I.e., there are two reasons this problem may be 
important:

	a) kills connections
		which could cause a loss of a lot of data,
		though (IMO) anything with that much data
		ought to know how to restart and recover
		from where it left-off (i.e., what it ACKd)

	b) killed connections can hurt BGP more than some other
	apps.
		that warrants a fix to BGP, IMO.

Joe

---

From: Jeremy Harris <[email-masked]>
Date: Fri, 23 Apr 2004 02:05:26 +0100

>          Route-2-b: Use crypto, but with key exchange.

Route-2-c: expand the sequence space.

     (No crypto, another option, two (say) 64-bit sequence numbers
      per packet; the probability swings against the attacker)

- Jeremy

---

From: Mitesh Dalal <[email-masked]>
Date: Thu, 22 Apr 2004 18:25:32 -0700 (PDT)

>       per packet; the probability swings against the attacker)

the problem with this route is that option space is already at
a premium and further this may not be backward compatible.
If option agreement fails you still remain vulnerable ?

thx
Mitesh

---

From: Florian Weimer <[email-masked]>
Date: Fri, 23 Apr 2004 15:49:36 +0200

Joe Touch <[email-masked]> writes:

> It would, FWIW, be useful to nail this down and cite something
> specific about it in the draft. I.e., there are two reasons this
> problem may be important:
>
> 	a) kills connections

Ahem, not what it ACKed.  Proper recovery has to be done above the TCP
level because data that has been ACKed can be discarded nevertheless
(for example, when an RST ist received before the data has been
delivered to the application).

It's quite hard to find protocols that rely on long connections and
have no appropriate restart handling.  Are there any protocols
commonly used over the Internet except BGP and IRC which have that
property?

> 		that warrants a fix to BGP, IMO.

BGP tends to assume that a TCP connection can be established if and
only if the link is working.  This is not true with current TCP, it's
neither a sufficient nor a necessary condition.

-- 
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: Yogesh Prem Swami <[email-masked]>
Date: Fri, 23 Apr 2004 10:25:47 -0500

>      per packet; the probability swings against the attacker)

This is a valid option and probably worth considering. But having a 
crypto based method can help in detecting, if not preventing, a broader 
range of attacks. For example, sequence numbers will not be able to 
detect/prevent if the attacker (typically a virus) can see packets on 
the end to end path. Although it might be hard to prevent such 
man-in-the-middle attacks, it will be useful to have a scheme which can 
detect (with high probability) the possibility.

Yogesh

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Apr 2004 13:27:56 -0700

Florian Weimer wrote:

> Ahem, not what it ACKed. 

The ACKd data is potentially lost, as you note below, by the apps.

> Proper recovery has to be done above the TCP

Certainly - some apps do this, some don't. What I'm suggesting is that
one reccomendation of this sort of ID would be "apps sensitive to
assasination of longstanting connections should support restart".

> commonly used over the Internet except BGP and IRC which have that

File transfer sometimes does and sometimes does not support it; that's
at least one example I was thinking of. (FTP supports it, but it is
often not used).

> neither a sufficient nor a necessary condition.

TCP is a protocol for reordering and retransmitting data (among other
things, e.g., controlling flow of the data, etc.). A link 'liveness'
indicator it is not; consider how much it tells you about a link if the
transfer goes idle.

I.e., if BGP is using TCP as a heartbeat or link tester, it is BGP that
is committing the error and needs a fix.

Joe

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 23 Apr 2004 17:09:37 -0500

Joe Touch wrote:

...
> is committing the error and needs a fix.

If it can be sufficiently established that in the real world there are only a few app
protocols (BGP as one of them) that are actually impacted by those vulnerabilities, it may
make more sense to leave TCP alone and simply recommend those few apps to consider using
SCTP which seems to be fairly robust against those attacks.

regards,
-Qiaobing

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 23 Apr 2004 23:25:11 +0100 (BST)

I'm interested in the proposed RST ack challenge/response mechanism.

I expect the case that the valid packet received containing the RST
flag is _not_ the packet the receiver was expecting with the next
expected sequence number to be quite common, with packet reordering in
the Internet, loss (and don't users often kill slow browser
connections?), and whatnot. Connections don't always get closed under
the best of conditions.

It strikes me that, a priori, both sender and receiver know and can
remember the initial sequence number ever used on their connection,
which is (pseudo-randomly) selected. Randomness of initial sequence
numbers was recently improved, after much media fuss:

http://www.google.com/search?q=initial+sequence+number+randomness

We can use this randomness to our advantage.

This first sequence number information can be used to form part of the
challenge-response; if the sender has sent an RST packet whose
sequence number lies in the window, but it is not the next expected
packet, the ack sent back by the receiver can be an indicator for the
RST sender to pass the first sequence number in a subsequent packet
(also containing a confirming RST flag. 'I told you to close. I'm
telling you to close again. And here's a reminder of when we first
spoke and agreed to open. It's a random number we both know.'.)

I suppose this could be passed as (sigh) a new TCP option -- or,
better, you could just use the existing sequence number field.

Existing TCP implementations would ignore this second RST packet
containing the original first sequence number in that field if that
correct number lies outside the window, and if it's inside, well,
you've already sent one RST anyway. You're likely backwards
compatible.

This weak authentication might give added protection to long-lived TCP
flows, as the attacker would need to snoop on the start of the
connection to know that first sequence number - and if she's doing
that, your unsecure data can already be hers. (Why is there so much
fuss about a weak DoS attack and no fuss about the widespread reliance
on an unsecure transfer protocol?)

And in tying to sequence space, which is where our problem lies,
storing and resending the initial sequence number on request as a
cookie seems somewhat easier to code and deal with than the later and
optional timestamps (K Poon's suggestion), as we avoid option fields
entirely.

L.

apologies if this has already been suggested in these related threads.
Unfortunately, my life prevents me from reading email full-time.

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

---

From: Tim Shepard <[email-masked]>
Date: Fri, 23 Apr 2004 19:19:06 -0400

> spoke and agreed to open. It's a random number we both know.'.)

If I'm sending you a RST because I rebooted and lost all state and
don't have any state for the TCP connection that you apparently have
becasue you are sending me packets, how am I supposed to remember what
the initial sequence number was?

Here's an idea (just thinkint out loud here) for solving the BGP problem:

Ignore RSTs and just let keep alive failures and timers take care of
tearing down old connections.

(and continuing to think out loud here....)

Joe Touch recently suggested that IPsec/ESP with Null encryption and
authentication would effectively put in place a cookie mechanism (the
SPI being the cookie) which would be sufficient to solve these
probelms.  But that just pushes the problem of handling a TCP RST to
figuring out how to "RST" a IPsec SA.  And my understanding of that
problem (which is based on recent discussion in HIP WG) is that when a
packet shows up with an unknown SPI, that you might have a mechanism
that sends back an advisory "unknown SPI" notification, but that when
you receive an "unknown SPI" notification, there's not much you can do
with it because it could be someone spoofing you.

So it seems just hacking your TCP implementation to ignore RSTs
might give you the same robustness that you'd get from
null-encryption, null-authentication IPsec ESP.

			-Tim Shepard
			 [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Apr 2004 16:48:32 -0700

Tim Shepard wrote:

...
> figuring out how to "RST" a IPsec SA.

Why do I have to RST an SA?

I certainly have to re-key. But otherwise the only party sending a RST 
will be inside the SA anyway.

> And my understanding of that

Sure - which begs the question as to why you're doing anything with 
unknown SPIs other than dropping the packet silently, as required.

To reply in any way would be a violation of 2401.

---

From: Kacheong Poon <[email-masked]>
Date: Fri, 23 Apr 2004 16:53:31 -0700

> the initial sequence number was?

Although people do not seem to be considering this...  But if
timestamp option is used, the receiver of the RST can check the
timetstamp echo value and verify that the RST is indeed triggered
by its own TCP segment.

> tearing down old connections.

I assume that you were only suggesting this as a TCP socket
option which an app could set to tell the stack to ignore RST.
IMHO, this is really not acceptable as a general mechanism in
TCP.

-- 

						K. Poon.
						[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Apr 2004 16:53:27 -0700

> SCTP which seems to be fairly robust against those attacks.

The routers in question are more likely (IMO) to support IPsec already 
than to already have SCTP. Besides, as I noted, this is an IPsec issue - 
you want to trust who you get a RST from. There are other good reasons 
to want IPsec here, since there are other similar attacks that you might 
want to protect.

I.e., BGP is infrastructure. Secure it. (IMO)

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Sat, 24 Apr 2004 01:01:37 +0100 (BST)

> the initial sequence number was?

If you've rebooted, it's much more likely that the RST you send will
be next-in-sequence, given decreased window sizes while the other open
end hangs around waiting for you to reboot.

The RST ACK mechanism in intended for in-window-but-not-next-
expected-seq-no RST packets (ahem, TCP segments):

| I expect the case that the valid packet received containing the RST
| flag is _not_ the packet the receiver was expecting with the next
| expected sequence number to be quite common, with packet reordering
| in the Internet, loss (and don't users often kill slow browser
| connections?), and whatnot.

L.

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 26 Apr 2004 07:44:23 -0400

Joe Touch wrote:

> than to already have SCTP. Besides, as I noted, this is an IPsec issue 
> - you want to trust who you get a RST from. There are other good 
> reasons to want IPsec here, since there are other similar attacks that 
> you might want to protect. 

Cisco routers already support SCTP... I believe it would be almost
a no-op for a Juniper router to pick up the KAME-SCTP code for
there routers... not sure about the rest of the router vendors out there..

And I am sure that most router vendors are considering or have considered
SCTP for BGP... but like anything there would always be a transition
time when moving to a "new" solution.. this can be a bit hap-hazard to
deal with so if such a thing were to occur it would not be anytime soon :-o

R

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 26 Apr 2004 08:01:01 -0400

Tim:

Good point on the ISN issue... (i.e. how do I remember it when
I reboot)...

Your idea of ignoring RST's might work.. but what about
SYN's .. do you still want to do as the draft recommends?
If so, the ACK would illicit a RST... which you would then
ignore....

Hmm..

R

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Apr 2004 10:32:29 -0700

> deal with so if such a thing were to occur it would not be anytime soon :-o

Any transition - use of IPsec, a new TCP, porting SCTP - involves a 
transition. I am frankly surprised that the router vendors are so eager 
right now to consider a mod to TCP to fix this, given our collective 
experience with the complexity of TCP mods.

Joe