Recommendations for Transport-Protocol Port Randomization
RFC 6056

Note: This ballot was opened for revision 09 and is now closed.

(Pasi Eronen) Discuss

Discuss (2010-03-02 for -)
I have reviewed draft-ietf-tsvwg-port-randomization-06, and have
couple of small concern that I'd like to discuss before recommending
approval of the document:

- Section 3.3.1 says '"random()" is a function that returns a
pseudo-random unsigned interger number in the range 0-65535'.

The document is not very clear on exactly what the requirements for
this function are. If I recall right, the output of typical
implementations of POSIX random() may look random to simple
statistical tests, but it is not unpredictable (seeing couple of
values allows you to fully predict future outputs).

While this use probably doesn't need a cryptographically secure 
strong random number generator, it looks like some degree of 
unpredictability would be needed?

- Section 3.4 suggests use of a 32 bit key, which has exploitable
security problems -- to make the sequence unpredictable (even after
seeing couple of values), more is needed (and since bits here are 
cheap, so there's no real reason to use less than 128).
Comment (2010-03-02 for -)
No email
send info
Charlie Kaufman's SecDir review identified a number of minor
clarifications/editorial nits that should be addressed; it seems
the authors are already addressing those.

(Cullen Jennings) Discuss

Discuss (2010-03-04 for -)
One other issues that got raised was would it be possible to give advice about getting initial randomness. Perhaps pointers to other RFC. The problem is partially hard for a small residential NAT that has just booted. Saying there should be some randomness does not really help implementers without a way to do that. 


This is a very long discuss and many of the appoints in are purely asking we certain attacks considered. It's perfectly reasonable to resolve theses with a  "Yes" and pointer to the list. 

RFC3605 is not commonly implemented for RTP and I find it very concerning that this would break RTP. The recommendation here violate the recombination in Req-4 of BCP 127. It would be very easy to define the algorithm here such that they preserved port parity. Why not do that? If one does not, some RTP receivers when told to send  RTP to port x, will deice the parity is wrong and actually send it to x-1.  This is not good. Breaking port+1 continuity breaks RTCP but that has not turned out to be as critical as breaking RTP. However, it would nice to see an this draft support that unless there was a reason it was not possible. Regardless of how we resolve this, I believe this draft needs to be changed so it is consistent with BCP 127, or we need to change BCP 127 before this can be published. We should not be publishing a draft that violates an existing BCP. 


I only find two normative statements. The first

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

This relies on the suggestion that somehow one would maintain a local list of port numbers that should not be allocated as ephemeral ports. How is a OS such as Linux supposed to actually implement this? Is there a list IANA is providing with real time updates? When IANA allocated a new port to a protocol, how long before they could reliably use that across existing computers. I don't find this to be implementable. I would like the draft updated such that it has advice that is clear to implementers what they need to do. I worry the current advice will result in ports such as 5060 being allocated and then servers tripping to run on that port not being able to get it for no reasons that is parent to the end user who will see it as an intermittent problem that goes away when they reboot. That not a design I would consider good for a BCP. 

The second normative statement is one SHOULD obfuscate the allocation of their ephemeral ports. It then goes on to describe a series of possible algorithm to do this which all seem to lack any crypto analysis. The problem of having a algorithm that generates a number that is hard to predict by an attacker that  has seen the previous sequence of numbers the algorithm produced is pretty well understood so I expected to see pointers to concrete analysis here. 

Alg 1. 

If the attacker knows that port x in in use, they know that port x+1 is twice as likely to be chosen as the next port as say x-1. I'm not a crypto person but this sort of property always makes me pretty uncomfortable about deciding what the security properties of this are. Did crypto people look at it? Can we describe the security properties of this. 

Alg 2:

You have count = num_ephemeral but I have a hard time imagining anyone would set it this high. It still won't guarantee 100% port usage as you point out in the note. It seem from the text below figure 3 you are saying that count = 2 would be fine. Same issue in some of the other ALGs. 

Alg 3:

I'm fairly skeptical of the advice on choosing the key sizes. I'm not a crypto person but I'd love to see some analysis of this. Let's consider some different keys sizes (yes, I realize the draft recommends 32 or 64, I'll get to that). If the key size was 16, and the attacker could see what port was used for a single connection, they could brute force the key space and have the key, or at least a small number of possible entries for the key if there were collisions in the MD5 space. Now lets consider a 32 bit key. Again if the attacker could see two connections, they could brute force the space (the machine I am on right now looks like it would do that in about 5 seconds) on the first connection which would get them to about 2^16 possible keys, but on the second connection, they could filter these keys and get down to a very small number. Now I realize the draft says to use 64 bits it attackers can probe for ports but do we have any crypto analysis of any of this? If 64 bits enough? 32 bits clearly is not. If I could probe for several ports and had and FPGA card in my computer, could I easily figure out 64 bits? Is there discussion on this you can point me at?

I suspect I would be much more conformable with something that had been looked at lots, like AES counter mode. Again, I'm not even qualified to suggest anything here but I'm looking for evidence the crypto stuff was seriously looked at. 

Alg 5:

The idea that an end user should configure N does not seem practical. How would they figure out what to do. Most the implementors I know would choose 500 for the default because it was in the RFC and the RFC was golden and you MUST do exactly what it says, unless of course it is a SHOULD in which case they don't even bother to read it much less do it but I degrees. The 500 is going to have a wrap around after a mere 256 ports while at the same time only proving a 8 bits of security which seems like it would be inadequate for many cases. This is harmful in that it passes an impossible hard problem of choosing a good value of N to the end user which will not provide security while at the same time providing the illusion of being more useful than it probably is. If this algorithm is not a good choice, remove it from the BCP. If it is only a good choice for certain cases, make it clear which cases this should be used instead of the other ones. 

Section 3.5 provides some ideas about pros and cons of various algorithms but no real advice one which ones to use and when. Would if be possible to pick one algorithm and just recommend that? If the view is we need to develop experience to find out which one of these is the best for a general OS, then this should be experimental not BCP. 

I find this far from what I would expect in a BCP on such an important topic. I think it could be vastly improved by having the security folks define an algorithm, working with the Apps, RAI, and behave folks to make sure that it does no more harm than necessary to existing applications. And overall make it be a tight specification where it is clear what an implementation MUST do to be compliant. A draft where vendors can have very poor implementation and still claim to be compliant is not good.
Comment (2010-03-04 for -)
No email
send info
For the IESG more than the authors .... My current understanding of BCP would imply this should be a PS that update TCP, UPD, DCCP, and SCTP but I don't really understand why it is a BCP. 

Though ephemeral pot sounds of some relevance to my discuss, I suspect you want a 
s/ephemeral pot/ephemeral port/ Having made a nearly infinite number of typos in my life, I did like this one.

Magnus Westerlund Discuss

Discuss (2010-03-03 for -)
Section 4.

If this document is supposed to make recommendations on NAT behavior I think it needs to discuss when it makes sense in the context of the terminology of the NAT behavior documents, like RFC 4787 and 5382 that do discuss port assignment in the NAT. 

As I see the NAT behavior around port obfuscation is dependent on at least three things. The nat's port assignment rule, if it is preserving. Secondly what it does when it fails to preserve and if it has port parity preservation. So I find the text under specified, but still gives recommendations that do go against the current BCPs. Thus we must also consider if this document actually updates theses BCPs.

(Jari Arkko) (was Discuss) Yes

Comment (2010-03-04)
No email
send info
The document says:

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

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

First, what does the document actually recommend as the default policy?
The use of the entire range, or the entire range minus locally 
configured list?

Second, I think the comment about IANA isn't quite right above. The
issue is not the IANA allocation, its the possibility that some
application would be running on a port. You already discussed
avoiding ports that are in the listen state. So this appears to
leave only the case where the application is not yet running
but will later run and want to use its well known port. Please
be more specific about what the problem actually is.

(Lars Eggert) Yes

(Ron Bonica) No Objection

Comment (2010-03-02 for -)
No email
send info
I support Tim's discuss regarding port range selection.

(Ross Callon) No Objection

(Ralph Droms) No Objection

Comment (2010-03-03 for -)
No email
send info
I think there needs to be some text between this text in section 2.1: 

   The dynamic port range defined by IANA consists of the 49152-65535
   range, and is meant for the selection of ephemeral ports.

and this text in section 3.1:

   It is important to note that a number of applications rely on binding
   specific port numbers that may be within the ephemeral ports range.
   If such an application was run while the corresponding port number
   was in use, the application would fail.  Therefore, ephemeral port
   selection algorithms avoid using those port numbers.

that explains the (as far as I can tell) unstated assumption that ephemeral ports could be selected from the IANA "registered" port range, 1024-49151.

Reading on, it seems the issue is addressed here:

3.2.  Ephemeral port number range

   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.

I suggest clarifying to:

3.2.  Ephemeral port number range

   As mentioned in Section 2.1, the dynamic ports consist of the range
   49152-65535.  However, ephemeral port selection algorithms should 
   also use available ports in the range of registered ports, 1024-49151.
   Therefore, the port selection algorithm should be applied to the 
   whole range 1024-65535.

(Adrian Farrel) No Objection

Comment (2010-03-11 for -)
No email
send info
It is interesting that Algorithms 1, 3, and 4 statistically favor port
numbers one greater than allocated port numbers. But probably not worth
noting.

(David Harrington) (was Discuss) No Objection

(Russ Housley) No Objection

Comment (2010-03-04 for -)
No email
send info
  Since we are trying to replace the TCP MD5 signature option [RFC2385]
  with TCP AO, it seems like a bad idea to reference it in the document
  as a security solution.

  As pointed out in the Gen-ART Review by Avshalom Houri on 2010-03-03,
  the first portion of the document (up to and including Section 3.2) is
  lengthy and repeating while it is lacking some background.  When and
  how are the techniques described in the document to be used?  Is this
  texpected to be used in every transport protocol implementation in
  every environment?

  The Gen-ART Review by Avshalom Houri also makes many suggestions for
  improving the document.  Please consider them.

Alexey Melnikov No Objection

(Tim Polk) (was Discuss) No Objection

(Dan Romascanu) No Objection

Comment (2010-03-04 for -)
No email
send info
I support the issues raised by Pasi, Robert and Tim in their DISCUSSes

(Robert Sparks) (was Discuss) No Objection

Comment (2010-03-11)
No email
send info
The text should acknowledge that applications using RTP are really at the mercy of what their underlying UDP implementation (for the current majority of RTP users anyway) chooses to do with this recommendation.

(Sean Turner) (was Discuss) No Objection

Comment (2010-04-13 for -)
No email
send info
The authors should also consult Pasi's COMMENT position to address SECDIR review provided by Charlie Kaufman.