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

From: Tim Shepard <[email-masked]>
Date: Tue, 20 Apr 2004 22:34:49 -0400

I just gave draft-ietf-tcpm-tcpsecure-00.txt a quick read.

It seems to me this is not something we need to be worried about.  An
attacker not only needs to manage to have a sequence number land
inside a range of TCP sequence number space, the attacker needs to
know the two 16-bit port numbers of the TCP connection involved, and
the two 32-bit IPv4 addresses, i.e. the attacker needs to somehow be
aware of the existance of the TCP connection.

If the attacker cannot see the traffic (spy on the net somewhere
between the two endpoints of the TCP connection), then most all TCP
connections will not be vulnerable simply because they are hiding in a
very large space.  

If there are well-known long-lived TCP connections (where both IP
addresses and one (or both) of the port numbers are well known) then
maybe there is a problem, and perhaps the draft should explain that
situation explicitly.  If both port numbers are predictable, then
perhaps implementations should pick a (good) random port number to
come from, adding a 2^16 factor to the size of the search space for an
attacker.

If the attacker is spying on the net and seeing the packets go by,
then the "solutions" proposed in this draft will not be of any help.
Solution: Either protect the links and routers along the path to make
spying more difficult, or deploy end-to-end encryption using some sort
of tunnel (e.g. tunnel mode IPsec ESP) or transport mode IPsec ESP.

			-Tim Shepard
			 [email-masked]

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

---

From: Allison Mankin <[email-masked]>
Date: Tue, 20 Apr 2004 20:08:44 -0700

Hi, Tim,

I agree the draft should mention the point about ports and addresses.

Below is an interesting mail from nanog showing how addresses and
ports can be found.  Another nanog message mentioned that some router
vendors limit the TCP port range.  There is also some nanog chat about
seeing scanners.

Allison

-----

Subject: tcp bgp vulnerability looking glass and route server issues.
Date: Tue, 20 Apr 2004 14:38:18 -0600
From: "Smith, Donald" <[email-masked]>
To: <[email-masked]>

John Fraizer author of MRLG one of the looking glass implementations
has updated his code to fix a flaw that provided too much information.

MRLG-4.3.0 is available at:
Available here:
ftp://ftp.enterzone.net/looking-glass/CURRENT/

Some route servers also provide too much info.
This audit was performed yesterday so if you have already fixed this 
issue please ignore:-)
Part of this issue is the fact that some router servers provide too much 
information.
Without knowing the source/destination ports and IP's this is still a 
difficult vulnerability to exploit.

>From this URL I did a quick audit.
http://www.traceroute.org/#Route%20Servers
I did NOT look at the looking glass URLs just the route servers.

This is the list of open route servers I did a quick audit on.
No connection means I was unable to connect to it.
Not misconfigured meant sho ip bgp nei did NOT work.
Sho ip bgp nei gives full ports/ips means what you think it means.
You have may want to see if any of them are yours of20
if you peer / are the upstream for any of them.

"Route Servers"

"telnet://ner-routes.bbnplanet.net" BBN Planet NER route monitor20
No connection

"telnet://route-server.belwue.de" BelWue (AS553)
Sho ip bgp nei gives full ports/ips.

"telnet://route-views.on.bb.telus.com">Telus - East Coast (AS852)
Sho ip bgp nei gives full ports/ips.

telnet://route-views.ab.bb.telus.com" Telus - West Coast (AS852)
Sho ip bgp nei gives full ports/ips.

"telnet://route-server.cerf.net">CerfNet Route Server (AS1838)</A></LI>
Sho ip bgp nei gives full ports/ips.

"telnet://route-server.ip.tiscali.net">Tiscali (AS3257)</A></LI>
Sho ip bgp nei gives full ports/ips.

"telnet://route-server.gblx.net">Global Crossing (AS3549)</A></LI>
Not misconfigured:-)

"telnet://route-server.savvis.net/">SAVVIS Communications 
(AS3561)</A></LI>
Sho ip bgp nei gives full ports/ips.

"telnet://public-route-server.is.co.za" TARGET3DNEW>Internet Solutions 
(AS3741)</A></LI>
Sho ip bgp nei gives full ports/ips.

"telnet://route-server-ap.exodus.net">Exodus Communications Asia 
(AS4197)</A></LI>
No connection

