kern/75873: Usability problem with non-RFC-compliant IP spoof protection implementation

[Jonas Nagel]

>Number:         75873
>Category:       kern
>Synopsis:       Usability problem with non-RFC-compliant IP spoof protection implementation
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Thu Jan 06 08:40:26 GMT 2005
>Closed-Date:
>Last-Modified:
>Originator:     Jonas Nagel
>Release:        4.10-RELEASE-p4
>Organization:
-
>Environment:
>Description:
"Some servers are protected by a mechanism whereby upon receiving a SYN 
packet from an unknown source, attempt to validate the source IP by 
generating an invalid ACK packet in response. The server then expects to
receive a RST back from the Client, for the invalid ACK, and this then 
validates the source IP of the Client. At this point the Server knows 
the Client's IP is not spoofed, and will add the Client's IP to a list 
of valid IPs.

The problem is that the PIX passes this invalid ACK packet to the 
Client, and the client correctly responds with a RST. However, the PIX 
will not pass this RST packet because the Sequence number in the RST 
does not match the Next Expected Sequence number. Therefore, the PIX 
responds to the RST packet with an ACK, and the Ack number is set equal 
to the Next Expected Sequence number. The PIX then expects the client to
Reset this ACK with the valid sequence number, but the client is not 
obligated to do so."

CISCO PIX and FreeBSD seem to have that problem with such 
implementation. While above description is copied from a CISCO Firewall 
Engineer response, the latest PIX microcode engineering releases 
incorporates a fix that works around this.

Maybe this is also an IPFilter Problem (I am using ipf/ipnat on my firewall).
>How-To-Repeat:
Try to connect to https://citrix.lehmannholding.ch - at least with FreeBSD 4.x as Firewall the (listening) port appears to be 'filtered', also the other ports which are listening (or being forwarded rather) on this peer appear this way. While all other ports which are not listening return RST and therefore appear 'unfiltered' (in fact they are blocked on the firewall).

Btw. this host is running a Symantec Raptor Firewall.
>Fix:
It would require a full analysis of the broken packet being sent. But 
hacking IPFILTER or even the FreeBSD TCP Stack is out of my scope.
>Release-Note:
>Audit-Trail:
>Unformatted: