Subject: [Tsvwg] Fwd: draft-ietf-tsvwg-port-randomization-00

From: Fernando Gont <[email-masked]>
Date: Wed, 26 Dec 2007 20:46:26 -0300

Folks,

FYI, Alfred Hoenes sent us (off-list) this 
feedback for the port randomization draft.

Kind regards,
Fernando

>X-Flags: 1001
>Delivered-To: GMX delivery to [email-masked]
>From: Alfred =?hp-roman8?B?SM5uZXM=?= <[email-masked]>
>Subject: draft-ietf-tsvwg-port-randomization-00
>To: [email-masked], [email-masked]
>Date: Fri, 14 Dec 2007 20:31:28 +0100 (MEZ)
>X-Mailer: ELM [$Revision: 1.17.214.3 $]
>X-GMX-Antivirus: -1 (not scanned, may not use virus scanner)
>X-GMX-Htest: 0.48
>X-GMX-Antispam: 0 (Mail was not recognized as spam)
>X-GMX-UID: CrcAE2tWbXBttuhMDDU2yEAqLyUmZUjV
>
>The items below are presented in textual order.
>To give more context, sometimes I quote larger blocks of text
>literally and show the replacement proposed using the shorthand
>notation:
>
>    <original draft text>
>---
>    <modified text>
>
>I use change bars ('|' in column 1) and occasionally
>up/down pointing marker lines ('^^^'/'vvv') to emphasize
>the location of textual issues and/or proposed corrections.
>Modified text has been re-adjusted to match RFC formatting
>rules, where appropriate.  I also try to accomodate published
>RFC-Ed policy on style and punctuation etc. in my proposals.
>
>
>(1)  General: terminology
>
>I suggest to generally replace "five-tuple" by the established
>term "quintuple", in all running text and in the pseudo-code.
>
>
>(2)  Abstract -- typo/grammar
>
>Please correct the singular/plural mismatch near the end of the
>Abstract:
>
>  ... are local modification that may be ... and that *do* not violate ...
>
>I.e., perform the change:
>
>                  [...].  The mechanisms described in this document are a
>|  local modification that may be incrementally deployed, and that does
>    not violate the specifications of any of the transport protocols that
>    may benefit from it, such as TCP, UDP, SCTP, DCCP, and RTP.
>---
>                  [...].  The mechanisms described in this document are a
>|  local modification that may be incrementally deployed, and that do
>    not violate the specifications of any of the transport protocols that
>    may benefit from it, such as TCP, UDP, SCTP, DCCP, and RTP.
>
>
>(3)  ToC
>
>The headlines of App. B.1 and B.2 erroneously again use "-randomisation-"
>in place of "-randomization-" . Please correct the ToC entries ...
>
>      B.1.  Changes from draft-larsen-tsvwg-port-randomisation-02  . . 20
>      B.2.  Changes from draft-larsen-tsvwg-port-randomisation-01  . . 20
>---
>      B.1.  Changes from draft-larsen-tsvwg-port-randomization-02  . . 20
>      B.2.  Changes from draft-larsen-tsvwg-port-randomization-01  . . 20
>
>and apply the same changes in the appendix proper.
>
>
>(4)  Section 1
>
>In the 5th paragraph, I suggest to change:
>                                                      v
>|  This document describes a number of algorithms for random selection
>    of the client ephemeral port, that reduce the possibility of an off-
>    path attacker guessing the exact value.  [...]
>---                                                  vvvvv
>|  This document describes a number of algorithms for the random
>    selection of the client ephemeral port, that reduce the possibility
>    of an off-path attacker guessing the exact value.  [...]
>
>In the 7th (=last) paragraph, I suggest to change:
>
>    Since these mechanisms are obfuscation techniques, focus has been on
>|  a reasonable compromise between level of obfuscation and ease of
>    implementation.  Thus the algorithms must be computationally
>    efficient, and not require substantial data structures.
>---
>    Since these mechanisms are obfuscation techniques, focus has been on
>|  a reasonable compromise between the level of obfuscation and the ease
>                                   ^^^^^                        ^^^^^
>    of implementation.  Thus the algorithms must be computationally
>    efficient, and not require substantial data structures.
>
>
>(5)  Sections 2.1 and 3.*
>
>The (constant) expression,
>      max_ephemeral - min_ephemeral + 1
>appears so frequently in the pseudocode fragments that readability
>would be much improved by assigning it a specific name / variable.
>In particular, I recommend to add to the 'initialization' part of
>Figure 1..5 the line:
>
>       num_ephemeral = max_ephemeral - min_ephemeral + 1;
>
>and replace all existing occurrences of the expression above by
>"num_ephemeral" .
>
>I omit to present the details for this change below.
>
>
>(6)  Section 3.2.2
>
>The final paragraph of Section 3.2.2 says:
>
>    We will refer to this algorithm as 'Algorithm 2'.  The only
>    difference between this algorithm and Algorithm 1 is that the search
>|  time for this variant may be longer than for the later, particularly
>               vvv                                   ^^^^^
>|  when there are a large number of port numbers already in use.
>
>I suggest to improve the wording/grammar as follows:
>
>    We will refer to this algorithm as 'Algorithm 2'.  The only
>    difference between this algorithm and Algorithm 1 is that the search
>|  time for this variant may be longer than for the latter, particularly
>               vv                                    ^^^^^^
>|  when there is a large number of port numbers already in use.
>
>
>(7)  Section 3.2.3
>
>The first paragraph in that section says:
>                                                         v
>|  We would like to achieve the port reuse properties of traditional BSD
>    port selection algorithm, while at the same time achieve the
>    obfuscation properties of Algorithm 1 and Algorithm 2.
>
>I suggest to add the missing definite article:
>                                                         vvvvv
>|  We would like to achieve the port reuse properties of the traditional
>    BSD port selection algorithm, while at the same time achieve the
>    obfuscation properties of Algorithm 1 and Algorithm 2.
>
>The last paragraph of Section 3.2.3 says:
>                                                                     v
>|  The ability of hostnames to uniquely define hosts can be discusses,
>|  and since SCTP always include at least one IP address, we recommend
>    to use this as input to the offset function F() and ignore hostnames
>    chunks when searching for ephemeral ports.
>
>I suggest the following fixes of the grammar:
>                                                                     v
>|  The ability of hostnames to uniquely define hosts can be discussed,
>|  and since SCTP always includes at least one IP address, we recommend
>                                 ^
>    to use this as input to the offset function F() and ignore hostnames
>    chunks when searching for ephemeral ports.
>
>
>(8)  Section 3.2.4
>
>In the first paragraph, please remove the spurious comma:
>                                 v
>                                                              [...].  The
>|  system would keep an array of, TABLE_LENGTH short integers, which
>    would provide a separation of the increment of the 'next_ephemeral'
>    variable.  [...]
>---
>                                                              [...].  The
>|  system would keep an array of TABLE_LENGTH short integers, which
>    would provide a separation of the increment of the 'next_ephemeral'
>    variable.  [...]
>
>In the 3rd line of the pseudocode in Figure 5, for clarity I suggest
>to adopt `C`-like notation,  "random()"  in place of just "random",
>which looks like a variable, but is a function:
>
>            table[i] = random % 65536;
>---
>            table[i] = random() % 65536;
>
>For consistency with the expanded scope of the draft and the quintuple-
>matching now performed, I suggest to expand the interface of the offset
>function F() to also include the 'protocol', and to allow for special
>'wildcard' values (e.g., NULL pointers in `C`) for all address and port
>arguments of F().
>(Note: This need becomes most apparent when reading the final parts
>of Section 3.4 !)
>
>The 4th text paragraph ("The array ...") refers to "Algorithm 2".
>I strongly suspect that the renumbering of algorithms performed by
>you has missed this point and that this phrase should still refer to
>what now is named "Algorithm 1".
>Please fix the number.
>
>
>(9)  Section 3.3
>
>In the second paragraph, please remove the improper hyphenation
>(only applicable to attributal and adverbial context):
>
>           s/32-bits should/32 bits should/
>
>           s/64-bits or more/64 bits or more/
>
>
>(10)  Section 3.4
>
>Please correct, at the end of the second paragraph:
>
>                     [...].  However, they may increase the chances of
>|  port number collisions, which could lead to failure of the connection
>    establishment attempts.
>---
>                     [...].  However, they may increase the chances of
>|  port number collisions, which could lead to failures of the
>    connection establishment attempts.
>
>See also item (8) above for an appropriate modification of F() that
>would allow for an elegant treatment of the special cases addressed
>in the final part of Section 3.4.
>
>
>(11)  References
>
>RFC 2960 has been superseded by RFC 4960, and the text does not
>contain any more a reference to  [RFC2960] .
>Hence the entry  [RFC2960]  should be deleted from Section 6.1.
>
>There have been left a few typographic issues in Setcion 6.2.
>Please change the following entries:
>
>    [Silbersack] Silbersack, M., "Improving TCP/IP security through
>               randomization without sacrificing interoperability.",
>|             EuroBSDCon 2005 Conference , 2005.
>---                                     ^^
>    [Silbersack] Silbersack, M., "Improving TCP/IP security through
>               randomization without sacrificing interoperability.",
>|             EuroBSDCon 2005 Conference, 2005.
>                                         ^
>
>    [Stevens]  Stevens, W., "Unix Network Programming, Volume 1:
>|             Networking APIs: Socket and XTI,  Prentice Hall", 1998.
>---                                          ^^^             ^^
>    [Stevens]  Stevens, W., "Unix Network Programming, Volume 1:
>|             Networking APIs: Socket and XTI", Prentice Hall, 1998.
>                                              ^^^             ^
>
>    [Watson]   Watson, P., "Slipping in the Window: TCP Reset attacks",
>|             december 2003.
>---           ^
>    [Watson]   Watson, P., "Slipping in the Window: TCP Reset attacks",
>|             December 2003.
>               ^
>
>(12)  Appendices A.*
>
>I suspect that the renumbering of the algorithms presented in the body
>of the draft has also missed the Appendices A.*, and that A.1, A.2, and
>A.4 in fact should refer to Algorithm *1* in place of Algorithm *2*.
>Please check!
>
>
>(13)  Appendices B.{1,2}
>
>(Just to remind you:) See item (3) above!
>
>
>Best regards,
>   Alfred HÎnes.
>
>--
>
>+------------------------+--------------------------------------------+
>| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
>| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
>| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
>+------------------------+--------------------------------------------+

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