Recommendations for Transport-Protocol Port Randomization
draft-ietf-tsvwg-port-randomization-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
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 |
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 |