Re: How TCP handle (RST,SYN) at initial connection establishment

[Davide <tatonet () tiscali it>]

On Thursday 13 January 2005 13:20, Lim Boon Ping wrote:
> I need some clarification on how TCP reacts to
> incoming (RST, SYN) during 3-way handshaking process.
> In this case, assumptions are made such that
>
>    (1) attacker manages to conquer 1 router in front
> of victim server.
>
>    (2) instead of consuming server / bandwidth
> resources by flooding,the attacker would send (RST,
> SYN) or (RST, ACK) or simply RST upon receiving of any
> SYN request towards victim server.
>
> RFC 793, p36, states the following:
>
> "In all states except SYN-SENT, all reset (RST)
> segments are validated by checking their SEQ-fields
> [sequence numbers]. A reset is valid if its sequence
> number is in the window. In the SYN-SENT state (a RST
> received in response to an initial SYN), the RST is
> acceptable if the ACK field acknowledges the SYN."
>
> My questions are:
>
> 1) According to RFC 793, an established TCP connection
> can be reset by sending suitable TCP packets with the
> (RST, SYN). During the connection establishment stage,
> does the client suffer the same risk?

I don't know if this answer your question... I think (RST, SYN) means no ACK.
The "client", during the three-way handshacking, starts in CLOSED state, 
crosses the SYN-SENT state and then land in ESTABLISHED state (so I assume 
that you're interested only in  SYN-SENT state... the client can reach the 
SYN-RCV state only for simultaneous open, but this is another story).
In the SYN-SENT state:

"  If the state is SYN-SENT then
     first check the ACK bit
        [...]
     second check the RST bit
        If the RST bit is set

          If the ACK was acceptable then signal the user "error:
          connection reset", drop the segment, enter CLOSED state,
          delete TCB, and return.  Otherwise (no ACK) drop the segment
          and return." (rfc793, pp.66-67)

So if the client is in SYN-SENT state and receives a (RST, SYN) packet without 
an ACK it drops the packet and its state doesn't change.
This beacause the SYN flag is analized only at step four:

"     fourth check the SYN bit
        This step should be reached _only_ if the ACK is ok, or there is
        no ACK, and it the segment _did not_ contain a RST." (rfc793, p. 67)

> At SYN-SENT state, what happen if the client receives
> (RST, SYN) spoofed by the attacker with Source
> IP=victim server IP? Assume that in the (RST, SYN)
> packet, the ACK sequence number correctly acknowledges
> the client's SYN, but TCP ACK flag is not set (can it
> be in this way?).

If the ACK bit isn't set the ACK field value isn't checked. As stated before 
client state doesn't change.

> 2) At TCP connection establishment, can (RST, ACK) or
> simply RST flooding toward client side will avoid any
> connection request to the victim server?

You can intercept the client first SYN and send to it a spoofed segment with 
RST on, ACK on, sequence 0 and ack field equal to client seq.+1. The client 
will think that the remote tcp port is closed (no process bound it). This is 
what the REJECT target of iptables does if used with option "--reject-with 
tcp-reset".
If you're using linux you can add an iptables rule like the following:

iptables -I FORWARD -o <output i/f> -p tcp --destination-port <port# of \ 
     service you want to disallow access to> -j REJECT --reject-with tcp-reset

> =====
> Best regards,
> Boon Ping, Lim

Hope this help, sorry for my bad English,
        Davide.