[e2e] RFI: Microsoft accused of TCP standards violation

[Ramesh Shankar]

Perhaps I am not too familiar with the dump formats, but how is this 
supposed to show the establishment of an HTTP session without going 
through a 3-way handshake? I am assuming "S" stands for SYN, "P" for 
push and "F" for FIN. As I see it we have a case of a browser expecting 
a persistent connection HTTP-server while the server is non-persistent 
or alternately, persistent, but kicking off the client anyway.

The client side's TCP ACKs the FIN (which is done by the TCP stack, 
nothing to do with the browser client) and the client doesn't know that 
the server is not willing to receive anything more on the HTTP session 
and so gets a reset from the server's TCP stack (as the server side has 
presumably done a full close) when it sends data. Hence, the client 
establishes another connection which can be clearly seen by the SYN and 
the new client side port number (34154 instead of 34154).

Apart from all these, I don't understand how one could do guess work and 
establish a TCP session when data are received without any 3-way 
handshake. NATs would drop on the floor such packets, for example! What 
would be the sender's ACK #? What about the TCP options setup during SYN?

I would suspect that someone may have seen the trace on a an already 
established persistent, but idle connection and speculated that TCP 
3-way handshake is being bypassed.

If someone were that desperate, I would expect them to send the GET 
along with the SYN and the server side to send the data along with FIN 
in the SYN-ACK for non-persistent connections!

Thanks,

S.R.

Jianping Pan wrote:

>It is interesting that we observed the similar behavior
>for Netscape Browsers with an Apache Web server. See the
>attached tcpdump and httpd.log for reference. It was
>done a bit long ago and I do not have their software 
>version numbers handy now. Might be able to dig more.
>
>Initially we thought it might be a bug in Netscape. Now
>seems that it was *designed* to compete Microsoft's IE 
>with Microsoft's IIS.
>
>
>Best regards,
>
>Jianping
>
>---
>
>16:29:53 c.34153 > s.80: S 0:0(0) win 8760 <mss 1460> (DF)
>16:29:53 s.80 > c.34153: S 0:0(0) ack 1 win 5840 <mss 1460> (DF)
>16:29:53 c.34153 > s.80: . 1:1(0) ack 1 win 8760 (DF)
>16:29:53 c.34153 > s.80: P 1:276(275) ack 1 win 8760 (DF)
>16:29:53 s.80 > c.34153: . 1:1(0) ack 276 win 6432 (DF)
>16:29:53 s.80 > c.34153: . 1:1461(1460) ack 276 win 6432 (DF)
>16:29:53 s.80 > c.34153: P 1461:2553(1092) ack 276 win 6432 (DF)
>16:29:53 c.34153 > s.80: . 276:276(0) ack 1461 win 8760 (DF)
>16:29:53 c.34153 > s.80: . 276:276(0) ack 2553 win 8760 (DF)
>16:30:10 s.80 > c.34153: F 2553:2553(0) ack 276 win 6432 (DF)
>16:30:10 c.34153 > s.80: . 276:276(0) ack 2554 win 8760 (DF)
>
>c [16:29:53] "GET / HTTP/1.0" 200 2180 "-" 
>"Mozilla/4.5 [en] (X11; U; SunOS 5.6 sun4u)"
>
>16:33:42 c.34153 > s.80: P 276:632(356) ack 2554 win 8760 (DF)
>16:33:42 s.80 > c.34153: R 2554:2554(0) win 0 (DF)
>
>16:33:42 c.34154 > s.80: S 0:0(0) win 8760 <mss 1460> (DF)
>16:33:42 s.80 > c.34154: S 0:0(0) ack 1 win 5840 <mss 1460> (DF)
>16:33:42 c.34154 > s.80: . 1:1(0) ack 1 win 8760 (DF)
>16:33:42 c.34154 > s.80: P 1:357(356) ack 1 win 8760 (DF)
>16:33:42 s.80 > c.34154: . 1:1(0) ack 357 win 6432 (DF)
>16:33:42 s.80 > c.34154: P 1:268(267) ack 357 win 6432 (DF)
>16:33:42 c.34154 > s.80: . 357:357(0) ack 268 win 8760 (DF)
>16:33:59 s.80 > c.34154: F 268:268(0) ack 357 win 6432 (DF)
>16:33:59 c.34154 > s.80: . 357:357(0) ack 269 win 8760 (DF)
>
>c [16:33:42] "GET / HTTP/1.0" 304 - "-" 
>"Mozilla/4.5 [en] (X11; U; SunOS 5.6 sun4u)"
>
>  
>

-- 
-------------------------------------------------------------------------------
NOTICE: This email message is for the sole use of the intended recipient(s) and
	may contain confidential and privileged information meant for the sole
	use of the recipient(s) specified in the e-mail. Any unauthorized 
	review,	use, disclosure or distribution (including but not 
	limited to: forwarding, replying to, or including recipients not
	included in the original e-mail) without the sender's prior 
	approval is STRICTLY prohibited. If you are not the intended 
	recipient, please contact the sender by reply email and destroy 
	all copies of the original message.
--------------------------------------------------------------------------------