Subject: [Gen-art] Gen art LC+TC review of: draft-ietf-tsvwg-port-randomization-06

From: Avshalom Houri <[email-masked]>
Date: Thu, 4 Mar 2010 04:02:54 +0200

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-tsvwg-port-randomization-06
Reviewer: Avshalom Houri
Review Date: 2010-03-03
Last Call Date: 2010-03-02
IESG Telechat date: 2010-03-4

Summary: The document is not ready for publication as a BCP.

Major issues:

The document is lacking explanation on the when and how that the 
techniques that are
described in the document will be used. There are many ways to protect the 
network
and it is not clear when and how the specific techniques that are 
described in the
document will be used, how they relate to other ways etc.

The introductory part of the document (up to and including section 3.2) 
seems lengthy
and repeating while it is lacking some background as described in the 
previous paragraph.

Minor issues:

Lines 624-626
  However, it
   may be affected by the vector involving binding a more specific
   socket. 
-- Not clear

Lines 644-645
   Ephemeral port selection algorithms SHOULD use the largest possible
   port range, since this improves obfuscation.

-- Should be merged with lines 632-634
   As mentioned in Section 2.1, the dynamic ports consist of the range
   49152-65535.  However, ephemeral port selection algorithms should use
   the whole range 1024-49151.

Lines 870-871
   and alternative IP addresses may be included in the association
   negotiation and either of these could be used in the offset function

-- What is meant by "association negotiation"? (repeats also in line 879).

Lines 1040-0144
 The smaller the value of "N", the more linear the more
   similar this algorithm is to the traditional BSD port selection
   algorithm (described in Section 2.2.  The larger the value of "N",
   the more similar this algorithm is to the algorithm described in
   Section 3.3.1 of this document.

-- Need to rephrase

Nits/editorial comments:

Line 512:
   There are a number of factors to consider when designing an algorithm
->    There are number of factors to consider when designing an algorithm

Line 622
   DCCP is not affected is not affected by the exploitation of
->    DCCP is not affected by the exploitation of

Line 799
   will not have different sequences of port numbers; i.e., wil not be
->    will not have different sequences of port numbers; i.e., will not be

Line 869
   availability an the granularity requested.  With SCTP both hostnames
->    availability and the granularity requested.  With SCTP both 
hostnames

--Avshalom

---

From: Fernando Gont <[email-masked]>
Date: Thu, 04 Mar 2010 04:07:25 -0300

Hello, Avshalom,

Some comments inline...

> described in the document will be used. 

Not sure what you mean. Port randomization is not used in any specific
case. Transport protocols should randomize their ephemeral ports by default.

> There are many ways to protect
> the network

Port randomization mitigates off-path attacks by obfuscation. It simply
requires more work on the side of the attacker for him to successfully
forge a valid attack packet.

>    may be affected by the vector involving binding a more specific

I have clarified the text.

This is how I've modified it:

--- cut here ---
   Port numbers that are currently in use by a TCP in the LISTEN state
   should not be allowed for use as ephemeral ports.  If this rule is
   not complied with, an attacker could potentially "steal" an incoming
   connection to a local server application in at least to different
   ways.  Firstly, an attacker could issue a connection request to the
   victim client at roughly the same time the client tries to connect to
   the victim server application [CPNI-TCP] [I-D.gont-tcp-security].  If
   the SYN segment corresponding to the attacker's connection request
   and the SYN segment corresponding to the victim client "cross each
   other in the network", and provided the attacker is able to know or
   guess the ephemeral port used by the client, a TCP simultaneous open
   scenario would take place, and the incoming connection request sent
   by the client would be matched with the attacker's socket rather than
   with the victim server application's socket.  Secondly, an attacker
   could specify a more specific socket than the "victim" socket (e.g.,
   specify both the local IP address and the local TCP port), and thus
   incoming SYN segments matching the attacker's socket would be
   delivered to the attacker, rather than to the "victim" socket (see
   Section 10.1 of [CPNI-TCP]).

[....]

   The aforementioned issue do not affect SCTP, since most SCTP
   implementations do not allow a socket to be bound to the same port
   number unless a specific socket option (SCTP_REUSE_PORT) is issued on
   the socket (i.e., this behavior needs to be explititly allowed
   beforehand).  An example of a typical SCTP socket API can be found in
   [I-D.ietf-tsvwg-sctpsocket].

   DCCP is not affected by the exploitation of "simultaneous opens" to
   "steal" incoming connections, as the server and the client state
   machines are different [RFC4340].  However, it may be affected by the
   vector involving binding a more specific socket.  As a result, those
   tuples {local IP address, local port, Service Code} that are in use
   by a local socket should not be allowed for allocation as ephemeral
   ports.
--- cut here ---

Does this change address your comment?

>    the whole range 1024-49151.

Please let me know if you feel strongly about this. -- me, I believe the
explanation *between* the two paragraphs is needed.

>    Section 3.3.1 of this document.

Fixed.

> ->    There are number of factors to consider when designing an algorithm

Changed it to "There are several factors..."

> ->    DCCP is not affected by the exploitation of

Fixed.

> ->    will not have different sequences of port numbers; i.e., will not be

Fixed.

> ->    availability and the granularity requested.  With SCTP both hostnames

Fixed.

Thanks!

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

---

From: Avshalom Houri <[email-masked]>
Date: Thu, 4 Mar 2010 19:37:37 +0200

Fernando Gont <[email-masked]> wrote on 04/03/2010 09:07:25 AM:

> Re: Gen art LC+TC review of: draft-ietf-tsvwg-port-randomization-06
> 
> Fernando Gont 
> 
> to:
> 
> Avshalom Houri
> 
> 04/03/2010 09:07 AM
> 
> Cc:
> 
> michael.larsen, General Area Review Team, Russ Housley, jmpolk, 
lars.eggert
> case. Transport protocols should randomize their ephemeral ports by 
default.

Since the document is a BCP and port randomization is not part of the 
basic
transport protocols it is important to explain the use case of what is 
described
in the document. For example, are there environments where the port 
randomization
is less important? What are the risks of not using this etc. Maybe the 
right word
for what I am missing is "context". A good introduction can also help in 
getting
a better security consideration section as it will be easier to refer to 
the use
cases.

> forge a valid attack packet.

See my reply above.

>    connection to a local server application in at least to different
to->two
>    other in the network", and provided the attacker is able to know or
provided the -> provided that the
>    with the victim server application's socket.  Secondly, an attacker

Very long sentence from Firstly.

>    The aforementioned issue do not affect SCTP, since most SCTP
do->does
>    vector involving binding a more specific socket.  As a result, those

This is the first mention of the word "vector" in the document. Some
explanation may help.

>    by a local socket should not be allowed for allocation as ephemeral
be allowed for allocation -> allocated
> Does this change address your comment?

See comments above.

> explanation *between* the two paragraphs is needed.

How this sounds to you?

   As mentioned in Section 2.1, the dynamic ports consist of the range
   49152-65535.  However, ephemeral port selection algorithms should use
   the whole range 1024-49151 since ephemeral port selection algorithms
   SHOULD use the largest possible port range, as this improves 
obfuscation.

   Since this range includes ports numbers assigned by IANA, this may
   not always be possible, though.  A possible workaround for this
   potential problem would be to maintain a local list of the port
   numbers that should not be allocated as ephemeral ports.  Thus,
   before allocating a port number, the ephemeral port selection
   function would check this list, avoiding the allocation of ports that
   may be needed for specific applications.

hostnames