"telnet://route-server.as5388.net">Planet Online (AS5388)</A></LI>
Sho ip bgp nei gives full ports/ips.

"telnet://route-server.opentransit.net">Opentransit (AS5511)</A></LI>
Not misconfigured:-)

"telnet://tpr-route-server.saix.net">South African Internet eXchange 
SAIX (AS5713)</A></LI>
Not misconfigure:-)

"telnet://route-server.gt.ca">GT Group Telecom (AS6539)</A></LI>
Sho ip bgp nei gives full ports/ips.

"telnet://route-server.as6667.net">EUNet Finland (AS6667)</A></LI>
Sho ip bgp nei gives full ports/ips.

"telnet://route-server.he.net">Hurricane Electric (AS6939)</A></LI>
Sho ip bgp nei gives full ports/ips.

"telnet://route-server.ip.att.net">AT&T (AS7018)</A></LI>
No connection

"telnet://route-views.optus.net.au">Optus Route Server Australia 
(AS7474)</A></LI>
Sho ip bgp nei gives full ports/ips.

"telnet://route-server.wcg.net">Wiltel (AS7911)</A></LI>
Sho ip bgp nei gives full ports/ips.

"telnet://route-server.colt.net">Colt Internet (AS8220)</A></LI>
Sho ip bgp nei gives full ports/ips.

"telnet://route-server-eu.exodus.net">Exodus Communications Europe 
(AS8709)</A></LI>
No connection

"telnet://route-views.bmcag.net">Broadnet mediascape communications AG 
(AS9132)</A></LI>
Not misconfigured:-)

"telnet://route-server-au.exodus.net">Exodus Communications Australia 
(AS9328)</A></LI>
No connection

"telnet://route-server.manilaix.net.ph">Manila Internet Exchange, 
Philippines (AS9670)</A></LI>
Sho ip bgp nei gives full ports/ips.

"telnet://route-server.east.attcanada.com">ATT Canada - East 
(AS15290)</A></LI>
Sho ip bgp nei gives full ports/ips.

"telnet://route-server.west.attcanada.com">ATT Canada - West 
(AS15290)</A></LI>
Sho ip bgp nei gives full ports/ips.

"telnet://route-server.ip.ndsoftware.net">NDSoftware (AS25358)</A></LI>
Sho ip bgp nei gives full ports/ips.

"telnet://route-server.loudpacket.net">Loud Packet (AS27276)</A></LI>
No connection.

"telnet://route-server.as28747.net/">RealROOT (AS28747)</A></LI>
No connection

