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

From: <[email-masked]>
Date: Mon, 1 Mar 2010 23:23:37 +0000

On 1 Mar 2010, at 06:23, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:

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

Surely, "has been roadblocked and nitpicked to death at every possible opportunity by the TCP Maintenance and Minor Extensions Working Group (TCPM), so that this document is a shadow of its former self, but has now been edited and reworked sufficiently to give TCPM the necessary sense of ownership, dominance and authorship to permit the document to proceed." ?

This group's work is no longer about TCP, but about bad document re-re-re-re-re-writing; not something I'd have the patience for, and if I was the primary originating author I'd have moved on to more satisfying things long ago.

Sorry, I'm with Alfred. His assessment of this group is correct.

I'd insist on including a reference to the original CPNI security assessment document.

L.

Lloyd Wood
[email-masked]
http://sat-net.com/L.Wood

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Mon, 1 Mar 2010 19:28:33 -0600

I don't know if you've read the document under discussion, but it already includes a reference to the CPNI security assessment you mention including a reference to, and this reference immediately follows the text I suggested clarifying to identify TCPM as the document source.

My suggestion was to put a sentence in that makes the context of the document clear, as a TCPM product, with recommendations that have been reviewed by TCPM.  It shouldn't be controversial that the WG takes ownership of a WG product.

________________________________________
From: [email-masked] [[email-masked]]
Sent: Monday, March 01, 2010 6:23 PM
To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security

L.

Lloyd Wood
[email-masked]

---

From: <[email-masked]>
Date: Tue, 2 Mar 2010 08:16:35 +0000

> I don't know if you've read the document under discussion, but it already includes a reference to the CPNI security assessment you mention including a reference to, and this reference immediately f…

No, it includes it as an inline comment - i.e. it does not have the status of an explicit reference. It's already well on its way to being elided as unnecessary as history is rewritten.

> My suggestion was to put a sentence in that makes the context of the document clear,

by removing any mention of security/threats?

> as a TCPM product, with recommendations that have been reviewed by TCPM.  It shouldn't be controversial that the WG takes ownership of a WG product.

You're right, that shouldn't be controversial. That it is says much about the way that this WG takes ownership.

L.

Lloyd Wood
[email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Wed, 03 Mar 2010 21:55:40 -0300

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: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Fri, 5 Mar 2010 09:09:43 -0600

>-----Original Message-----
>From: Fernando Gont [mailto:[email-masked]]
>Sent: Wednesday, March 03, 2010 7:56 PM
> ...

It doesn't really matter to my; my only concern was
that they each have a unique identifier to reference
against more easily than using the full sentence.
In order to not cause massive renumberings when
adding or removing, one system would be to name them
something like "R.0302001" for the first requirement
in section 3.2 and "R.1100012" for the twelfth one in
section 11 (with no subsections).  There may be a
more elegant way, I don't really care what the ID
looks like as long as there is one :).

If it's too much trouble or nobody else in the WG
cares, I don't think it's absolutely necessary, I
just would find it really helpful in my work.

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

I agree that the port can't and shouldn't be used,
but if we're starting with the assumption that it's
never legitimately used, then why would we worry
about making a timely response to incoming packets
on that port? I think it's easier to just ignore
them.  It's like sending responses to spam otherwise.

>clients only use port numbers in that range as the source port).

Ok; but implementing this requirement doesn't at all
improve the security of TCP implementations, so I
believe it's out of scope.  It seems like something
that would be included in BEHAVE's work (and maybe
it already is?), but I've not been active in that
so I could be wrong.

--
Wes Eddy
MTI Systems

---

From: Fernando Gont <[email-masked]>
Date: Fri, 05 Mar 2010 13:33:36 -0300

Hi, Wes,

> against more easily than using the full sentence.

That makes perfect sense.

> looks like as long as there is one :).

Ok, I'll use your proposal... unless somebody can quickly come up with
something that is clearly better (I can't).

FWIW, the behave folks use "REQ-n"... however, their documents usually
have no more than a dozen requirements... and thus such a "flat" naming
scheme is managable. In our case, we'll probably end-up with more than a
hundred requirements, so such a "flat" scheme would not work that well
here. A more hierarchical one such as the one you describe would work
better.

> just would find it really helpful in my work.

It's not too much trouble (I can add the "numbers" in an incremental
way... as I edit the I-D)... and it is clearly useful. So I will be
adding the req-numbers in the next rev.

(Worst case, if people don't like it, we could eventually remove the
numbers (I guess the only argument against it is that things like
"R.XXXXXX" look like cryptic, but that's it :-) )).

> them.  It's like sending responses to spam otherwise.

Makes sense to me.

(I guess at the time I decided that an RST might make sense as it would
signal a "hard error" condition... but in retrospective, I agree with
what you say. For instance, some systems already do this (ignore TCP
segments that use port 0)).

> believe it's out of scope.  

Yes, I agree. As I said before, I wasn't sure whether to include it as a
req. But did so so that we'd discuss it.

> It seems like something

And maybe not even behave... this has more to do with firewalls...

Thanks!

Kind regards,