[tsvwg] AD review: draft-ietf-tsvwg-port-randomization-05

[Lars Eggert <[e-mail]>]

Hi,

sorry that I didn't manage to review this document early (= during WG last call). I have a few comments and there are a pretty long list of nits to fix, which I think will require another revision.

Overall, this document is OK, but I really wish that it'd be crisper, given that it'll become a BCP. There's a bunch of duplication of content between the earlier and the latter sections, I wish the language would be more precise in some places, and I have this vague feeling that the content could be presented in a more structured format. But I realize that a bunch of this is personal preference and not really realistic to achieve at this time. The document is good enough to publish, modulo my detailed comments below.

Lars


  Note: Most comments marked as nits below have been automatically
  flagged by review scripts - there may be some false positives in
  there.


INTRODUCTION, paragraph 2:
>                            Port Randomization

  It would be good to find a more precise title. Maybe "Transport
  Protocol Port Randomization Recommendations" or something along those
  lines?


INTRODUCTION, paragraph 13:
> Copyright Notice

  The document seems to lack a disclaimer for pre-RFC5378 work, but was
  first submitted before 10 November 2008.  You should add the
  disclaimer.


Section 1., paragraph 1:
>    Recently, awareness has been raised about a number of "blind" attacks
>    (i.e., attacks that can be performed without the need to sniff the
>    packets that correspond to the transport protocol instance to be

  By "instance" you mean "connection"? I'd mildly prefer to use
  connection, esp. since you don't use the term "instance" consistently
  in the document anyway.


Section 1., paragraph 5:
>    While the server IP address and well-known port and the client IP
>    address may be accurately guessed by an attacker, the ephemeral port
>    of the client is usually unknown and must be guessed.

  Wording: "accurately guessed" followed by "must be guessed" sounds
  strange. Suggest s/accurately guessed/known/.


Section 1., paragraph 6:
>    This document describes a number of algorithms for the selection of
>    the ephemeral ports, such that the possibility of an off-path

  Wording. s/the ephemeral ports/an ephemeral port number for a
  connection instance/


Section 1., paragraph 8:
>    The mechanisms described in this document are local modifications

  Nit: s/local/local, sender-side/


Section 1., paragraph 9:
>    that may be incrementally deployed, and that does not violate the

  Nit: s/does/do/


Section 1., paragraph 10:
>    specifications of any of the transport protocols that may benefit
>    from it, such as TCP [RFC0793], UDP [RFC0768], SCTP [RFC4960], DCCP

  Nit: s/it/them/


Section 2., paragraph 0:
> 2.  Ephemeral Ports

  I don't really understand the purpose of Section 2. Almost all content
  is again covered in Section 3.


Section 2.1., paragraph 5:
>    The range for assigned ports managed by the IANA is 0-1023, with the
>    remainder being registered by IANA but not assigned.

  This is from the IANA web page, but I think it's actually incorrect.
  IANA manages the entire range 0-65536, and makes assignments in the
  0-49151 range, with the 49152-65536 range being unassignable.


Section 2.1., paragraph 6:
>    The ephemeral port range defined by IANA has traditionally consisted
>    of the 49152-65535 range.

  Not only "traditionally" - it is still defined to be that range.


Section 2.2., paragraph 6:
>            if (five-tuple is unique)
>                return port;

  This syntax doesn't really make it clear that the "five-tuple is
  unique" check uses is done with "port" as the candidate ephemeral
  port. (Also elsewhere.)


Section 2.2., paragraph 11:
>    This algorithm works well provided that the number of connections for
>    a each transport protocol that have a life-time longer than it takes
>    to exhaust the total ephemeral port range is small, so that five-
>    tuple collisions are rare.

  I wouldn't say it "works well". It manages to generate unique
  ephemeral ports, but they're predictable. Say maybe that it "works
  adequately" or something like that?


Section 2.2., paragraph 12:
>    source port values to obtain the number of outoing TCP connections

  Nit: s/outoing/outgoing/


Section 2.3., paragraph 0:
> 2.3.  Collision of connection-id's

  What is a connection-id? Hasn't been defined so far and isn't defined
  in this section either.


Section 2.3., paragraph 1:
>    not currently in use at that system, the resulting connection-id may

  Nit: s/at/by/


Section 2.3., paragraph 3:
>    Another possible approach to minimize the rate of collisions of
>    connection-id's would be for both end-points of a TCP connection to
>    keep state about recent connections (e.g., have both end-points end
>    up in the TIME-WAIT state).

  I wouldn't call this a "possible" approach. It has significant
  drawbacks that make it unsuitable for real deployments (state
  explosion at servers). It's at best a strawman.


Section 3.1., paragraph 1:
>    There are a number of factors to consider when designing a policy of
>    selection of ephemeral ports, which include:

  Nit: s/policy of selection/algorithm for selecting/


Section 3.1., paragraph 5:
>    connection-establishment, or data curruption) discussed in

  Nit: s/curruption)/corruption)/