"telnet://route-views.oregon-ix.net">Oregon-ix.net Route Server</A></LI>
Sho ip bgp nei appears it WOULD provide full ports/ips if they had any? 
The command executed but came back empty!!?? This one  can be used as a 
proxy bounce (connect ip port) too:-(

"telnet://route-server.utah.rep.net">Utah Regional Exchange Point Route 
Server</A></LI>
Sho ip bgp nei gives full ports/ips.

"telnet://www.netlantis.org">The NetLantis Project Route Server</A></LI>
Not misconfigured.

http://pgp.mit.edu:11371/pks/lookup?op3Dget&search3D0xAF00EDCC
pgpFingerPrint:9CE4 227B B9B3 601F B500  D076 43F1 0767 AF00 EDCC
Increased trust is received by not violating the trust you have 
received.

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Wed, 21 Apr 2004 11:46:08 -0500

Hi all:

Don Lewis from FreeBSD has raised this point
to me privately.. and I thought it worth sharing...
"

From what I see here: 
	<http://docs.freebsd.org/cgi/getmsg.cgi?fetch=71731+0+archive/1999/freebsd-net/19991128.freebsd-net>
I am concerned that step C will not solve the compatibility problem. The
FreeBSD host is sending a FIN to close an established connection, and
the peer host adding the window size advertised in the FIN packet to the
sequence number acknowledged in the FIN packet, and using the sum as the
sequence number for the RST packet, which puts the sequence number at
the end of the receive window.

"

Don:

I am still a bit fuzzy on this scenario... could you do something like:

E-A                                                             E-Z
--------------FIN(ack=X)---------------------------------->
<----------------------------RST(ack=Y)-----------------

and spell this out for me.

Thanks

Rb

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

---

From: Florian Weimer <[email-masked]>
Date: Fri, 23 Apr 2004 00:12:51 +0200

> I agree the draft should mention the point about ports and addresses.

Vendors seem to disagree and hesitate to add source port
randomization.  I don't know why. 8-(

-- 
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: Joe Touch <[email-masked]>
Date: Thu, 22 Apr 2004 16:12:51 -0700

A few somewhat separate points:

1) I agree with a few others that this is not a
    substantially worrisome problem.

	The draft would be made much better by, e.g.,
	pointing out early and directly that

	a) this problem was known before (RFC2385)

	b) the primary change is the increase in the
	   window, which increases the chance of it
	   working as an attack

	The current draft (IMO) obfuscates its relation
	to 2385, noting it only as an informative ref
	(if this isn't normative, though not a protocol,
	I'm not sure what is), and as a way to close
	the attack "incompletely" (FWIW, the RST trick
	is incomplete too).

2) The sky isn't falling

	This is critical ONLY for:

		- pairs of machines that OTHERS not
		in the path know are communicating

		- that others care to interrupt

	IMO, IPsec or the MD5 signature options are
	more than sufficient for these cases.

	Sure, there's an esoteric interest we share
	in exploring the space of "can we do better
	without slowing down the connection and without
	predeploying keys of some sort", but it's
	not clear it's worth #3

	- it IS worth noting that, e.g., as others have
	pointed out:
		--a) data-level security won't help (TLS)
		--b) transport or network security will
		     (MD5 signatures, IPsec)
		--c) cookies are as good as signatures
		     for this purpose
		--d) transport security, whether cookies
		     or signatures, requires a TCP option,
		     which could break non-modified receivers
		     (i.e., aren't as backward-compat as this
		     might be)

		     but since you have to modify the ones you're
		     trying to protect anyway, so consider it
		     as a 'dual stack' issue and move on ;-)

3) mucking with RSTs can be hazardous

	RST handling is rife with dragons. At the least,
	these include:
	
		--a) when you throw a RST, IMO, _YOU_ ought
		to have to go into TIME_WAIT

		if not, you can't ensure that the other end
		won't restart the connection and data will
		leak in and corrupt...either when the other
		side does - or more importantly does not -
		implement this solution

		if you're in TIME_WAIT, you shouldn't reply
		to ACKs with anything but silence (pg 72)

		the alternative is to add a new state -
		TIME_WAIT_RST, which replies to ACKs differently
		than TIME_WAIT (which is entered on other events)

		--b) what about when there's lossy pipes?

	  	You send a RST with the last SEQ number
		(after all the data you already sent). But the lost
		data means the other side ACKs a lower (modulo
		wraparound) SEQ. So you send a RST with that SEQ.

		In the meantime, some of the pipelined data arrives,
		increasing the SEQ no. So the new RST shows up. It
		get's dropped, and an extra ACK of the new SEQ goes
		back to you.

		--- The ID isn't clear that the ACK sent is
			i) just an ACK
			in which case this pattern can repeat
			until all the data is sent, which could
			be a LONG TIME

			ii) a RST-ACK
			which, since RST bits are processed before
			ACK bits, will cause you to reset, somewhat
			unexpectedly ;-)

	For these reasons and a few lurking suspicions, I'm hesitant to
	change the processing diagram to add new states OR new arcs;
	this appears to need BOTH.

Joe

---

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

> randomization.  I don't know why. 8-(

Port allocation is an implementation issue and the current issue
we have at hand is a flaw  in the original standard. Its
the later that we are trying to address. yes, port randomization
will help, but the amount of benefit we can derive is debatable.

thx
Mitesh

---

From: Florian Weimer <[email-masked]>
Date: Fri, 23 Apr 2004 08:30:34 +0200

Mitesh Dalal <[email-masked]> writes:

> we have at hand is a flaw  in the original standard.

Why do you think this is a flaw in TCP?  Which specification is
violated?

---

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

Joe Touch wrote:

Joe: A few comments inline

>     the attack "incompletely" (FWIW, the RST trick

We were going to actually have different wording but
could not get it in due to email crossing between Allison and
myself... what should have been in the intro section of the
document is:

"
   For some uses of TCP, an alternative protection against the threats
   that these changes address has already been implemented and deployed
   in the TCP MD5 Signature Option (RFC2385 [2]). Because this option is
   not negotiated  and is implemented with a manually established shared
   key or password, it has been used for protecting uses of TCP in which
   the endpoints are managed, such as for BGP peers.  RFC3562 [2]
   provides importance guidance for users of RFC2385 [2] for decreasing
   their vulnerability to key-guessing.

"

The next pass will have Allison's wording in it :-D

> 2) The sky isn't falling

