netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Pankratov <ap@swapped.cc>
To: "David S. Miller" <davem@redhat.com>
Cc: netdev@oss.sgi.com, Michael Rozhavsky <mike@minantech.com>
Subject: RST business
Date: Wed, 21 Apr 2004 22:59:11 -0700	[thread overview]
Message-ID: <40875F2F.7010204@swapped.cc> (raw)


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

             reply	other threads:[~2004-04-22  5:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-22  5:59 Alex Pankratov [this message]
2004-04-22  7:08 ` RST business Glen Turner
2004-04-22 14:11 ` Steve Modica
2004-04-22 15:17   ` Alex Pankratov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40875F2F.7010204@swapped.cc \
    --to=ap@swapped.cc \
    --cc=davem@redhat.com \
    --cc=mike@minantech.com \
    --cc=netdev@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).