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

[Alfred Hönes <[e-mail]>]

[[  resending due to problem with antispam measures (now resolved)  ]]


> From: Alfred Hönes <ah@.TR-Sys.de>
> To: [e-mail]
> Cc: [e-mail]
> Message-Id: <[e-mail]>
> Date: Mon, 22 Mar 2010 21:03:53 +0100 (MEZ)
> Subject: Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security

Prologue:
  It's always a trouble with the rush during the last few weeks
  before an IETF meeting, and all folks expecting feedback for
  updates shipped based on comments sent over several months,
  and all "hopefully before the wg session".  :-)


Nevertheless, I have provided a detailed off-list editorial review
of the current snapshot of the tcp-security draft.

I do not want to waste list bandwidth for the bulk of my
suggestions, and so only highlight the most important things I found:


(1)  General

I suggest to transform References as needed in text plugged into
the WG draft and move them from the 'old refs' to the 'new Refs.'
Note that space characters are not possible in ref. anchors for the
RFC Editor, so e.g. [Silbersack, 2005] needs to become [Silbersack2005]
(or a shorter form).

[...]

(3)  Section 1.2

I suggest to leave off the parenthetical page counts in the list
of RFCs and instead place ref. tags ("anchors") there.  (1) applies.
I also suggest to only use the "official" titles from the RFC index
(for RFC 793).

[...]

The obsolescence of RFC 2581 should be noted; e.g.:

   o  RFC 2581, "TCP Congestion Control" (14 pages)
---
   o  RFC 2581, "TCP Congestion Control" [RFC2581]
      (recently superseded by RFC 5681)

... and add at the end of the list:

   o  RFC 5681, "TCP Congestion Control" [RFC5681]
      (successor of RFC 2581)

Further, since UTO should be dealt with among the TCP options,
I'd suggest to add RFC 5482.

[...]

(4)  Section 1.3

I suggest to reflect the intended grouping in the draft by adding
"direct" as shown below:

   This document is basically organized in two parts.  The first part
   contains a discussion of each of the TCP header fields, identifies
|  their direct security implications, and discusses the possible
   countermeasures.  The second part contains an analysis of the
   security implications of the mechanisms [...]

[...]

(4)  Section 2

(4.1)  2nd para and Figure 1

I propose to replace "DARPA" (which is in no way specific to the
ARPANET or the Internet) by "TCP/IP"  and "reference model" by
"layering model".

[...]

The caption of Fig. 1 then can be simplified:

                Figure 1: TCP in the DARPA reference model
---
                   Figure 1: The TCP/IP Layering Model

(4.2)  2nd-to-last para

Here as well, the transition from RFC 2581 to RFC 5681 should be
mentioned.

[...]

(6)  Section 3.1.1

(6.1)  2nd para (and other similar places)

For clarification, I suggest adding "already" :

                        [...]  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 already
   have the RST flag set).

[...]

(6.3)  5th para

Privileged ports usually are 0-1023, not including 1024 !
Due to recurring issues, I once more urgently recommend to add the
salvatory clause from RFC 1122 that no system should assume that
another system makes this distinction.

   While some systems restrict use of the port numbers in the range
|  0-1024 to privileged users, applications SHOULD NOT grant any trust
|  based on the port numbers used for a TCP connection.
---
   While some systems restrict use of the port numbers in the range
|  0-1023 to privileged users, applications SHOULD NOT grant any trust
|  based on the port numbers used for a TCP connection, and a system
|  making this distinction locally MUST NOT assume that other systems
|  do that as well (cf. [RFC1122] and [RFC1812]).

(6.4)  last para

[...]

For similar reasons, I suggest to even more strongly state here:

   Middle-boxes such as packet filters MUST NOT assume that clients use
|  ephemeral port numbers from only some restricted port range.
   ^^^^^^^^^^                       ^^^^^^^^^^^^^^^^^^^^^^^^^^

[...]

(9)  Section 3.1.2.2

(9.1)  1st para

The text there abuses the term "obfuscation" (cf. my LC comments for
the Port Randomization draft on TSVWG).

      ... obfuscation of this four-tuple to an off-path attacker ...

does not make sense IMO. The four-tuple is in the clear.  Simply say:

      ... randomization of this four-tuple ...

Later on:

    ... since this increases the obfuscation.  [...]

might better state:

    ... since this decreases the likelihood of correct guessing by an
    off-path attacker.  [...]

[...]

(10)  Section 3.1.2.3, 3rd para

The present text there IMO confuses ephemeral ports and connection
IDs -- the same ephemeral port can independently be used for other
destinations.

I suggest to add much more precision to the text and amend the
paragraph as follows:

   If the connection rate is high enough, at some point all the
   ephemeral ports at the client will be in use by some connection in
|  the TIME-WAIT state, thus preventing the establishment of new
|  connections.  In order to overcome this problem, a number of TCP
|  implementations include some heuristics to allow the creation of a
|  new incarnation of a connection that is in the TIME-WAIT state. [...]
---
   If the connection rate is high enough, at some point all the
   ephemeral ports at the client will be in use by some connection in
|  the TIME-WAIT state with the same source IP address and destination
|  IP address and port number, thus preventing the establishment of new
|  connections to that server.  If the client detects such saturation of
|  connections in TIME-WAIT state, it must defer (although some
|  implementations will prematurely re-use a previous connection
|  identifier).  For the case where the server encounters such TIME-WAIT
|  saturation, a number of TCP implementations include some heuristics
|  to overcome this problem and allow the creation of a new incarnation
|  of a connection that is in the TIME-WAIT state.  [...]


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+