Skip to main content

Recommendations for Transport-Protocol Port Randomization
RFC 6056

Revision differences

Document history

Date Rev. By Action
2020-01-21
09 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2015-10-14
09 (System) Notify list changed from tsvwg-chairs@ietf.org, draft-ietf-tsvwg-port-randomization@ietf.org to (None)
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Robert Sparks
2012-08-22
09 (System) post-migration administrative database adjustment to the Yes position for Jari Arkko
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for David Harrington
2011-01-19
09 Amy Vezza State changed to RFC Published from RFC Ed Queue.
RFC 6056
BCP 156
2011-01-18
09 (System) RFC published
2010-08-20
09 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2010-08-20
09 (System) IANA Action state changed to No IC from In Progress
2010-08-20
09 (System) IANA Action state changed to In Progress
2010-08-20
09 Amy Vezza IESG state changed to Approved-announcement sent
2010-08-20
09 Amy Vezza IESG has approved the document
2010-08-20
09 Amy Vezza Closed "Approve" ballot
2010-08-19
09 Lars Eggert State changed to Approved-announcement to be sent from IESG Evaluation - Defer::AD Followup by Lars Eggert
2010-08-19
09 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Discuss by Tim Polk
2010-08-15
09 Robert Sparks [Ballot Position Update] Position for Robert Sparks has been changed to No Objection from Discuss by Robert Sparks
2010-08-15
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-08-15
09 (System) New version available: draft-ietf-tsvwg-port-randomization-09.txt
2010-06-21
09 Lars Eggert State Changes to IESG Evaluation - Defer::Revised ID Needed from IESG Evaluation - Defer::AD Followup by Lars Eggert
2010-06-07
09 David Harrington [Ballot Position Update] Position for David Harrington has been changed to No Objection from Discuss by David Harrington
2010-05-31
09 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to Yes from Discuss by Jari Arkko
2010-05-31
08 (System) New version available: draft-ietf-tsvwg-port-randomization-08.txt
2010-04-13
09 Tim Polk [Ballot comment]
2010-04-13
09 Tim Polk
[Ballot discuss]
This is a revised discuss, eliminating issues previously addressed and restating/clarifying those that have not been addressed

(1) Section 3.2 states that "ephemeral …
[Ballot discuss]
This is a revised discuss, eliminating issues previously addressed and restating/clarifying those that have not been addressed

(1) Section 3.2 states that "ephemeral port selection algorithms should use the whole range 1024-49151."  The following paragraph notes that this range includes assigned ports so "this may not be possible".  This implies that the assigned ports SHOULD NOT be used, but it is my understanding that only assigned ports in use on this host need be avoided.  This is important, since a very significant number of ports in the range 1024-49151 have been assigned, and some of the algorithms presented in the document behave very poorly with large numbers of eliminated ports. This is especially true if the set of ports that cannot be used include long seqeunces of consecutively numbered ports.

The second paragraph in 3.2 needs to be revised to better explain which of the set of IANA registered ports should be made available for ephemeral port selection.

(2) If a large number of the IANA registered ports are NOT available for ephemeral port selection, algorithm #1 is heavily biased towards the first available port after a sequence of unavailable port numbers.

Consider port 1491, which is unassigned.  1027 is the next smallest unassigned port.  Assuming all the IANA assigned ports from
1028 through 1490 are not available, and a min_epehemeral of 1024, any value of (random() % num_ephemeral) in the range 4..466 will result in selection of port 1491.  If next_ephemeral has a uniform distribution, port 1491 is 473 times more likely to be selected by algorithm #1 than a value in the dynamic ports range.

If I was an attacker, I would start by guessing port 1491.

I would strongly discourage using algorithm #1 unless only a very small number of IANA assigned ports are excluded from selection.
2010-04-13
09 Sean Turner [Ballot comment]
The authors should also consult Pasi's COMMENT position to address SECDIR review provided by Charlie Kaufman.
2010-04-13
09 Sean Turner [Ballot discuss]
2010-04-13
09 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss by Sean Turner
2010-04-12
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-04-12
07 (System) New version available: draft-ietf-tsvwg-port-randomization-07.txt
2010-04-09
09 David Harrington
[Ballot discuss]
Section 4.

If this document is supposed to make recommendations on NAT behavior I think it
needs to discuss when it makes sense …
[Ballot discuss]
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.
2010-04-09
09 David Harrington [Ballot Position Update] New position, Discuss, has been recorded by David Harrington
2010-04-08
09 Sean Turner
[Ballot discuss]
I am picking up Pasi's DISCUSS on this document. The authors should also consult Pasi's COMMENT positions to address the SECDIR review provided …
[Ballot discuss]
I am picking up Pasi's DISCUSS on this document. The authors should also consult Pasi's COMMENT positions to address the SECDIR review provided by Charlie Kaufman.

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).
2010-04-08
09 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded by Sean Turner
2010-03-11
09 Cindy Morgan State Changes to IESG Evaluation - Defer::Revised ID Needed from IESG Evaluation - Defer by Cindy Morgan
2010-03-11
09 Robert Sparks
[Ballot comment]
The text should acknowledge that applications using RTP are really at the mercy of what their underlying UDP implementation (for the current majority …
[Ballot comment]
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.
2010-03-11
09 Robert Sparks
[Ballot discuss]
Before suggesting that NATs follow the recommendations in this
document, there should be more discussion of the impact of the
recommendations on deployed …
[Ballot discuss]
Before suggesting that NATs follow the recommendations in this
document, there should be more discussion of the impact of the
recommendations on deployed systems using symmetric RTP/RTCP
that expect sequential binding.
2010-03-11
09 Adrian Farrel
[Ballot comment]
It is interesting that Algorithms 1, 3, and 4 statistically favor port
numbers one greater than allocated port numbers. But probably not worth …
[Ballot comment]
It is interesting that Algorithms 1, 3, and 4 statistically favor port
numbers one greater than allocated port numbers. But probably not worth
noting.
2010-03-05
09 (System) Removed from agenda for telechat - 2010-03-04
2010-03-04
09 Cullen Jennings State Changes to IESG Evaluation - Defer from IESG Evaluation by Cullen Jennings
2010-03-04
09 Cullen Jennings
[Ballot comment]
For the IESG more than the authors .... My current understanding of BCP would imply this should be a PS that update TCP, …
[Ballot comment]
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.
2010-03-04
09 Cullen Jennings
[Ballot discuss]
One other issues that got raised was would it be possible to give advice about getting initial randomness. Perhaps pointers to other RFC. …
[Ballot discuss]
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.
2010-03-04
09 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2010-03-04
09 Jari Arkko
[Ballot comment]
The document says:

  As mentioned in Section 2.1, the dynamic ports consist of the range
  49152-65535.  However, ephemeral port selection algorithms …
[Ballot comment]
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.
2010-03-04
09 Jari Arkko
[Ballot discuss]
This is a good and much needed document, thanks for writing it. I
did have one issue, however. Perhaps I'm missing something but …
[Ballot discuss]
This is a good and much needed document, thanks for writing it. I
did have one issue, however. Perhaps I'm missing something but the
document first says:

  Port numbers that are currently in use by a TCP in the LISTEN state
  should not be allowed for use as ephemeral ports.

but then later the algorithms say:

          if(resulting five-tuple is unique)
                  return next_ephemeral;

This does not appear to be sufficient to prevent the use of a
port in the LISTEN state. The if statement simply checks whether
there's an open connection between this host and some other specific
host. It does NOT check whether there could in the future be a
connection between this host and the specific host. If we are
opening a connection for application X between hosts A and B,
you cannot choose a port that another application Y is already
listening on host A. Even if A and B at the moment are not having
an open connection for application Y between them.
2010-03-04
09 Russ Housley
[Ballot comment]
Since we are trying to replace the TCP MD5 signature option [RFC2385]
  with TCP AO, it seems like a bad …
[Ballot comment]
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.
2010-03-04
09 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2010-03-04
09 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2010-03-04
09 Jari Arkko
[Ballot comment]
The document says:

  As mentioned in Section 2.1, the dynamic ports consist of the range
  49152-65535.  However, ephemeral port selection algorithms …
[Ballot comment]
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.
2010-03-04
09 Dan Romascanu [Ballot comment]
I support the issues raised by Pasi, Robert and Tim in their DISCUSSes
2010-03-04
09 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2010-03-03
09 Cullen Jennings
[Ballot comment]
For the IESG more than the authors .... My current understanding of BCP would imply this should be a PS that update TCP, …
[Ballot comment]
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.
2010-03-03
09 Cullen Jennings
[Ballot discuss]
This is a very long discuss and many of the appoints in are purely asking we certain attacks considered. It's perfectly reasonable to …
[Ballot discuss]
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.
2010-03-03
09 Magnus Westerlund
[Ballot discuss]
Section 4.

If this document is supposed to make recommendations on NAT behavior I think it needs to discuss when it makes sense …
[Ballot discuss]
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.
2010-03-03
09 Cullen Jennings [Ballot Position Update] New position, Discuss, has been recorded by Cullen Jennings
2010-03-03
09 Magnus Westerlund [Ballot Position Update] New position, Discuss, has been recorded by Magnus Westerlund
2010-03-03
09 Robert Sparks
[Ballot comment]
The text should acknowledge that applications using RTP are really at the mercy of what their underlying UDP implementation (for the current majority …
[Ballot comment]
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.
2010-03-03
09 Robert Sparks
[Ballot discuss]
Before suggesting that NATs follow the recommendations in this
document, there should be more discussion of the impact of the
recommendations on deployed …
[Ballot discuss]
Before suggesting that NATs follow the recommendations in this
document, there should be more discussion of the impact of the
recommendations on deployed systems using symmetric RTP/RTCP
that expect sequential binding.
2010-03-03
09 Robert Sparks [Ballot Position Update] New position, Discuss, has been recorded by Robert Sparks
2010-03-03
09 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Charlie Kaufman.
2010-03-03
09 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms
2010-03-03
09 Ralph Droms
[Ballot comment]
I think there needs to be some text between this text in section 2.1:

  The dynamic port range defined by IANA consists …
[Ballot comment]
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.
2010-03-03
09 Adrian Farrel
[Ballot comment]
It is interesting that Algorithms 1, 3, and 4 statistically favor port
numbers one greater than allocated port numbers. But probably not worth …
[Ballot comment]
It is interesting that Algorithms 1, 3, and 4 statistically favor port
numbers one greater than allocated port numbers. But probably not worth
noting.
2010-03-03
09 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel
2010-03-02
09 Ron Bonica [Ballot comment]
I support Tim's discuss regarding port range selection.
2010-03-02
09 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2010-03-02
09 Lars Eggert State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Lars Eggert
2010-03-02
09 Pasi Eronen [Ballot comment]
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.
2010-03-02
09 Pasi Eronen
[Ballot discuss]
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:

- …
[Ballot discuss]
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).
2010-03-02
09 Pasi Eronen [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen
2010-03-02
09 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2010-03-01
09 Tim Polk
[Ballot comment]
section 3.1, final paragraph
s/DCCP is not affected is not affected/DCCP is not affected/

Section 3.2 states:
  As mentioned in Section 2.1, …
[Ballot comment]
section 3.1, final paragraph
s/DCCP is not affected is not affected/DCCP is not affected/

Section 3.2 states:
  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.

Shouldn't the whole range be "1024-65535"?
2010-03-01
09 Tim Polk
[Ballot discuss]
There are a couple of issues I would like to discuss before moving to No Object for this
document...

(1) Section 3.2 states …
[Ballot discuss]
There are a couple of issues I would like to discuss before moving to No Object for this
document...

(1) Section 3.2 states that "ephemeral port selection algorithms should use the whole range
1024-49151."  [As noted in the comment section, I believe that 49151 should be 65535.]
I get the concept of using the largest possible range, but this seems to violate the spirit of
RFC 4340, among others. 

The following paragraph notes that this range includes assigned ports so "this may not be
possible".  Upon review, a very significant number of ports in the range 1024-49151 have
been assigned. I would like to understand how to determine which of the set of IANA
registered ports should be made available for ephemeral port selection.

(2) There are issues with the computation of next_ephemeral in Algorithm #1
which will skew the selected.  While the impact of this issue in isolation is relatively
minor, the fix is very straightforward.  (See follow up email.)

(3) Depending upon which IANA registered ports are available for ephemeral port selection,
issues 1 and 2 in combination with algorithm #1 can create a situation where certain ports
in the range 1024-49151 are significantly more likely to be selected.  (See follow up email.)
2010-03-01
09 Tim Polk
[Ballot comment]
section 3.1, final paragraph
s/DCCP is not affected is not affected/DCCP is not affected/

Section 3.2 states:
  As mentioned in Section 2.1, …
[Ballot comment]
section 3.1, final paragraph
s/DCCP is not affected is not affected/DCCP is not affected/

Section 3.2 states:
  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.

Shouldn't the whole range be "1024-65535"?

Section 3.3.1
The range of values returned by random() exceeds num_ephemeral values, so
random() % num_ephemeral does not provide a even distribution.
2010-03-01
09 Tim Polk
[Ballot discuss]
There are a couple of issues I would like to discuss before moving to No Object for this
document...

(1) Section 3.2 states …
[Ballot discuss]
There are a couple of issues I would like to discuss before moving to No Object for this
document...

(1) Section 3.2 states that "ephemeral port selection algorithms should use the whole range
1024-49151."  [As noted in the comment section, I believe that 49151 should be 65535.]
I get the concept of using the largest possible range, but this seems to violate the spirit of
RFC 4340, among others. 

The following paragraph notes that this range includes assigned ports so "this may not be
possible".  Upon review, a very significant number of ports in the range 1024-49151 have
been assigned. I would like to understand how to determine which of the set of IANA
registered ports should be made available for ephemeral port selection.

(2) There are issues with the computation of next_ephemeral in Algorithm #1
which will skewing the results.  While the impact of this issue in isolation is relatively
minor, the fix is very straightforward.  (See follow up email.)

(3) Depending upon which IANA registered ports are available for ephemeral port selection,
issues 1 and 2 in combination with algorithm #1 can create a situation where certain ports
in the range 1024-49151 are significantly more likely to be selected.  (See follow up email.)
2010-03-01
09 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2010-03-01
09 Tim Polk
[Ballot comment]
section 3.1, final paragraph
s/DCCP is not affected is not affected/DCCP is not affected/

Section 3.2 states:
  As mentioned in Section 2.1, …
[Ballot comment]
section 3.1, final paragraph
s/DCCP is not affected is not affected/DCCP is not affected/

Section 3.2 states:
  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.

Shouldn't the whole range be "1024-65535"?

Section 3.3.1
The range of values returned by random() exceeds num_ephemeral values, so
random() % num_ephemeral does not provide a even distribution.
2010-03-01
09 Tim Polk
[Ballot comment]
section 3.1, final paragraph
s/DCCP is not affected is not affected/DCCP is not affected/

Section 3.2 states:
  As mentioned in Section 2.1, …
[Ballot comment]
section 3.1, final paragraph
s/DCCP is not affected is not affected/DCCP is not affected/

Section 3.2 states:
  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.

Shouldn't the whole range be "1024-65535"?

Section 3.3.1
The range of values returned by random() exceeds num_ephemeral values, so
random() % num_ephemeral does not provide a even distribution.
2010-02-27
09 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov
2010-02-23
09 Amanda Baber IANA comments:

As described in the IANA Considerations section, we understand this
document to have NO IANA Actions.
2010-02-20
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Charlie Kaufman
2010-02-20
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Charlie Kaufman
2010-02-16
09 Amy Vezza Last call sent
2010-02-16
09 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2010-02-15
09 Lars Eggert Placed on agenda for telechat - 2010-03-04 by Lars Eggert
2010-02-15
09 Lars Eggert [Note]: 'James Polk (jmpolk@cisco.com) is the Document Shepherd.' added by Lars Eggert
2010-02-15
09 Lars Eggert [Ballot Position Update] New position, Yes, has been recorded for Lars Eggert
2010-02-15
09 Lars Eggert Ballot has been issued by Lars Eggert
2010-02-15
09 Lars Eggert Created "Approve" ballot
2010-02-15
09 Lars Eggert Last Call was requested by Lars Eggert
2010-02-15
09 (System) Ballot writeup text was added
2010-02-15
09 (System) Last call text was added
2010-02-15
09 (System) Ballot approval text was added
2010-02-15
09 Lars Eggert State Changes to Last Call Requested from AD Evaluation::AD Followup by Lars Eggert
2010-02-15
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-02-15
06 (System) New version available: draft-ietf-tsvwg-port-randomization-06.txt
2009-12-04
09 Lars Eggert State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Lars Eggert
2009-12-04
09 Lars Eggert State Changes to AD Evaluation from Publication Requested by Lars Eggert
2009-12-04
09 Cindy Morgan [Note]: 'James Polk (jmpolk@cisco.com) is the Document Shepherd.' added by Cindy Morgan
2009-12-04
09 Cindy Morgan
  (1.a) Who is the Document Shepherd for this document? Has the
          Document Shepherd personally reviewed this version of the …
  (1.a) Who is the Document Shepherd for this document? Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

James Polk  is the Document Shepherd. I have
reviewed this version of the document, and believe this is ready to
forward to the IESG for publication.

  (1.b) Has the document had adequate review both from key WG members
          and from key non-WG members? Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

Yes, key members of the WG have reviewed this document.

Key non-members of this WG are: TCPM WG did a WGLC on this document
as well, and voiced support for this document's progression.

There are no concerns with this -05 version of this document.

  (1.c) Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

No, I do not have concerns about this document progressing forward.

  (1.d) Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of? For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it. In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here. Has an IPR disclosure related to this document
          been filed? If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

No, there are no additional concerns - unless someone takes issue
with the document name including "randomization" in it, thinking this
could describe a literal randomization of numbering. The document
makes it pretty clear up front that this document is really about
obfuscation, and not real randomization. There is no declared IPR
with respect to this document.

  (1.e) How solid is the WG consensus behind this document? Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

There is WG consensus around this document, with others being silent.
The nature of TSVWG is an open area WG, with 6 primary topics of
interest; very few efforts ever get 'strong' WG consensus. That said,
consensus was solidly behind this document. This doc has been
reviewed by many people.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
          discontent? If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director. (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No, there was never any threat of appeal wrt this document.

  (1.g) Has the Document Shepherd personally verified that the
          document satisfies all ID nits? (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough. Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews? If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

I have verified the 1 warning (lacking a disclaimer for pre-RFC5378
work) is ok with the editors.

  (1.h) Has the document split its references into normative and
          informative? Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state? If such normative references exist, what is the
          strategy for their completion? Are there normative references
          that are downward references, as described in [RFC3967]? If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The references are split. All normative references are RFCs.

  (1.i) Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document? If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries? Are the IANA registries clearly identified? If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations? Does it suggest a
          reasonable name for the new registry? See [RFC2434]. If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

The IANA considerations section exists, however - this document does
not register anything, therefore this section can be removed by the
RFC-Editor during publication processing.

  (1.j) Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

No, the 5-6 small examples of code in this document (each 5-10 lines)
have not been verified as being good, valid code. Everything else has
been verified for this item.

  (1.k) The IESG approval announcement includes a Document
          Announcement Write-Up. Please provide such a Document
          Announcement Write-Up. Recent examples can be found in the
          "Action" announcements for approved documents. The approval
          announcement contains the following sections:

          Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document. If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

  Recently, awareness has been raised about a number of "blind" attacks
  that can be performed against the Transmission Control Protocol (TCP)
  and similar protocols. The consequences of these attacks range from
  throughput-reduction to broken connections or data corruption. These
  attacks rely on the attacker's ability to guess or know the five-
  tuple (Protocol, Source Address, Destination Address, Source Port,
  Destination Port) that identifies the transport protocol instance to
  be attacked. This document describes a number of simple and
  efficient methods for the selection of the client port number, such
  that the possibility of an attacker guessing the exact value is
  reduced. While this is not a replacement for cryptographic methods
  for protecting the connection, the described port number obfuscation
  algorithms provide improved security/obfuscation with very little
  effort and without any key management overhead. The algorithms
  described in this document are local policies that may be
  incrementally deployed, and that do not violate the specifications of
  any of the transport protocols that may benefit from them, such as
  TCP, UDP, UDP-lite, SCTP, DCCP, and RTP.

          Working Group Summary
            Was there anything in the WG process that is worth noting?
            For example, was there controversy about particular points
            or were there decisions where the consensus was
            particularly rough?

Understanding that 'strong' consensus is nearly impossible in an open
area WG such as TSVWG, with 5-6 sub-groups within this WG divided
along technology focuses -- there is unwavering consensus in the WG
amongst interested parties to publish this document. It has been
reviewed by several people in the WG last call. Comments raised have
been addressed.

          Document Quality
            Are there existing implementations of the protocol? Have a
            significant number of vendors indicated their plan to
            implement the specification? Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues? If
            there was a MIB Doctor, Media Type, or other Expert Review,
            what was its course (briefly)? In the case of a Media Type
            Review, on what date was the request posted?

From the appendix at the end of the ID:

Appendix A. Survey of the algorithms in use by some popular
            implementations

A.1. FreeBSD

  FreeBSD implements Algorithm 1, and in response to this document now
  uses a 'min_port' of 10000 and a 'max_port' of 65535. [FreeBSD]

A.2. Linux

  Linux implements Algorithm 3. If the algorithm is faced with the
  corner-case scenario described in Section 3.5, Algorithm 1 is used
  instead [Linux].

A.3. NetBSD

  NetBSD does not obfuscate its ephemeral port numbers. It selects
  ephemeral port numbers from the range 49152-65535, starting from port
  65535, and decreasing the port number for each ephemeral port number
  selected [NetBSD].

A.4. OpenBSD

  OpenBSD implements Algorithm 1, with a 'min_port' of 1024 and a
  'max_port' of 49151. [OpenBSD]

A.5. OpenSolaris

  OpenSolaris implements Algorithm 1, with a 'min_port' of 32768 and a
  'max_port' of 65535. [OpenSolaris]

          Personnel
            Who is the Document Shepherd for this document? Who is the
            Responsible Area Director? If the document requires IANA
            experts(s), insert 'The IANA Expert(s) for the registries
            in this document are .'

James Polk is the document Shepherd. Magnus Westerlund is the
responsible Area Director. There is no IANA registrations specified
by this document.
2009-12-04
09 Cindy Morgan Earlier history may be found in the Comment Log for draft-larsen-tsvwg-port-randomization.
2009-12-01
05 (System) New version available: draft-ietf-tsvwg-port-randomization-05.txt
2009-07-02
04 (System) New version available: draft-ietf-tsvwg-port-randomization-04.txt
2009-03-12
03 (System) New version available: draft-ietf-tsvwg-port-randomization-03.txt
2008-08-31
02 (System) New version available: draft-ietf-tsvwg-port-randomization-02.txt
2008-02-25
01 (System) New version available: draft-ietf-tsvwg-port-randomization-01.txt
2007-12-14
09 (System) Earlier history may be found in the Comment Log for draft-larsen-tsvwg-port-randomization.
2007-12-14
09 (System) Draft Added by the IESG Secretary in state 0.  by system
2007-12-06
00 (System) New version available: draft-ietf-tsvwg-port-randomization-00.txt