I don't think we meant to say that in the draft :-D

>     more than sufficient for these cases. 

Yep.. but for some reason deployment of these have not
happened... I will note that I have heard more ISP's are now
interested in MD5 now.. which is a "good thing" :-D

>              as a 'dual stack' issue and move on ;-) 

So are you recommending cookies (or what I would call V-tags).... instead
of the current draft proposals... If this is what the working group
wants I would be happy to work with the co-authors to redo the
document has such...

>             until all the data is sent, which could

Yep.. thats the plan.. a plain ole ACK.. and yep.. until
all the data gets across you would have this issue...

>             ACK bits, will cause you to reset, somewhat

Nope.. not this one.. we will need to add wording to emphasis
its a plain ole ACK...

>     this appears to need BOTH. 

What would you recommed then?  Not do anything? or something else?>

R

---

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

Allison:

How about if we add something like:
"
TCP implementations MAY also introduce ephemeral port randomization. By
randomizing ephemeral ports an attacker would have a less easy time
in guessing the four tuples needed to mount a successful attack.
"

To the introduction section has an addtion?

R

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Apr 2004 08:54:15 -0700

> Joe Touch wrote:
...
> interested in MD5 now.. which is a "good thing" :-D

Actually, I would be more pleased if the ISPs used IPsec.

...
> wants I would be happy to work with the co-authors to redo the

The current draft ought to (IMO) be more complete in this regard. IF the 
draft is really about RST Assasination (which is what it, IMO, ought to 
be), then it ought to discuss and compare all viable solutions.

The doc appears, however, to be more like "given RST Assasinations, 
here's a TCP mod". Since there are extant protocols that already solve 
this for the most important cases. Do physicists with huge windows 
really advertise the two machines that are transferring? do hackers care 
to kill their connections? - likely not, i.e., this is primarily a BGP 
and IRC issue, for which IPsec is a better, more secure solution.

> What would you recommed then?  Not do anything? or something else?>

1) use IPsec if you want to avoid this

	the attacker might find other holes - in TCP, or basically
	any other protocol

	these protocols (transport and above) are being attacked by
	a third party. they are NOT secure or safe - they were never
	intended to be (from attackers)

	the attack is completely avoided by IPsec, since the attack
	only works because someone is FAKING IP PACKETS

	so, IMO, solve the __problem__ - faked IP packets -
	at the source, not somewhere up the stack

	FWIW, if IPsec is too slow - if you want a cookie checker
	to stall an attacker but not slow down IP - then propose
	it (or I might ;-) -- at the IP layer, where it helps
	all protocols, not just IP

2) fix TCP to do the right thing for RST throwers

	as I mentioned, throwing a RST and jumping into CLOSE
	works for this solution, ___BUT___ is NOT what should
	be done

	i.e., this fixes TCP to solve an IP-level security hole,
	at the expense of relying on a broken TCP behavior
	(it should jump into TW on sending RST) that ought to
	be fixed; if we do this, we'll have trouble fixing the
	'RSTer jumps into TW', which we should have done a while
	back, IMO

Joe

---

From: Mitesh Dalal <[email-masked]>
Date: Fri, 23 Apr 2004 09:06:52 -0700 (PDT)

> Why do you think this is a flaw in TCP?  Which specification is

in my opinion, the rst/syn processing recommended in the base spec
for an ESTAB connection is rather agressive in todays world.

thx
Mitesh

---

From: Anantha Ramaiah <[email-masked]>
Date: Fri, 23 Apr 2004 09:58:12 -0700 (PDT)

Randall:

After watching some email suggestions, it appears that we could add :

- Port randomization suggestion. [ Any good references, papers should
help]

- A note on MD5 and choosing MD5 secret..

-Anantha

---

From: Mitesh Dalal <[email-masked]>
Date: Fri, 23 Apr 2004 10:55:32 -0700 (PDT)

> 	all protocols, not just IP

Hi Joe,