Section 3.1., paragraph 9:
>    was in use, the application would fail.  Therefore, transport
>    protocols should avoid using those port numbers as ephemeral ports.

  s/transport protocols/port randomization algorithms/


Section 3.1., paragraph 10:
>    Port numbers that are currently in use by a TCP in the LISTEN state
>    should not be allowed for use as ephemeral ports.

  This policy is TCP-specific. Can we broaden this to other transport
  protocols?


Section 3.1., paragraph 11:
>    not complied, an attacker could potentially "steal" an incoming

  Nit: s/complied/complied with/


Section 3.1., paragraph 13:
>    It should be noted that most applications based on popular
>    implementations of TCP API (such as the Sockets API) perform "passive
>    opens" in three steps.  Firstly, the application obtains a file
>    descriptor to be used for inter-process communication (e.g., by
>    issuing a socket() call).  Secondly, the application binds the file
>    descriptor to a local TCP port number (e.g., by issuing a bind()
>    call), thus creating a TCP in the fictional CLOSED state.  Thirdly,
>    the aforementioned TCP is put in the LISTEN state (e.g., by issuing a
>    listen() call).  As a result, with such an implementation of the TCP
>    API, even if port numbers in use for TCPs in the LISTEN state were
>    not allowed for use as ephemeral ports, there is a window of time
>    between the second and the third steps in which an attacker could be
>    allowed to select a port number that would be later used for
>    listening to incoming connections.  Therefore, these implementations
>    of the TCP API should enforce a stricter requirement for the
>    allocation of port numbers: port numbers that are in use by a TCP in
>    the LISTEN or CLOSED states should not be allowed for allocation as
>    ephemeral ports [CPNI-TCP] [I-D.gont-tcp-security].

  This is again entirely about TCP. Do similar issues not exist for
  other transport protocols?


Section 3.2., paragraph 1:
>    As mentioned in Section 2.1, the ephemeral port range has
>    traditionally consisted of the 49152-65535 range.

  It *still* consists only of that range.


Section 3.2., paragraph 2:
>      However, it should
>    also include the range 1024-49151 range.

  You're mixing two things here: (1) the ranges for which IANA has
  different allocation rules for and (2) which range the host should
  randomize over. I understand that you want to say that (2) should be
  larger than the ephemeral range in (1), but that is *not* the same as
  making the ephemeral range larger.


Section 3.2., paragraph 3:
>    Since this range includes user-specific server ports, this may not
>    always be possible, though.

  It doesn't just include "user specific server ports" - it includes
  ports that IANA has assigned.


Section 3.2., paragraph 5:
>    Transport protocols SHOULD use the largest possible port range, since
>    this improves the obfuscation provided by the ephemeral port
>    selection algorithms.

  s/Transport protocols SHOULD use/Port randomization algorithms SHOULD
  randomize over/ and remove the redundant part after "obfuscation."


Section 3.3., paragraph 1:
>    Transport protocols SHOULD obfuscate the allocatation of their

  Nit: s/allocatation/allocation/


Section 3.3.1., paragraph 2:
>        next_ephemeral = min_ephemeral + (random() % num_ephemeral);

  You need to say somewhere what you expect random() to return.


