TCP_HAVERCVDFIN

[Peter Sewell]

I remember we found something odd about this in our Netsem formal TCP
spec - see item 12 of the "Implementation anomalies" on p. 64 of:
http://www.cl.cam.ac.uk/~pes20/Netsem/tr.pdf, pasted below.

Peter


12. (Protocol bug) States in which we have received a FIN
TCPS_HAVERCVDFIN(s) is defined as:
In the BSD code, the macro
#define TCPS_HAVERCVDFIN(s) ((s) >= TCPS_TIME_WAIT)
Clearly, this set of states should also include CLOSE WAIT, LAST ACK
and CLOSING, since we
must have received a FIN segment to enter such a state.
This macro is used three times in the code (in tcp_input.c),
preventing the following from happening
if we believe we have received a FIN :
1. Processing of urgent data (i.e. from segments with the URG flag set).
2. Processing normal data data, and arranging to ACK it.
3. Processing a FIN segment and performing the appropriate state changes.
See deliver in ∗.

Impact: A consequence of the first of the above is that it is possible
(with suitably
crafted segments) to generate a SIGURG signal from a socket after its
connection has been closed. Data
may also be received by a closing socket. Similarly, extra FIN s will
be processed, causing an ACK to
be emitted and an increment of the sequence number (of course this
will only happen if the peer’s TCP
stack is broken, or malicious).

On 9 January 2016 at 15:11, Jonathan T. Looney <jtl at freebsd.org> wrote:
> On 1/8/16, 4:45 PM, "owner-freebsd-transport at freebsd.org on behalf of Sam
> Kumar" <owner-freebsd-transport at freebsd.org on behalf of
> samkumar99 at gmail.com> wrote:
>
>>I am working with the code for the TCP Stack.
>
> Thanks for choosing FreeBSD! :-)
>
>
>>In summary I suspect that the TCPS_HAVERCVDFIN macro needs to be
>>redefined,
>>but I'm not sure whether that is actually the case. I wanted to open a
>>discussion about this to explore whether this is a legitimate issue.
>
> In short, it appears you are correct that the macro name does not match
> the reality of what it checks. This is likely to cause a problem at some
> point, so it is legitimate to suggest it be fixed.
>
> However, this is non-trivial for at least several reasons:
>
> A) Changing this will require thoroughly testing all the impacted code.
> That requires both a thorough conformance-testing suite, as well as
> thorough performance tests (in case the change impacts performance).
> However, I don't think the FreeBSD project itself has such things at the
> moment. (gnn@ might have more to say on this topic. :-) )
>
> B) Even if the code you reference made an erroneous assumption, others may
> have written other code that assumes the current behavior. Changing the
> current behavior to be "more correct" might impact other code in subtle
> ways. (Hence, the need for testing: see (A).)
>
> C) Even if we can fully qualify that *our* code works correctly after
> changing this, third parties may have extended our system in ways that
> rely on the current behavior. (Hence the need for testing. They "own" that
> to some extent. But, we owe them some duty to be careful about changing
> basic building blocks they may use.)
>
> D) Changing this may make it harder to port code from other OSs. For
> example, OpenBSD uses the same definition of TCPS_HAVERCVDFIN that we do.
> On the other hand, it looks like NetBSD updated theirs (17 years ago!) to
> something closer to what you suggest. So, porting code from other OSs may
> already be problematic.
>
> Because we now have some level of TCP stack modularity, we *should* be
> able to build a TCP module that does what you suggest and let people try
> it out while maintaining the option to fallback to the main stack if
> things go haywire. However, that is more complicated than I wish it were
> because it currently requires *copying* code rather than just compiling
> the same code a second time. I have a proposal to address that, but need
> to circulate it and get feedback.
>
> In the meantime, we can talk through some of these obstacles and see how
> we want to handle this. We can always define two macros (the old and new
> one) and change the macro usage from the old to the new one as we feel
> comfortable. If there is desire to proceed, I would recommend that as the
> way forward, assuming we can satisfy the testing concerns.
>
> Jonathan
>
>
> _______________________________________________
> freebsd-transport at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-transport
> To unsubscribe, send any mail to "freebsd-transport-unsubscribe at freebsd.org"