Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt

[Don Lewis <[e-mail]>]

On 21 Apr, Randall Stewart (cisco) wrote:
> Hi all:
> 
> Don Lewis from FreeBSD has raised this point
> to me privately.. and I thought it worth sharing...
> "
> 
> From what I see here: 
> 	<http://docs.freebsd.org/cgi/getmsg.cgi?fetch=71731+0+archive/1999/freebsd-net/19991128.freebsd-net>
> I am concerned that step C will not solve the compatibility problem. The
> FreeBSD host is sending a FIN to close an established connection, and
> the peer host adding the window size advertised in the FIN packet to the
> sequence number acknowledged in the FIN packet, and using the sum as the
> sequence number for the RST packet, which puts the sequence number at
> the end of the receive window.
> 
> "
> 
> Don:
> 
> I am still a bit fuzzy on this scenario... could you do something like:
> 
> E-A                                                             E-Z
> --------------FIN(ack=X)---------------------------------->
> <----------------------------RST(ack=Y)-----------------
> 
> and spell this out for me.

It turns out that the problem mentioned in the FreeBSD archives is a
rather special case.  The traffic captured in the tcpdump trace is
between a web server and a load balancing device that sits between the
web server and its clients.

At the end of the server's response to the client, the server sends a
FIN packet to close down the connection.  The load balancer is detecting
the FIN packet, and immediately sending a RST response to the web server
to cause the web server to immediately tear down the connection state in
order to free up resources on the web server as quickly as possible,
without having the web server wait for an ACK from the possibly quite
distant client.  The quirk is that the RST packet constructed by the
load balancer does not use as its sequence number the last acknowledged
sequence number that it extracted from the FIN packet.  Instead it
appears to add the window size (less one?) advertised by the FIN packet
to the last acknowledged sequence number in the FIN packet to get the
value of the sequence number in the RST packet.

I would assume that the load balancing device is forwarding the FIN
packet to the client, and that it is handling any necessary
retransmissions.

I suspect that step C in the solution to the RST vulnerability mentioned
in draft-ietf-tcpm-tcpsecure-00 would not help in this case, since the
load balancing device appears to totally ignore retransmissions of the
FIN packet by the web server if the web server drops the initial RST
packet because of strict sequence number checking.


The fix currently proposed for the the FreeBSD stack is to enforce the
exact sequence match check (step B in draft-ietf-tcpm-tcpsecure-00) for
ESTABLISHED connections, but use the more permissive RFC 793 check for
connections in other states.


_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm