Recommendations for Transport-Protocol Port Randomization
draft-ietf-tsvwg-port-randomization-09

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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"?

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

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

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

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

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

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