I had written (roughly):

>>it seems to me that this whole section of tcp_dooptions() should
>>increment a new counter, viewable from netstat -s (e.g. "with bad
>>options"). Agreement?  I mean a new counter, viewable from netstat
>>-s.


In message <2993.963803970@coconut.itojun.org>, itojun@iijlab.net writes:

>       i looked at it.

I presume when you say "it" you do not mean "the idea of the counter",
but rather "the behavior of tcp_dooptions()"?

>  it looks to me we need to do it carefully, including:
>       - tcp_dooptions does not raise error on invalid options or whatever
>         (return type is void).

I'm not sure what a "whatever" is. Silently ignoring unknown options
is correct, per rfc1122 page 85:

         4.2.2.5  TCP Options: RFC-793 Section 3.1

            A TCP MUST be able to receive a TCP option in any segment.
            A TCP MUST ignore without error any TCP option it does not
            implement, assuming that the option has a length field (all
            TCP options defined in the future will have length fields).
            TCP MUST be prepared to handle an illegal option length
            (e.g., zero) without crashing; a suggested procedure is to
            reset the connection and log the reason.


I suppose it could be argued that an option is defined not only by
it's option type code, but by the option type and option length pair,
and if you know an option type but your idea of the option length differs,
then you do not "know" the option.

I do not see a denial of service or security problem from ignoring
malformed options, as we do now.

Silently (from the network perspective) ignoring apparently malformed
options would seem to be the right approach approach under "Be liberal
in what you accept." I do think that such cases should get a counter
increment, though.

>         should it [1] raise error on fatal failure and cause tcp code to
>         drop the tcp segment completely?  or the current behavior [2] is
>         right? ([2] ignore tcp option part, while accepting tcp segment)
[] mine.

or should it [3] reset the connection? I would say that [1] is wrong,
and it is between [2] and [3]. Given the lack of a convincing rationale
for [3], I think we should go with [2].


Perhaps a tcp-impl discussion should be initiated.

>       - tcp_dooptions try to skip over options with invalid length and
>         continue to the next option.  it looks a bit optimistic.

Does it? My reading is that it it "break"s within the for loop,
which terminates the for loop and terminates option processing.

>       we really really need to be careful doing the change, with checking
>       tcp specs.  i don't think the change should go into 1.5.

I think it depends on the magnitude of the change.

I'm of mixed minds as to whether adding a counter is appropriate for 1.5;
I would make the change and ask releng.

--jhawk