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

["Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[e-mail]>]

Hi Fernando, here are some comments from me as a WG participant (not a co-chair):

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.

In section 1.1, I think the first 2 paragraphs can be removed without any loss of context or content.

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.  As nearly all of the vendors who have implemented these fixes participate in the IETF, it seems they haven't felt a compelling urge to have their implementation practices codified in RFCs.  At least explaining this seems more valuable than the nebulous "For some reason" which makes it sound like this is just a strange occurence with no clear explanation, though I believe the sentence can just be completely removed without any loss to the document.

In the sentence "Producing a secure TCP/IP implementation ...", I think we should just say "TCP" (and change "protocols" to "protocol and dependencies or extensions".  Also, in this sentence, I'm unclear on what a "security roadmap" would look like; should this really be a "threat and mitigation summary"?

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.

The paragraph beginning with "This document is the result of a security assessment of the IETF specifications of the Transmission Control Protocol (TCP), from a security point of view.  Possible threats are identified and, where possible, countermeasures are proposed." should be replaced with something to the effect of "This document captures the best current practices in implementation, configuration, and use of TCP and its supporting protocols and extensions and has been produced by the IETF's TCP Maintenance and Minor Extensions Working Group (TCPM)."

Section 2 can be eliminated without any loss.

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.
"""
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.

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, 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,

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.


For high-level discussion, some of these comments are based on a desire to shorten, simplify, or clarify the presentation of these recommendations.  Looking at this first batch, it's a mix of things that an implementer may or may not care about depending on their implementation constraints or deployment environments.  For instance, in this first batch alone, some of the recommendations are for basic robustness to bizarre conditions whereas others are for making fingerprinting "attacks" less effective.  We will need some way to distinguish the types of attacks that are relevant to each 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.  I bring this option up since the prior thread on outlines didn't seem to drive to a clear consensus on what the next outline would look like, and this update left it almost completely unchanged so I think we need to find a way to deal with this type of complexity in mixed relevance of the recommendations going forward or it will be more difficult to sort out later.  But that's just my 2 cents.



________________________________________
From: [e-mail] [[e-mail]] On Behalf Of Fernando Gont [[e-mail]]
Sent: Friday, February 19, 2010 7:10 PM
To: [e-mail]
Subject: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security

Folks,

I have just posted a revision (-01) of draft-ietf-tcpm-tcp-security. The
document is available at the usual places (including:
http://tools.ietf.org/id/draft-ietf-tcpm-tcp-security-01.txt).

The current plan is discuss each section of the draft piecemeal (it is a
very large document), get consensus on the changes to apply to the
existing text, and then move on to the next section.

Therefore I'm requesting feedback on all the sections through Section
3.1.2.3. -- this includes the introduction sections, the basic
check on the TCP segment size (Section 3) and the discussion of port
numbers (Section 3.1 with all its subsections).

Please review these sections and submit comments by Friday March 5th,
2010, so that we can move on to the next sections in a timely manner.

Thanks!

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




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