Section 3.3.1., paragraph 11:
>    multiple peers into the same port space and thus increse the

  Nit: s/increse/increase/


Section 3.3.1., paragraph 14:
>    This algorithm selects ephemeral port numbers randomly and thus
>    reduces the chances of an attacker of guessing the ephemeral port
>    selected for a target connection.  Additionally, it prevents
>    attackers from obtaining the number of outgoing connections
>    established by the client in some period of time.

  It sounds like you should move this paragraph up to the beginning of
  this discussion.


Section 3.3.3., paragraph 1:
>    We would like to achieve the port reuse properties of the traditional

  When you say "we would like <x>" a number of times in this section,
  it's not clear if you mean "it could be beneficial to have one
  algorithm with property <x>" or "we would like <x> for all
  algorithms." I assume the former, but it's not clear and can be better
  phrased.


Section 3.3.3., paragraph 15:
>    The local IP address and remote port may in some cases
>    be constant and not improve the connection separation, however, they
>    should also be included in the offset calculation.

  What do you mean by "separation"?


Section 3.3.3., paragraph 20:
>    It should be note that, as this algorithm uses a global counter

  Nit: s/note/noted/


Section 3.3.3., paragraph 21:
>    values to obtain the number of outoing TCP connections established

  Nit: s/outoing/outgoing/


Section 3.3.4., paragraph 12:
>    The array 'table[]' assures that succesive connections to the same

  Nit: s/succesive/successive/


Section 3.3.5., paragraph 10:
>    similar this algorithm is to the traditioanl BSD port selection

  Nit: s/traditioanl/traditional/


Section 3.4., paragraph 4:
>    the previous secret, ths leading to the selection of a port number

  Nit: s/ths/thus/


Section 3.5., paragraph 1:
>    [Allman] is an empyrical study of the properties of the algorithms

  Nit: s/empyrical/empirical/


Section 3.5., paragraph 2:
>    That is, in those network scenarios asessed by [Allman] all of the

  Nit: s/asessed/assessed/


Section 3.5., paragraph 3:
>    algorithms described in this document perform good in terms of

  Nit: s/good/well/


Section 3.5., paragraph 5:
>    The algorithm sketched in Figure 1 is the traditional ephemeral port

  It's a bit confusing to refer to one algorithm by "Figure 1" and to
  another *different* one as "Algorithm 1". I suggest to remove the
  "Figure X" title from all figures and instead refer to all algorithms
  by a unique number.


Section 3.5., paragraph 6:
>    leads to a low port resuse frequency.

  Nit: s/resuse/reuse/


Section 3.5., paragraph 7:
>    Algorithm 1 and Algorithm 2 have the advantage that they provide
>    complete randomization.

  Don't understand what you mean by "complete randomization".


Section 3.5., paragraph 9:
>    Algorithm 3 provides complete separation in local and remote IP
>    addresses and remote port space, and only limited separation in other
>    dimensions (see Section 3.4).

  Don't understand what you mean by complete and limited "separation".


Section 3.5., paragraph 12:
>    algorithms (Algorithm 1 and Algorthm 2) and the hash-based algorithms

  Nit: s/Algorthm/Algorithm/


Section 3.5., paragraph 17:
>    compute.  Transport protocols implementating Algorithm 3 or Algorithm

  Nit: s/implementating/implementing/


Section 4, paragraph 1:
>    in response to the bind() call.  That is, selection of an epphemeral

  Nit: s/epphemeral/ephemeral/


Section 4., paragraph 1:
>    Network Address Port Translation (NAPT) translate both the network
>    address and transport-protocol port number, thus allowing the

  *source* address and *source* port


Section 8.2., paragraph 8:
>               Computer Communicatiion Review, 39(2), 2009.

  Nit: s/Communicatiion/Communication/


Appendix A., paragraph 0:
> Appendix A.  Survey of the algorithms in use by some popular
>              implementations

  It would be useful to add which *version* of the operating systems
  below you looked at.


Appendix B., paragraph 28:
>    o  The whole document was reorganizaed

  Nit: s/reorganizaed/reorganized/