Can we realy do this ? I mean suggesting using IPSec, using MD5,
using IPv6(since security is mandatory) are all end user choices.
I doubt a WG could really spell this out, expcept maybe an
informational draft or BCP.

> 	'RSTer jumps into TW', which we should have done a while

fixing the standard is a better approach (not that I agree with
your TW suggestion :) since the onus in now on IETF and the vendors
to provide correct solution to end users, who do not have to worry
about config, admin and cost issues of deploying yet another technology
to mitigate an attack in another protocol.

thx
Mitesh

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Apr 2004 11:40:49 -0700

> informational draft or BCP.

IMO, we can surely do this. The IESG took the task to us to address; 
addressing it is clearly within scope. Certainly the result would be a 
BCP at best, since it would not indicate a new protocol.

> to mitigate an attack in another protocol.

I don't agree; fixing TCP to deal with the fact that you can't trust the 
source of a RST is a bit of a layerer 'violation' (fixing the wrong layer).

Joe

---

From: Florian Weimer <[email-masked]>
Date: Mon, 26 Apr 2004 10:18:14 +0200

> wants I would be happy to work with the co-authors to redo the

Cookies/V-tags have the advantage that we can hope that we have to
deploy a fix just *once*.  If you tweak the TCP state machine to work
around the two problems identified so far, this won't help against
feature issues that might be discovered.

Given the costs of a fix like this one, I'd rather prefer to be on the
safe side.

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

---

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

>Given the costs of a fix like this one, I'd rather prefer to be on the
Florian:

I have always liked the V-tag mechanism .. but that is not
surprising seeing my involvement with SCTP :-D ..

If the WG feels this is a better way to go, then thats fine.. However
it will require a larger fix then just the few minor tweaks the current
draft proposes..

R

---

From: Don Lewis <[email-masked]>
Date: Sat, 24 Apr 2004 02:40:33 -0700 (PDT)

> and spell this out for me.

It turns out that the problem mentioned in the FreeBSD archives is a
rather special case.  The traffic captured in the tcpdump trace is
between a web server and a load balancing device that sits between the
web server and its clients.

At the end of the server's response to the client, the server sends a
FIN packet to close down the connection.  The load balancer is detecting
the FIN packet, and immediately sending a RST response to the web server
to cause the web server to immediately tear down the connection state in
order to free up resources on the web server as quickly as possible,
without having the web server wait for an ACK from the possibly quite
distant client.  The quirk is that the RST packet constructed by the
load balancer does not use as its sequence number the last acknowledged
sequence number that it extracted from the FIN packet.  Instead it
appears to add the window size (less one?) advertised by the FIN packet
to the last acknowledged sequence number in the FIN packet to get the
value of the sequence number in the RST packet.

I would assume that the load balancing device is forwarding the FIN
packet to the client, and that it is handling any necessary
retransmissions.

I suspect that step C in the solution to the RST vulnerability mentioned
in draft-ietf-tcpm-tcpsecure-00 would not help in this case, since the
load balancing device appears to totally ignore retransmissions of the
FIN packet by the web server if the web server drops the initial RST
packet because of strict sequence number checking.

The fix currently proposed for the the FreeBSD stack is to enforce the
exact sequence match check (step B in draft-ietf-tcpm-tcpsecure-00) for
ESTABLISHED connections, but use the more permissive RFC 793 check for
connections in other states.

---

From: Mitesh Dalal <[email-masked]>
Date: Mon, 26 Apr 2004 14:59:08 -0700 (PDT)

> value of the sequence number in the RST packet.

IMHO, this is rather unusual. I am not sure why the load balancer
decides to compute the sequence number in such a special way. Since
this is actually a deviation from the base spec, I am not sure how
much consideration we need to give to this scenario.

> in draft-ietf-tcpm-tcpsecure-00 would not help in this case, since the

since we have a load balancer in picture, I hypothesize that most
connections will be short lived and hence do not need to worry about
the current solution. But if we do decide to go down this road and
the servers in question do want the fix, maybe the load balancers
could also be expected to upgrade to this scenario ?

> packet because of strict sequence number checking.

this does not sound right. Without our changes, what if the first RST from
the load balancer to the server is lost in the network ? How does the
server recover ?

> connections in other states.

