netdev
[Top] [All Lists]

Re: RST business

To: Steve Modica <modica@xxxxxxx>
Subject: Re: RST business
From: Alex Pankratov <apankrat@xxxxxxxxx>
Date: Thu, 22 Apr 2004 08:17:45 -0700
Cc: Alex Pankratov <ap@xxxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxx>, netdev@xxxxxxxxxxx, Michael Rozhavsky <mike@xxxxxxxxxxxxx>
In-reply-to: <4087D29E.6010907@xxxxxxx>
References: <40875F2F.7010204@xxxxxxxxxx> <4087D29E.6010907@xxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
Yeah, sure, I understand that. But how realistis is this synchronization loss ? Ie I cannot immediately think of a sequence of events, which would result in two sides both in Established state with de-synchronized recp/send windows.

Steve Modica wrote:

If one of the potential causes for RST is that SEQ/ACK synchronization has been lost, then you can't do this.

Alex Pankratov wrote:


Looking at the hype around 'TCP vulnerability' the following
occured to me, and I wonder if it makes any sense -

A host may recieve legitimate RST packet only in response to
something that it has previously sent (let's call it a 'trigger').

SEQ/ACK values in RST packet are correlated to SEQ/ACK of the
trigger. If the correlation is not there, then RST packet is
most certainly spoofed and should be dropped even if its SEQ
falls into host's rcpt window.

In other words, it seems to be possible to stregthen ingress
RST checking (and thus better protect against blind RST attacks)
while maintaining _full RFC compliance_. Here's a how-to sketch.

    RFC 793 (page 35) states that for the connection in
    non-established state -

    If the incoming segment has an ACK field, the reset takes its
    sequence number from the ACK field of the segment, otherwise
    the reset has sequence number zero and the ACK field is set to
    the sum of the sequence number and segment length of the incoming
    segment.

Hence the second RST check (after standard window check) is

    if (! pkt->seq)
        check if we've recently sent a segment without
        an ACK with (pkt->ack - pkt->seq) bytes in it
    else
        check if we've recently sent a segment with ACK
        of (pkt->seq) and with (pkt->ack - pkt->seq)
        bytes in it

If RST passes the check, it's accepted. Otherwise checks continue.

    RFC 793 (page 36) states that for the connection in
    established state -

    .. elicit only an empty
    acknowledgment segment containing the current send-sequence number
    and an acknowledgment indicating the next sequence number expected
    to be received ..

At this point seeing a RST means that
(a) remote host is an ESTABLISHED state
(b) we sent a segment that it considers not to be a part of the
    current connection

And (b) is something that we can always check since we're now sure
about (a).

The above obviously requires keeping some sort of 'outbound history',
plus (b) involves some non-trivial logic, which however seems to be
doable from the first glance.

Comments ?

Alex




<Prev in Thread] Current Thread [Next in Thread>