Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security

[Fernando Gont <[e-mail]>]

Hi, Wes,

*Some* comments inline....

> There was mailing list discussion, and seemingly agreement, on Toby's
> suggestion changing the title to reflect the focus on implementation
> practices, but the title is not changed.

Yes. Thanks for catching this one! (Do not recall what we had converged
to, but will dig the archive... )



> There is a sentence that can simply be removed without any loss: "For
> some reason, much of the effort of the security community on the
> Internet protocols did not result in official documents (RFCs) being
> issued by the IETF (Internet Engineering Task Force)."  This doesn't
> consider the fact that protocol specifications in the IETF and many (if
> not most) other SDOs are focused on producing interoperable
> specifications with implementation detail left to individual vendors to
> differentiate their products.  In the case of many of these TCP
> vulnerabilities under discussion, many clearly fall into the realm of
> implementation issues rather than protocol issues, and are thus outside
> the traditional scope of IETF process.  

But virtually all the other ones have not been addressed in RFCs,
either. For instance, RFC 1948 was probably one of the first and only
RFCs on TCP security issues (Other than your informational RFC on syn
flooding, Joe's RFC on in-window attacks, tcp-secure, and the
icmp-attacks i-d...) -- and it was an *Informational* I-D.



> I believe section 1.2 can be entirely eliminated without any loss.  I
> believe we will cover quite a bit more than just the documents listed in
> this section anyways.

As the author of the I-D, I'd say that section is probably the most
unfair of all :-)O (see the "References" section, and *that* will give
an idea of what I had to read to write the I-D). But I do believe it is
valuable to list the specs that were formally assessed (although I'm
sure some are missing in the list).

What do others think about this?



> In section 3, an implementation requirement seems to be laid out with a
> mix of informal and standards language (it initially uses "should"
> instead of MUST, SHOULD, MAY, etc, yet later uses a MUST) and it's not
> included in the requirements section like the 3.1.1 recommendations are:
> """
> Therefore, before doing any processing of the TCP header fields, the
>    following check should be performed by TCP on the segments handed by
>    the internet layer:
> 
>                              Segment.Size >= 20
>    If a segment does not pass this check, it MUST be dropped.
> """

Yes, I'll fix this in the next rev (change it to the
REQUIREMENTS/DISCUSSION format).



> Further, I believe that if this document is to contain dozens of
> recommendations, then these should be better identified and individually
> numbered rather than mixed with prose.
> 
> In 3.1.1, I think the requirements should be individually numbered
> (maybe as R.1a, R.1b, etc. in this section?) so that they can be
> referenced individually and used in checklists or compliance matrices.

I have no problem with numbering each requirement.

That said, what naming scheme are you thinking of? Flat, or what?



> Regarding the requirement:
> """
>    If a segment is received with port 0 as
>    the Source Port or the Destination Port, a RST segment SHOULD be sent
>    in response (provided that the incomming segment does not have the
>    RST flag set).
> """
> The rationale indicates that this is to mitigate against OS
> fingerprinting, 

Actually, it's almost impossible to use port 0 reliably (many
middle-boxes already filter it, and many end-hosts do not allow its
use). So *that* is the reason for not using it.



> but no discussion motivates this particular response
> rather than other alternatives e.g. simply ignoring the segment, sending
> an ICMP port-unreachable, etc.  If there is a specific reason that this
> response is the one chosen to make all implementations look the same to
> a fingerprinting attempt, then we need to explain that,

Agreed. The rationale for that response was "responsiveness" -- i.e.,
rather than letting the connection-establishment time-out, you send an RST.

But please let me give this one another thought....



> Regarding the requirement:
> """
>    Middle-boxes such as packet filters MUST NOT assume that clients use
>    port numbers from only the Dynamic or Registered port ranges.
> """
> It's not clear to me how this improves security.

Disclaimer: I must say I wasn't sure about including this one as a
"requirement" (as this req does not aim at end-systems).

That said, while this does not improve the security of end-systems, it
provides advice on how to set policies correctly, so that communication
is not blocked mistakenly. (i.e., a middle-box must not assume that
clients only use port numbers in that range as the source port).



> recommendation, I think, which could easily be done in a set of lists in
> an appendix if the recommendations were numbered, or could be satisfied
> by using an outline organized by the things you're trying to protect.  

Such an appendix is already in the TODO list. It will be built as we vet
the recommendations.

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1