although when we wrote the draft the main intention was to protect
connections in the ESTAB state. However, since the base spec interprets
synchronized state to mean anything greater than ESTAB, we think that
this should easily apply to other states too. Baring the above,
are there any end-to-end scenarios that we might have overlooked ?

Thanks
Mitesh

---

From: Anantha Ramaiah <[email-masked]>
Date: Mon, 26 Apr 2004 15:36:50 -0700

Just wanted throw in my few cents:
In the load balancer case, like Mitesh pointed out the 
- RST could get lost.
- in case the RST makes it, the server ( with the fix) should send an
ACK back to solicit the "acceptable RST". the load balancer should not drop
the
ACK, since by originally sending RST it means that it has *released* the
control 
block resources and should act according to the RFC by sending RST for future
packets targetted towards this control block (TCB or PCB). If this is not
being done, then the host restart cases,dropped RST cases wouldn't work.
Probably it was noticed because the load balancer never ran into such
situation before. 

Also regarding the draft...

- We wanted carefully choose the wording for the current draft to reflect the 
base spec. This is the reason we wanted to keep with the > ESTAB terminology.
I don't think there should be any corner cases which we could have missed. 

I do agree that the main cause of concern is tearing down the connection 
in ESTAB state. For other states we could have choosen to do the older way 
but it is always better to to maintain the same semantics to avoid adding 
more arcs to the state diagram.

-Anantha

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 26 Apr 2004 18:08:54 -0700

> much consideration we need to give to this scenario.

I think most host TCP implementors will say that the above is not
unusual at all.  A host TCP stack talks to so many different kinds
of devices that nearly everything can be wrong will probably go wrong.
 From a router TCP stack's point of view, the changes suggested in the
draft may be acceptable.  But I think most host TCP implementors
will hesitate to implement that.

-- 

						K. Poon.
						[email-masked]

---

From: "Paul Goyette" <[email-masked]>
Date: Mon, 26 Apr 2004 18:58:36 -0700

> ...  But I think most host TCP implementors

Frankly, I'd be surprised if host TCP implementors made any changes
whatsoever.  That's why I like the proposed changes in Randall's
draft.  (Well, that and the fact that I had a small hand in helping
him!)  These changes impose no requirements at all on changes being
made on the TCP peer unless the peer wants to be protected from the
RST or SYN attack, or data injection.  And that's probably not very
likely, since most host TCPs won't engage in long-lived sessions
that are painful to restart.

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 26 Apr 2004 19:14:40 -0700

> that are painful to restart.

You expect the vast majority of TCP stacks out there will not
care about this change and yet this change is proposed in tcpm
as a "fix" to TCP?  I'd suggest this draft to be removed as a WG
doc.

-- 

						K. Poon.
						[email-masked]

---

From: Mitesh Dalal <[email-masked]>
Date: Mon, 26 Apr 2004 20:46:48 -0700 (PDT)

> as a "fix" to TCP?  I'd suggest this draft to be removed as a WG

if we decide to make the solution a standard, it does
not necessarily mean that all tcp stack vendors out their have to
run out and fix their stack. It IMHO, means that the engineering
community and the IETF have made due diligence in studying the
solution and that there is general consensus that yes, this is
a vulnerability and yes we agree that this is likely the best
solution given all considerations.

If you are believe that you have a solution this is easier
to implement, backward compatible, appears to be minimally
disruptive, I am sure we would all like to hear it and review
it.

FWIW, I do consider your timestamp option as a valid proposition,
but the very fact that you are banking on an "optional" option
to fix this problem is speculative, because in this solution
not only does the client need to upgrade but also the middlebox
in order for them to not drop your RST and if your answer to this
is that since its an option and it can be turned off later if
we find issues then, its like saying that here is a solution that
I think will work, but I am not confident enough and if you happen
to find a problem, please turn it off and let the vulnerability
open again.

So please put forward scenarios to the WG to ponder that you
think may not work. If you are successful in doing so, we would
be more than glad to take back our proposal.

thanks
Mitesh

---

From: Mitesh Dalal <[email-masked]>
Date: Mon, 26 Apr 2004 20:22:02 -0700 (PDT)

> will hesitate to implement that.

I went and looked at the freebsd thread that Don pointed in his earlier
email. I do not see any reference to load balancers(Don, I hope I am
looking at the right place, or is this that you personally tested ?)
But a subsequent reply (by venkat) to that question points to a valid
scenario where its possible to receive a RST with a sequence number which
is much beyond the rcvnxt. Here again since the RST is resulting from
the endhost but not from an intermediate system, our solution will
still hold.

