RST business

RST business

[Alex Pankratov]

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

Re: RST business

[Glen Turner]

On Thu, 2004-04-22 at 15:29, Alex Pankratov wrote:
> Looking at the hype around 'TCP vulnerability'

We're seeing the results of that hype.  Lots of
peers ringing the NOC to urgently arrange TCP MD5
authentication of their BGP sessions.  It looks
like lots of managers have read the press and
issued directives.

Which is ironic, as we're pretty insistent about
configuring MD5 authentication, and so the peer has
in the past explicitly requested that we not run BGP
authentication.  In the past we've assumed that
those were Linux peers, but apparently they were just
slack.

BGP is particularly vulnerable as they are long-lived
(some sessions here are longer than 400 days, so there can
be lots of attempts) and the interpretation of RST is dramatic
(remove routes learned from that neighbour).

Now if only they would release a Security Advisory
about the risks of unauthenticated OSPF and get the
same level of response :-)


> Comments ?

The essential problem is that RST is the generic
way of recovering from a failure condition in the TCP
state machine.

So trusting that the values in the remainder of
the TCP header are correct is a large leap of
faith (perhaps they got trod on by an errant
pointer, and perhaps the resulting out-of-range
value is why the other end sent us the RST).

If you choose to ignore a RST, and the RST is valid,
then you need to ensure that the TCP connection will
always time out (thus issuing its own RST).

You can expect, but not be assured of, a RST for
each subsequent packet sent on that connection
(and maybe that's a cheap way of checking if the
original RST is valid, hmmm).

Best wishes,
Glen

Re: RST business

[Steve Modica]

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

Re: RST business

[Alex Pankratov]

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
> 
> 
>