thanks
Mitesh

---

From: Anantha Ramaiah <[email-masked]>
Date: Mon, 26 Apr 2004 20:52:31 -0700 (PDT)

> as a "fix" to TCP?  I'd suggest this draft to be removed as a WG

Well, I guess the point Paul was trying to make is in terms of various
TCP stacks adapting this solution once it is standardized. The philosophy
is whoever implements this gets the additional security needed for
applications riding over TCP. Suppose you have some RFC written, which
talks about some eficient flow control or congestion control or window
handling. It is not necessary that all stacks out there needs to pick it
up and implement it. Wheover implements gets the benefit others not.
Probably lot of people won't care if telnet is not buying this new
proposal. Because there isn't much harm you will be causing resetting
a telnet connection as opposed BGP or a VOIP control connection.

Well, telling that "since vast majority of stacks out there wont care
about this and remove this as WG doc" is analogous to "since vast majority
of people cannot afford business class in flights", don't provide business
class...
:)

-Anantha

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 27 Apr 2004 19:06:27 -0700

> solution given all considerations.

This is the question.  Is this really the "best" solution
to this issue?  If most, if not all, host TCP implementors
are not comfortable with this "proposed solution" because
it involves a new "challenge/response" behavior and will not
implement it, I guess we cannot say that we have a general
consensus.

I'd like to hear other host TCP implementors' opinion on this.

> disruptive, I am sure we would all like to hear it and review

As I mentioned in a previous mail, a cookie mechanism is better
because it does not require modifying the basic TCP mechanism,
especially no extra TCP segment is generated in response to a RST.
The latter point is my main concern.  Well, if the hosts can use TCP
MD5 option or IPsec, this is not needed...  But if people really like
to have another alternative, I think it is better than having the TCP
stack to respond to a RST.

Let me submit a very short individual draft on this mechanism using
the timetstamp option so that the WG can discuss it.

> to find a problem, please turn it off and let the vulnerability

I think the lesson we learned from ECN applies here.  If ECN cannot
be turned off in Solaris (there are actually 3 options, off, passive
and active), I don't think Sun can ever include it in a production
version, at least not until we are pretty sure that all middleboxes
are fixed.  And Solaris supports ECN since 2002.  I think including
it in a production version actually helps the deployment of ECN.
People can use it now if they want.  Please do not underestimate the
power of turning off something.  It does not necessarily mean that the
mechanism has issues, it is simply a good engineering practice in a
world full of surprises.

Back to the timestamp option.  First, RST with timetstamp option is
actually legal according to RFC 1323.  And in the case when a middlebox
actually drops a RST with timestamp because of a bug, the result is
equivalent to dropping a RST.  There is no RST/ACK war possible.  It
is safe.  The connection stays up and if there is something to
retransmit, the sender will eventually time out.  Safety is very
important.  I think IETF normally recommends conservativeness and
safety.  The fact that the vulnerability increases as the window size
increases and timestamp option should be used in these cases makes
this mechanism more attractive.

> be more than glad to take back our proposal.

As I mentioned, what is the method to handle a possible RST/ACK war?
By limiting the number of ACK generated in response to RST?  By falling
back to the original TCP method?  I think this should be discussed in
the draft.

-- 

						K. Poon.
						[email-masked]

---

From: Mika Liljeberg <[email-masked]>
Date: Wed, 28 Apr 2004 19:13:41 +0300

> I'd like to hear other host TCP implementors' opinion on this.

I work with what you might call smartphones and my gut feeling is that
in this case the cure may potentially be worse than the disease. The
proposed challenge/response mechanism attempts to solve something we
basically see as a non-problem in our environment. On the other hand, we
have plenty of connection-tracking middleboxes of unknown make out there
in mobile operator networks, which makes it the Devil's own breeding
ground for interop trouble. As it is, we're seeing enough of it with the
standard TCP behaviour. So, I'm perfectly happy to sit this one out and
let others sort out the middleboxes.

Regards,

	MikaL

---

From: Mitesh Dalal <[email-masked]>
Date: Thu, 29 Apr 2004 12:18:41 -0700 (PDT)

Hi Kacheong,
Please see inline.

On Tue, 27 Apr 2004, Kacheong Poon wrote:
<snip>

> People can use it now if they want.  Please do not underestimate the

I totally agree with your take above as  I also provide a
cli to turn the feature on/off  when I implemented ECN in IOS.
But ECN is more of a  new feature addition which is
necessarily not benign. As I  see it the proposal that we
have put forward very much uses  the behavior described in
793 to protect its own weakness.
Ted Faber succintly summarized our proposal in one of his
earlier post. I dont think we are adding new state as such.

> mechanism has issues, it is simply a good engineering practice in a

I agree. But the objective should be to accommodate most
valid 793 compliant  scenarios. We may have an offending
middlebox that does not  follow the spec. It would be
difficult to accommodate those and to have a knob to
accommodate those would be detrimental, as we would now
expect the vast majority of tcp users to adapt to them,
rather than have a small bunch of stacks to rectify the
implementation. (again I am assuming here that this problem
will arise cause somebody did something that was a
deviation from the spec, if there are genuine scenarios that
can happen with a correct implementation of the base spec,
I would really like to hear it)

> actually drops a RST with timestamp because of a bug, the result is

rfc 1323 says the following:

"
It is recommended that RST segments NOT carry timestamps, and that
RST segments be acceptable regardless of their timestamp.  Old
duplicate RST segments should be exceedingly unlikely,  and
their cleanup function should take precedence over
timestamps.
"

So I believe many implementors might actually take it like a
MUST kind of thing and not like timestamps in RST. But the
next sentence clouds it implying that its possible  to see
timestamp in RST. So I am not sure what to make of this.
Opinions anybody ?

> As I mentioned, what is the method to handle a possible RST/ACK war?

I would like to put more thought on this. Could you please
elaborate on the RST/ACK war scenario you see happening.

> back to the original TCP method?  I think this should be discussed in

the next pass of the draft will have more  scenarios
explaining its backward compatibility and  capturing all the
questions that have bee raised so far.

Thanks
Mitesh

---

From: Kacheong Poon <[email-masked]>
Date: Fri, 30 Apr 2004 13:00:55 -0700

> earlier post. I dont think we are adding new state as such.

I don't agree that the current proposal uses the "behavior
described in 793" for protection.  Responding to a RST is
not a correct behavior.  It is very clear in RFC 793 what
a RST means.  A stack can ignore the RST (pretend that the
RST is dropped elsewhere (-:), but responding to it is bad.
I think any proposal suggesting a response to a RST is not
acceptable to a host vendor.

> I would really like to hear it)

Note that RFC 793 does not specify how a middlebox should work.
And a middlebox which won't break any current RFC 793 conforming
stack can still have problems with the proposed changes.  For
example, as I mentioned in a previous mail, a middlebox caching
a RST for retransmission is quite acceptable to a RFC 793
conforming stack.  The stack will take the RST.  With the proposed
change in TCP behavior, this will not be the case and may lead to
a RST/ACK war.

I am not advocating that any protocol improvement should stop
because of middlebox.  Unfortunately, middlebox is a fact of
life.  And the proposed change for a problem which already has
more than one solution, TCP MD5 option and IPsec, does not justify
a change in the base TCP protocol behavior.  This is especially
true as the change is not really a protocol improvement, IMHO.

> timestamp in RST. So I am not sure what to make of this.

I expect a normal stack will just ignore the timestamp in the
RST.  I think this is the behavior of most, if not all, host
stacks out there.  So sending a RST with timestamps to those
stacks should cause no harm.  Note that a host stack normally
is quite "liberal" in what it accepts.  Unless there is a clear
MUST, a host stack will take the extra effort to make things
work.  The simple reason is that a host stack needs to talk to
some many different kinds of TCP implementations out there...

As I mentioned in a previous email, a TCP level option can be
used to tell a stack what it needs to do with timestamp option.
I'll get to this in the short draft I said I would submit.  I
hope I can do it during this weekend.

> elaborate on the RST/ACK war scenario you see happening.

The key here is what should happen if the RST is "always" not
acceptable to a modified stack.  A simple solution may be to
keep a counter there for the number of RST it has responded
to with an ACK.  But I don't really think that it is a good
idea to patch up things for the wrong reason: responding to
a RST.

-- 

						K. Poon.
						[email-masked]