Recommendations on Using Assigned Transport Port Numbers
RFC 7605
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2020-01-21
|
11 | (System) | Received changes through RFC Editor sync (added Verified Errata tag) |
|
2015-10-14
|
11 | (System) | Notify list changed from tsvwg-chairs@ietf.org, draft-ietf-tsvwg-port-use@ietf.org to (None) |
|
2015-08-07
|
11 | (System) | RFC published |
|
2015-08-04
|
11 | (System) | RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7605">AUTH48-DONE</a> from AUTH48 |
|
2015-07-20
|
11 | (System) | RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7605">AUTH48</a> from RFC-EDITOR |
|
2015-07-12
|
11 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
|
2015-05-04
|
11 | Cindy Morgan | IESG state changed to RFC Ed Queue from Approved-announcement sent |
|
2015-05-04
|
11 | (System) | RFC Editor state changed to EDIT |
|
2015-05-04
|
11 | (System) | Announcement was received by RFC Editor |
|
2015-05-04
|
11 | (System) | IANA Action state changed to No IC from In Progress |
|
2015-05-04
|
11 | (System) | IANA Action state changed to In Progress |
|
2015-05-04
|
11 | Amy Vezza | IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup |
|
2015-05-04
|
11 | Amy Vezza | IESG has approved the document |
|
2015-05-04
|
11 | Amy Vezza | Closed "Approve" ballot |
|
2015-05-04
|
11 | Amy Vezza | Ballot approval text was generated |
|
2015-05-04
|
11 | Amy Vezza | Ballot writeup was changed |
|
2015-04-24
|
11 | Alissa Cooper | [Ballot comment] Thanks for addressing my DISCUSS! --- I think I may have some overlapping comments with Barry, but I wrote this before I saw … [Ballot comment] Thanks for addressing my DISCUSS! --- I think I may have some overlapping comments with Barry, but I wrote this before I saw his comments, so my apologies. -- Sec 5: "Port numbers can also be useful for other purposes." I would suggest s/useful/used/ because whether the purposes listed in the previous paragraph (e.g., monitoring, blocking, etc. based on port number) are considered "useful" is in the eye of the beholder. -- Sec 7.4: The term "security" is really vague. It would help to define what is meant by "security" or "secure service." -- Sec 7.4 and 7.5: Both of these sections contain recommendations that are good, but seem out of place in this document unless they could be made more specific to port use. The ones that jumped out at me are: >> New services SHOULD support security, either directly or via a secure transport such as TLS [RFC5246]. >> Insecure versions of new or existing secure services SHOULD be avoided because of the new vulnerability they create. >> Version support SHOULD be included in new services. I would say to either remove these or add in the context of what they have to do with port number assignment (e.g., "Version support SHOULD be included in new services rather than relying on different port number assignments for different versions.") -- Sec 7.7: "Deployments that use port numbers before deployment complicate IANA management of the port number space." I think this is supposed to say "before assignment" rather than "before deployment." -- Sec 7.8: ""Squatting" describes the use of a number from the assigned range in deployed software without IANA assignment. It is hazardous because IANA cannot track such usage and thus cannot avoid making legitimate assignments that conflict with such unauthorized usage. Such "squatted" port numbers remain unassigned, and IANA retains the right to assign them when requested by applicants." This is a little confusing -- is the first sentence supposed to say "unassigned range"? If not, what is the assigned range, and why is IANA said to retain the right to assign numbers that are already assigned? I would have thought squatting would be understood as using unassigned numbers in the system and user ranges. "In particular, any unassigned code from the assigned ranges will be assigned by IANA, and any conflict will be easily resolved as the protocol designer's fault once that happens (because they would not be the assignee). This may reflect in the public's judgment on the quality of their expertise and cooperation with the Internet community." This seems a little over-the-top to me. I would suggest: "IANA may assign any code from the system or user ranges to applicants that meet all of the relevant criteria, and is not obligated to take into consideration the existence of squatters when doing so. Squatting is viewed as uncooperative behavior in the Internet community." |
|
2015-04-24
|
11 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss |
|
2015-04-24
|
11 | Joseph Touch | New version available: draft-ietf-tsvwg-port-use-11.txt |
|
2015-03-30
|
10 | Kathleen Moriarty | [Ballot comment] Comments: Thanks for your work on this draft and addressing my and other ADs prior discusses and comments. I'll just leave the one … [Ballot comment] Comments: Thanks for your work on this draft and addressing my and other ADs prior discusses and comments. I'll just leave the one comment below as Alissa's discuss may not have been addressed yet. I'll be interested to see any new text on it. For what it's worth, I read 6.2 as informational background and think the text is helpful. Alissa has a discuss on this, so if the text is changed, I'd be interested to see what the suggested changes would be so that the draft still conveys the helpful information (which she was not opposed to in the discuss). I've configured hundreds of firewalls and what is described is what folks need to know when configuring such devices. Alternate port use can be used to get around rules you put in place and services like FTP in the old days would have used an FTP proxy and today that type of analysis on traffic to open the correct ports is called DPI. |
|
2015-03-30
|
10 | Kathleen Moriarty | [Ballot Position Update] Position for Kathleen Moriarty has been changed to No Objection from Discuss |
|
2015-03-25
|
10 | Joseph Touch | New version available: draft-ietf-tsvwg-port-use-10.txt |
|
2015-03-23
|
09 | Ted Lemon | [Ballot comment] Thanks for addressing my DISCUSS. This is an excellent document and I support publication. Thanks for doing this work--it's very complete and should … [Ballot comment] Thanks for addressing my DISCUSS. This is an excellent document and I support publication. Thanks for doing this work--it's very complete and should serve as a good guide for working groups designing new protocols. One additional comment, the new version has a change in section five resulting in the following text: This is the primary reason for requesting assigned port numbers assigned by IANA The double use of "assigned" here is likely to make the RFC editor want to change the text, so it might be nice to add a note explaining why this change was made so that that information isn't forgotten by the time this gets to the top of the editor queue. |
|
2015-03-23
|
09 | Ted Lemon | [Ballot Position Update] Position for Ted Lemon has been changed to Yes from Discuss |
|
2015-03-23
|
09 | Joseph Touch | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
|
2015-03-23
|
09 | Joseph Touch | New version available: draft-ietf-tsvwg-port-use-09.txt |
|
2015-03-19
|
08 | Kathleen Moriarty | [Ballot discuss] I'd like to see this worked out, so I'm changing back to discuss to see what happens with this conversation. This draft is … [Ballot discuss] I'd like to see this worked out, so I'm changing back to discuss to see what happens with this conversation. This draft is making a point claiming consensus on the security of one port versus two and I do not agree that the IETF has such agreement on consensus and do not agree that the referenced draft provides that. We showed a lack of consensus on the SecDir list and Ted Lemon provided a pointer to text in a newer RFC than the 15 year old one that Joe is referencing which states there is no consensus on this point. I'd like to see what results from discussions with the WG and would like to see the language changed. You may already have the few sentences queued up as a result of your response to the SecDir review: https://www.ietf.org/mail-archive/web/secdir/current/msg05422.html Essentially adding mention of DTLS and IPsec as options to secure sessions in addition to TLS. I do think the point Dan raised was good and appreciated your response, but this draft version is prior to that discussion. This is a placeholder to check for that text. If you have a version to look at, let me know and I'll peek at that one. |
|
2015-03-19
|
08 | Kathleen Moriarty | [Ballot comment] Comments: Thanks for your work on this draft. I do have some comments I'd like to chat about, but others already had discuss … [Ballot comment] Comments: Thanks for your work on this draft. I do have some comments I'd like to chat about, but others already had discuss items on a few of these, so I am either weighing in or providing suggestions to help resolve. For what it's worth, I read 6.2 as informational background and think the text is helpful. Alissa has a discuss on this, so if the text is changed, I'd be interested to see what the suggested changes would be so that the draft still conveys the helpful information (which she was not opposed to in the discuss). I've configured hundreds of firewalls and what is described is what folks need to know when configuring such devices. Alternate port use can be used to get around rules you put in place and services like FTP in the old days would have used an FTP proxy and today that type of analysis on traffic to open the correct ports is called DPI. The following "much debated" text was raised on the SAAG list by Stephen & I and so far there's no consensus for multiple ports. I'll update if there is, but I suspect there won't be. I do think that some changes to the text could be helpful and I'm not sure where to look for changes that happened from Barry's review... I am fine with the text Barry suggested to replace the first of the following two paragraphs and I don't think the second one is needed, perhaps deleting it as Barry's new text covers that enough. I just wasn't sure if that was already part of the updates in the works. o Separate port numbers are not intended for insecure versions of existing (or new) secure services. A service that already requires security would be made more vulnerable by having the same capability accessible without security. Note that the converse is different, i.e., it can be useful to create a new, secure service that replicates an existing insecure service on a new port number assignment. This can be necessary when the existing service is not backward-compatible with security enhancements, such as the use of TLS [RFC5246]. 7.4 - I'm fine with the text in this section discouraging the use of a second port for an insecure version of the protocol as we are pushing back on creating insecure versions anyway. Typically, this is all over one port with options to upgrade to increased security (encryption & authentication). I don't think this draft is the right place to go further than you already have, so I'm good with most of it. I think it was Alissa that raised a point on this sentence in the paragraph following the compliance bullets and I agree with it, so I suggest a change from: Either approach is currently permitted, although use of a single port number is consistent with port number conservation. To: Either approach is currently permitted. The second sentence of the paragraph after that should be deleted, leaving the argument just between performance and security. Delete: As discussed earlier, port numbers are a critical resource and it is inappropriate to consume assignments to increase performance. Thanks! |
|
2015-03-19
|
08 | Kathleen Moriarty | [Ballot Position Update] Position for Kathleen Moriarty has been changed to Discuss from Abstain |
|
2015-03-19
|
08 | Richard Barnes | [Ballot Position Update] Position for Richard Barnes has been changed to No Objection from Discuss |
|
2015-03-19
|
08 | Adrian Farrel | [Ballot comment] The most recent revision addresses the two remaining points from my Discuss. Thanks to the author for the (somewhat lengthy) discussion that resulted … [Ballot comment] The most recent revision addresses the two remaining points from my Discuss. Thanks to the author for the (somewhat lengthy) discussion that resulted in the changes. I have also reduced my list of Comments according to this most recent revision and our discussions. [Please recall that Comments are my voiced opinions, but are not mandatory. Please reach agreement with your AD on what needs to be done to the document.] --- I agree with Ted's Discuss about secure and insecure variants on different port numbers. RFC 6335 says Note: At the time of writing of this document, there is no IETF consensus on when it is appropriate to use a second port for an insecure version of a protocol. I don't see that Section 7.4 of this document has established that consensus, and I believe that there are good reasons to distinguish secure and insecure protocol versions (esepecially with legacy, insecure protocols) by use of separate port numbers. --- [This item removed from my Discuss] I think that the "guiding principle" in 6.1 that says... o Copies of an existing service can be differentiated by using different IP addresses, either on different hosts or as different real or virtual interfaces (or even operating systems) on the same host. ... describes an option, but it is wrong to suggest it as a solution. The main thrust of the document says that it is wrong to include a demultiplex reference at the transport layer when what is being multiplexed is really at the application layer (or at last at the level of the payload of the transport protocol). Yet this suggested remedy actually pushes the demultiplex identifier to the network layer. That really is not a good thing to recommend. ...Further to email discussion with the author, I think that this is describing a situation where copies of a host are being made, not copies of a service. It is not a significant Comment, but I feel that this bullet is distracting from the main list of suggested solution. |
|
2015-03-19
|
08 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss |
|
2015-03-18
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2015-03-18
|
08 | Cindy Morgan | New revision available |
|
2015-03-15
|
07 | Kathleen Moriarty | [Ballot comment] Reason for abstain: This draft is making a point claiming consensus on the security of one port versus two and I do not … [Ballot comment] Reason for abstain: This draft is making a point claiming consensus on the security of one port versus two and I do not agree that the IETF has such a statement on consensus. We showed this on the SecDir list and Ted Lemon provided a pointer to text in a newer RFC than the 15 year old one that Joe is referencing which states there is no consensus on this point. The editor doesn't seem to be budging or checking with the WG and scoping that advice to the WG only (as it is not IETF advice), even though 5 ADs disagree with him. Prior Discuss points, still should be checked in new version: You may already have the few sentences queued up as a result of your response to the SecDir review: https://www.ietf.org/mail-archive/web/secdir/current/msg05422.html Essentially adding mention of DTLS and IPsec as options to secure sessions in addition to TLS. I do think the point Dan raised was good and appreciated your response, but this draft version is prior to that discussion. This is a placeholder to check for that text. If you have a version to look at, let me know and I'll peek at that one. Comments: Thanks for your work on this draft. I do have some comments I'd like to chat about, but others already had discuss items on a few of these, so I am either weighing in or providing suggestions to help resolve. For what it's worth, I read 6.2 as informational background and think the text is helpful. Alissa has a discuss on this, so if the text is changed, I'd be interested to see what the suggested changes would be so that the draft still conveys the helpful information (which she was not opposed to in the discuss). I've configured hundreds of firewalls and what is described is what folks need to know when configuring such devices. Alternate port use can be used to get around rules you put in place and services like FTP in the old days would have used an FTP proxy and today that type of analysis on traffic to open the correct ports is called DPI. The following "much debated" text was raised on the SAAG list by Stephen & I and so far there's no consensus for multiple ports. I'll update if there is, but I suspect there won't be. I do think that some changes to the text could be helpful and I'm not sure where to look for changes that happened from Barry's review... I am fine with the text Barry suggested to replace the first of the following two paragraphs and I don't think the second one is needed, perhaps deleting it as Barry's new text covers that enough. I just wasn't sure if that was already part of the updates in the works. o Separate port numbers are not intended for insecure versions of existing (or new) secure services. A service that already requires security would be made more vulnerable by having the same capability accessible without security. Note that the converse is different, i.e., it can be useful to create a new, secure service that replicates an existing insecure service on a new port number assignment. This can be necessary when the existing service is not backward-compatible with security enhancements, such as the use of TLS [RFC5246]. 7.4 - I'm fine with the text in this section discouraging the use of a second port for an insecure version of the protocol as we are pushing back on creating insecure versions anyway. Typically, this is all over one port with options to upgrade to increased security (encryption & authentication). I don't think this draft is the right place to go further than you already have, so I'm good with most of it. I think it was Alissa that raised a point on this sentence in the paragraph following the compliance bullets and I agree with it, so I suggest a change from: Either approach is currently permitted, although use of a single port number is consistent with port number conservation. To: Either approach is currently permitted. The second sentence of the paragraph after that should be deleted, leaving the argument just between performance and security. Delete: As discussed earlier, port numbers are a critical resource and it is inappropriate to consume assignments to increase performance. Thanks! |
|
2015-03-15
|
07 | Kathleen Moriarty | [Ballot Position Update] Position for Kathleen Moriarty has been changed to Abstain from Discuss |
|
2015-03-05
|
07 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
|
2015-03-05
|
07 | Adrian Farrel | [Ballot discuss] [Updated to remove the middle of three points to the Comments section] Thanks for this work. I think it is helpful for authors … [Ballot discuss] [Updated to remove the middle of three points to the Comments section] Thanks for this work. I think it is helpful for authors and protocol designers to understand the way that the port experts approach this issue. But I have some concerns that I hope we can work out quite simply. --- I understand that the current situation with the number of free ports is in some respects due to the "policing" by the port experts. But I disagree that the situation is such a severe state that fierce rules are needed. And "compliance statements" are fierce rules not recommendations or guidance. Furthermore, this document brings to the fore the thin line between the opinions of the port experts and the opinions of the IETF community. If, for example, the community chooses (with appropriate discussion and consideration) to request IANA to allocate a port via an IETF consensus standards track document, I believe that request should be honored. Obviously the port experts should express their opinions as firmly as they hold them, and the TSV ADs may support their opinions, but I do not think that the port experts should ultimately be able to override the community consensus. I would appreciate it if this document made it clearer that the "rules" it defines are guidance only, and that exceptions may be made when there is community consensus to make such exceptions. --- Section 7.6 has >> Services SHOULD NOT use UDP as a performance enhancement over TCP, i.e., to circumnavigate TCP's congestion control. Is this a port use issue, or guidance about how to use transport protocols in a harmonious Internet? I think it is the latter and has no place in this document. |
|
2015-03-05
|
07 | Adrian Farrel | [Ballot comment] I appreciate that this document was sent for early cross-area review as noted in the shepherd write-up. It's a little disappointing that Routing … [Ballot comment] I appreciate that this document was sent for early cross-area review as noted in the shepherd write-up. It's a little disappointing that Routing wasn't included in that process given the recent interesting debates about the use of ports for indicating UDP tunnel payloads, and about ports for different types of BFD usage. Well, no point in bitching about that now. There was an IETF last call, and --- I agree with Ted's Discuss about secure and insecure variants on different port numbers. RFC 6335 says Note: At the time of writing of this document, there is no IETF consensus on when it is appropriate to use a second port for an insecure version of a protocol. I don't see that Section 7.4 of this document has established that consensus, and I believe that there are good reasons to distinguish secure and insecure protocol versions (esepecially with legacy, insecure protocols) by use of separate port numbers. Furthermore, Section 7.4 goes *way* beyond the scope of the document by stating how new "services" should be designed. Is it the place of this document to tell protocol designers what security they should put in their protocols? (It doesn't matter whether the advice is good or not, it seems unlikely that this section has been reviewed by people who believed that the document was only about recommendations for port number assignment and uses). [I almost made this a Discuss in it's own right, but I think it can piggy-back on Ted's Discuss.] --- Notwithstanding our disagreement about quite how critical conservation may be and how practical some of the principles in 6.1 are, I find the compliance requirement in Section 6 hard to parse. >> Each port requested MUST be justified as independently necessary. Could you explain or reword "independently necessary"? Independent of what? "Justified" by whom / to whom (I think that is more obvious, but it wouldn't hurt to spell it out). --- Section 7.6 has However, to conserve space and to reflect increasing use of other transports, assignments are now specific only to the transport being used. Can you clarify what space you are referring to? If this is text space on a web page, then this is not a particularly meaningful reason. --- Section 7.6 has >> Services SHOULD NOT use UDP as a performance enhancement over TCP, i.e., to circumnavigate TCP's congestion control. Is this a port use issue, or guidance about how to use transport protocols in a harmonious Internet? I think it is the latter and has no place in this document. --- Shouldn't Section 7.6 say something about the use of the same port number for different services with different transports? That is, you have that port xyz will only be registered for the transport protocols that service A uses. But you don't go on to say that port xyz having been registered for service A on transport protocol Z MUST NOT be registered for service B on transport protocol Y. --- Section 7.7 Deployments that use port numbers before deployment complicate IANA management of the port number space. Keep in mind that this I think s/before deployment/before assignment/ ---- [This item removed from my Discuss] I think that the "guiding principle" in 6.1 that says... o Copies of an existing service can be differentiated by using different IP addresses, either on different hosts or as different real or virtual interfaces (or even operating systems) on the same host. ... describes an option, but it is wrong to suggest it as a solution. The main thrust of the document says that it is wrong to include a demultiplex reference at the transport layer when what is being multiplexed is really at the application layer (or at last at the level of the payload of the transport protocol). Yet this suggested remedy actually pushes the demultiplex identifier to the network layer. That really is not a good thing to recommend. ...Further to email discussion with the author, I think that this is describing a situation where copies of a host are being made, not copies of a service. It is not a significant Comment, but I feel that this bullet is distracting from the main list of suggested solution. |
|
2015-03-05
|
07 | Adrian Farrel | Ballot comment and discuss text updated for Adrian Farrel |
|
2015-03-05
|
07 | Brian Haberman | [Ballot Position Update] Position for Brian Haberman has been changed to No Objection from No Record |
|
2015-03-05
|
07 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
|
2015-03-04
|
07 | Richard Barnes | [Ballot discuss] Some of the ">>" compliance points here are only marginally related to the subject matter, e.g.: ">> New services SHOULD support security, either … [Ballot discuss] Some of the ">>" compliance points here are only marginally related to the subject matter, e.g.: ">> New services SHOULD support security, either directly or via a secure transport such as TLS [RFC5246]." ">> UDP over IPv4 multi-host services SHOULD use multicast rather than broadcast." ">> Services SHOULD NOT use UDP as a performance enhancement over TCP, i.e., to circumnavigate TCP's congestion control." While these may be good things to say, they don't belong in this document. |
|
2015-03-04
|
07 | Richard Barnes | [Ballot comment] I share Alissa's comments that the rationale for conservation is a bit shaky. Clearly conservation is prudent, but it doesn't seem like there's … [Ballot comment] I share Alissa's comments that the rationale for conservation is a bit shaky. Clearly conservation is prudent, but it doesn't seem like there's a crisis here. Section 3: The values in the "Binary" column are decimal, as indeed they are labelled in RFC 758. Section 7.4: I agree with Stephen here. Separate ports and STARTTLS are equivalent from a security/downgrade POV -- either you need to know to use the secure port, or you need to know to require STARTTLS to succeed. The only difference is that STARTTLS adds latency if you're doing TLS. You can avoid that by starting secure (STOPTLS?), but in either case, there's a loser. But ISTM that the document addresses this point sufficiently. |
|
2015-03-04
|
07 | Richard Barnes | [Ballot Position Update] New position, Discuss, has been recorded for Richard Barnes |
|
2015-03-04
|
07 | Alia Atlas | [Ballot comment] I agree with Adrian's DISCUSS |
|
2015-03-04
|
07 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
|
2015-03-04
|
07 | Stephen Farrell | [Ballot comment] - I share the concern that this needs to be in-whack with RFC6335 but sometimes overstates things, e.g. some of the MUST NOTs … [Ballot comment] - I share the concern that this needs to be in-whack with RFC6335 but sometimes overstates things, e.g. some of the MUST NOTs in 7.7. I'm fine that that's being discussed already. - The one-port/two-port thing: I don't think there's a real seurity difference here in general, so that is not a basis on which to prefer to discourage the registration of two ports, nor is it a reason to prefer to do that. It is however, also reasonable to want two ports, one e.g. using TLS and one not, and it is equally reasonable to use STARTTLS. Basically, please move on, there's nothing to see here, find another argument:-) - I would like to see a statement that, in allocating a new port for a "secure" variant of an existing protocol, the port experts will consider actual deployment, even if it is the case that some RFC says that one can do security stuff on the currently assigned port. If we do not allocate such ports, then we would be getting in the way of improving real security, and that would be bad. I'm not sure from the text what the port experts do in such cases, but as that is not addressed by the current document, the RFC that results won't be a block on such allocations (where justified). - 7.8, "easily resolved" to be the squatter's fault is not true - in general people will I think consider the most widely deployed use of a port to be in the right, and most people won't even go look at the IANA registry. (Some will, including no doubt the port experts.) |
|
2015-03-04
|
07 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
|
2015-03-03
|
07 | Kathleen Moriarty | [Ballot discuss] You may already have the few sentences queued up as a result of your response to the SecDir review: https://www.ietf.org/mail-archive/web/secdir/current/msg05422.html Essentially adding mention … [Ballot discuss] You may already have the few sentences queued up as a result of your response to the SecDir review: https://www.ietf.org/mail-archive/web/secdir/current/msg05422.html Essentially adding mention of DTLS and IPsec as options to secure sessions in addition to TLS. I do think the point Dan raised was good and appreciated your response, but this draft version is prior to that discussion. This is a placeholder to check for that text. If you have a version to look at, let me know and I'll peek at that one. |
|
2015-03-03
|
07 | Kathleen Moriarty | [Ballot comment] Thanks for your work on this draft. I do have some comments I'd like to chat about, but others already had discuss items … [Ballot comment] Thanks for your work on this draft. I do have some comments I'd like to chat about, but others already had discuss items on a few of these, so I am either weighing in or providing suggestions to help resolve. For what it's worth, I read 6.2 as informational background and think the text is helpful. Alissa has a discuss on this, so if the text is changed, I'd be interested to see what the suggested changes would be so that the draft still conveys the helpful information (which she was not opposed to in the discuss). I've configured hundreds of firewalls and what is described is what folks need to know when configuring such devices. Alternate port use can be used to get around rules you put in place and services like FTP in the old days would have used an FTP proxy and today that type of analysis on traffic to open the correct ports is called DPI. The following "much debated" text was raised on the SAAG list by Stephen & I and so far there's no consensus for multiple ports. I'll update if there is, but I suspect there won't be. I do think that some changes to the text could be helpful and I'm not sure where to look for changes that happened from Barry's review... I am fine with the text Barry suggested to replace the first of the following two paragraphs and I don't think the second one is needed, perhaps deleting it as Barry's new text covers that enough. I just wasn't sure if that was already part of the updates in the works. o Separate port numbers are not intended for insecure versions of existing (or new) secure services. A service that already requires security would be made more vulnerable by having the same capability accessible without security. Note that the converse is different, i.e., it can be useful to create a new, secure service that replicates an existing insecure service on a new port number assignment. This can be necessary when the existing service is not backward-compatible with security enhancements, such as the use of TLS [RFC5246]. 7.4 - I'm fine with the text in this section discouraging the use of a second port for an insecure version of the protocol as we are pushing back on creating insecure versions anyway. Typically, this is all over one port with options to upgrade to increased security (encryption & authentication). I don't think this draft is the right place to go further than you already have, so I'm good with most of it. I think it was Alissa that raised a point on this sentence in the paragraph following the compliance bullets and I agree with it, so I suggest a change from: Either approach is currently permitted, although use of a single port number is consistent with port number conservation. To: Either approach is currently permitted. The second sentence of the paragraph after that should be deleted, leaving the argument just between performance and security. Delete: As discussed earlier, port numbers are a critical resource and it is inappropriate to consume assignments to increase performance. Thanks! |
|
2015-03-03
|
07 | Kathleen Moriarty | [Ballot Position Update] New position, Discuss, has been recorded for Kathleen Moriarty |
|
2015-02-28
|
07 | Adrian Farrel | [Ballot discuss] Thanks for this work. I think it is helpful for authors and protocol designers to understand the way that the port experts approach … [Ballot discuss] Thanks for this work. I think it is helpful for authors and protocol designers to understand the way that the port experts approach this issue. But I have some concerns that I hope we can work out quite simply. --- I understand that the current situation with the number of free ports is in some respects due to the "policing" by the port experts. But I disagree that the situation is such a severe state that fierce rules are needed. And "compliance statements" are fierce rules not recommendations or guidance. Furthermore, this document brings to the fore the thin line between the opinions of the port experts and the opinions of the IETF community. If, for example, the community chooses (with appropriate discussion and consideration) to request IANA to allocate a port via an IETF consensus standards track document, I believe that request should be honored. Obviously the port experts should express their opinions as firmly as they hold them, and the TSV ADs may support their opinions, but I do not think that the port experts should ultimately be able to override the community consensus. I would appreciate it if this document made it clearer that the "rules" it defines are guidance only, and that exceptions may be made when there is community consensus to make such exceptions. --- I think that the "guiding principle" in 6.1 that says... o Copies of an existing service can be differentiated by using different IP addresses, either on different hosts or as different real or virtual interfaces (or even operating systems) on the same host. ... describes an option, but it is wrong to suggest it as a solution. The main thrust of the document says that it is wrong to include a demultiplex reference at the transport layer when what is being multiplexed is really at the application layer (or at last at the level of the payload of the transport protocol). Yet this suggested remedy actually pushes the demultiplex identifier to the network layer. That really is not a good thing to recommend. --- Section 7.6 has >> Services SHOULD NOT use UDP as a performance enhancement over TCP, i.e., to circumnavigate TCP's congestion control. Is this a port use issue, or guidance about how to use transport protocols in a harmonious Internet? I think it is the latter and has no place in this document. |
|
2015-02-28
|
07 | Adrian Farrel | [Ballot comment] I appreciate that this document was sent for early cross-area review as noted in the shepherd write-up. It's a little disappointing that Routing … [Ballot comment] I appreciate that this document was sent for early cross-area review as noted in the shepherd write-up. It's a little disappointing that Routing wasn't included in that process given the recent interesting debates about the use of ports for indicating UDP tunnel payloads, and about ports for different types of BFD usage. Well, no point in bitching about that now. There was an IETF last call, and --- I agree with Ted's Discuss about secure and insecure variants on different port numbers. RFC 6335 says Note: At the time of writing of this document, there is no IETF consensus on when it is appropriate to use a second port for an insecure version of a protocol. I don't see that Section 7.4 of this document has established that consensus, and I believe that there are good reasons to distinguish secure and insecure protocol versions (esepecially with legacy, insecure protocols) by use of separate port numbers. Furthermore, Section 7.4 goes *way* beyond the scope of the document by stating how new "services" should be designed. Is it the place of this document to tell protocol designers what security they should put in their protocols? (It doesn't matter whether the advice is good or not, it seems unlikely that this section has been reviewed by people who believed that the document was only about recommendations for port number assignment and uses). [I almost made this a Discuss in it's own right, but I think it can piggy-back on Ted's Discuss.] --- Notwithstanding our disagreement about quite how critical conservation may be and how practical some of the principles in 6.1 are, I find the compliance requirement in Section 6 hard to parse. >> Each port requested MUST be justified as independently necessary. Could you explain or reword "independently necessary"? Independent of what? "Justified" by whom / to whom (I think that is more obvious, but it wouldn't hurt to spell it out). --- Section 7.6 has However, to conserve space and to reflect increasing use of other transports, assignments are now specific only to the transport being used. Can you clarify what space you are referring to? If this is text space on a web page, then this is not a particularly meaningful reason. --- Section 7.6 has >> Services SHOULD NOT use UDP as a performance enhancement over TCP, i.e., to circumnavigate TCP's congestion control. Is this a port use issue, or guidance about how to use transport protocols in a harmonious Internet? I think it is the latter and has no place in this document. --- Shouldn't Section 7.6 say something about the use of the same port number for different services with different transports? That is, you have that port xyz will only be registered for the transport protocols that service A uses. But you don't go on to say that port xyz having been registered for service A on transport protocol Z MUST NOT be registered for service B on transport protocol Y. --- Section 7.7 Deployments that use port numbers before deployment complicate IANA management of the port number space. Keep in mind that this I think s/before deployment/before assignment/ |
|
2015-02-28
|
07 | Adrian Farrel | [Ballot Position Update] New position, Discuss, has been recorded for Adrian Farrel |
|
2015-02-28
|
07 | Ted Lemon | [Ballot discuss] The -07 version of the document encourages the use of a single port for both secure and non-secure communication. I am concerned that … [Ballot discuss] The -07 version of the document encourages the use of a single port for both secure and non-secure communication. I am concerned that the outcome will be to encourage the use of mechanisms analogous to STARTTLS in future protocol specifications. A two-port secure/non-secure model is preferable to any mechanism that supports a downgrade attack: the port number signals that the connection must be secure, or is not expected to be secure. Barry raised a DISCUSS on this text, but unfortunately it looks like the conversation that followed did not fix the issue, and indeed may have made it worse. I am concerned that the document as written and with the proposed changes will lead protocol designers to rely on a single port for secure and non-secure communications in situations where this unavoidably exposes the communication to a man-in-the-middle downgrade attack. I would expect that pretty much any dual-use port would be subject to this risk: dependably preventing it is possible, but hard, and only possible if the thing that signals the initiator to connect to that port can securely indicate whether to use the secure or non-secure mode. I would therefore like to see the text emphasize this concern, rather than emphasizing the concern that if two ports are used, administrators will default to using the non-secure mode. I agree that this latter issue is a concern, but it is a concern for any protocol that allows a non-secure mode, whether it uses the port number to signal that or the signaling is done out of band. The only sense in which using a single port mitigates this concern is if the single port _only_ support secure, authenticated communication. An alternative would be to simply not take a position either way, but the text currently makes some good points about the tradeoffs, which would have to be lost in order to avoid taking a position, so I don't really want to encourage that solution. |
|
2015-02-28
|
07 | Ted Lemon | [Ballot comment] Overall this is an excellent document and I support publication: the DISCUSS I've entered should not be taken as an indication otherwise. Thanks … [Ballot comment] Overall this is an excellent document and I support publication: the DISCUSS I've entered should not be taken as an indication otherwise. Thanks for doing this--it's very complete and should serve as a good guide for working groups designing new protocols. |
|
2015-02-28
|
07 | Ted Lemon | [Ballot Position Update] New position, Discuss, has been recorded for Ted Lemon |
|
2015-02-17
|
07 | Spencer Dawkins | Telechat date has been changed to 2015-03-05 from 2015-02-19 |
|
2015-02-17
|
07 | Pete Resnick | [Ballot comment] Mostly for the IESG: I agree that this document does not update 6335. I agree that it is supplemental. And I agree that … [Ballot comment] Mostly for the IESG: I agree that this document does not update 6335. I agree that it is supplemental. And I agree that it's a BCP. So let's make it part of BCP165. This doesn't need a new BCP number. It's part of the same series. 1: A bit of clarification would be useful: OLD Note that this document provides information to potential port number applicants that complements the IANA process described in BCP165 [RFC6335], but it does not update that document. NEW Note that this document provides information to potential port number applicants that complements the IANA process described in BCP165 [RFC6335], but it does not change any of the port number assignment procedures described therein. I don't think you need to say anything about the "update" status. 2: In this document, the characters ">>" preceding an indented line(s) indicates a compliance requirement statement using the key words listed above. This convention aids reviewers in quickly identifying or finding the explicit compliance requirements of this RFC. Generally, this sort of things simply produces eye-rolling in me and nothing more. 2119 keywords are not about "compliance", and so to claim above that you are using them "as described in RFC-2119" and then go on to include them in "compliance requirements" is bogus. However, most of these "compliance requirements" in the rest of the document are simply summary advice regarding what's going to be useful and what won't, so really what's in the ">>" is not a "compliance requirement", but rather an "Important Summary Note". I'd really prefer you call them that here. That said, one of them in 7.4 actually gave me pause: >> When simultaneously requesting both a secure and an insecure port, strong justification MUST be provided for the insecure port. Precedent (citing other protocols that use an insecure port) is not strong justification by itself. A strong case for utility of the insecure service is REQUIRED for approval of the insecure port. Here it sounds like you *are* imposing a requirement, and it sure sounds to me like you're specifying a registration procedure to be enforced by the Designated Expert or IANA, not giving a piece of advice to the registrant. If it wasn't for the last sentence in the above, I wouldn't have thought twice about it. So my two suggestions are: - Change the text in section 2 to not call these "compliance requirements". If you don't like "Important Summary Note", choose something else. - Change or delete the last sentence in the paragraph from 7.4. (I think delete is fine; it's repetitive anyway.) 7.4/7.5: I agree with Alissa's comments regarding the ">>" statements. Either re-word them to be about port assignment or ditch them. |
|
2015-02-17
|
07 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
|
2015-02-17
|
07 | Alissa Cooper | [Ballot discuss] Thanks for writing this. Overall I agree with its conclusions. But the way that it reaches those conclusions seems lacking or misguided in … [Ballot discuss] Thanks for writing this. Overall I agree with its conclusions. But the way that it reaches those conclusions seems lacking or misguided in a couple of respects, so I'd like to discuss those. The document argues that port numbers should be conserved and gives basically three reasons why (my summary): 1. Port numbers are designed for a specific purpose and conservation helps maintain that specificity. 2. The port number space is smaller than other number spaces. 3. Because of firewall and NAT interactions. Reason (1) seems unobjectionable. Reason (2) is true, but it doesn't really offer a compelling argument in light of the pace of assignments to date. The document indicates that about 11% of the port number space has been allocated over several decades. Does that really create cause to worry about running out of space? Are we suddenly being flooded with port number requests? If the rate of assignments doubled or tripled, would we worry about running out of port numbers? Again, I'm not saying this isn't worth pointing out, but in terms of making a compelling argument to developers about the need to conserve port numbers, I don't think this works. That leaves reason (3), and in this case it seems like the document is making contradictory statements at times. On the one hand, many of the recommendations seem motivated by the fact that firewalls make judgments on the basis of port numbers, and therefore conservation makes firewall configuration easier and reduces application fragility that can arise from having some ports blocked. On the other hand, the document notes that port numbers should only be considered meaningful to endpoints and details some of the complications that arise when firewalls instead associate meaning to them. The message comes across as contradictory -- intermediaries are interpreting port numbers in all kinds of ways that they shouldn't, but we should take a conservative attitude towards port number assignment so that they can keep doing it. I think it's totally fine to represent the state of affairs when it comes to how firewalls treat ports. But if that treatment is in some ways a perversion of the motivation for having port numbers in the first place (and if it wreaks some havoc on application development/deployment, which it does), I don't think it's appropriate for us to publish a BCP that predicates its recommendations on that perversion. The upshot of these comments would result in some editing of sections 5 and 6, but I wanted to have the discussion before suggesting edits. |
|
2015-02-17
|
07 | Alissa Cooper | [Ballot comment] I think I may have some overlapping comments with Barry, but I wrote this before I saw his comments, so my apologies. -- … [Ballot comment] I think I may have some overlapping comments with Barry, but I wrote this before I saw his comments, so my apologies. -- Sec 5: "Port numbers can also be useful for other purposes." I would suggest s/useful/used/ because whether the purposes listed in the previous paragraph (e.g., monitoring, blocking, etc. based on port number) are considered "useful" is in the eye of the beholder. -- Sec 7.4: The term "security" is really vague. It would help to define what is meant by "security" or "secure service." -- Sec 7.4 and 7.5: Both of these sections contain recommendations that are good, but seem out of place in this document unless they could be made more specific to port use. The ones that jumped out at me are: >> New services SHOULD support security, either directly or via a secure transport such as TLS [RFC5246]. >> Insecure versions of new or existing secure services SHOULD be avoided because of the new vulnerability they create. >> Version support SHOULD be included in new services. I would say to either remove these or add in the context of what they have to do with port number assignment (e.g., "Version support SHOULD be included in new services rather than relying on different port number assignments for different versions.") -- Sec 7.7: "Deployments that use port numbers before deployment complicate IANA management of the port number space." I think this is supposed to say "before assignment" rather than "before deployment." -- Sec 7.8: ""Squatting" describes the use of a number from the assigned range in deployed software without IANA assignment. It is hazardous because IANA cannot track such usage and thus cannot avoid making legitimate assignments that conflict with such unauthorized usage. Such "squatted" port numbers remain unassigned, and IANA retains the right to assign them when requested by applicants." This is a little confusing -- is the first sentence supposed to say "unassigned range"? If not, what is the assigned range, and why is IANA said to retain the right to assign numbers that are already assigned? I would have thought squatting would be understood as using unassigned numbers in the system and user ranges. "In particular, any unassigned code from the assigned ranges will be assigned by IANA, and any conflict will be easily resolved as the protocol designer's fault once that happens (because they would not be the assignee). This may reflect in the public's judgment on the quality of their expertise and cooperation with the Internet community." This seems a little over-the-top to me. I would suggest: "IANA may assign any code from the system or user ranges to applicants that meet all of the relevant criteria, and is not obligated to take into consideration the existence of squatters when doing so. Squatting is viewed as uncooperative behavior in the Internet community." |
|
2015-02-17
|
07 | Alissa Cooper | [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper |
|
2015-02-17
|
07 | Dan Romascanu | Request for Telechat review by GENART Completed: Ready. Reviewer: Dan Romascanu. |
|
2015-02-17
|
07 | Martin Stiemerling | [Ballot comment] Thanks for writing this document! Just one nit: On page 6 in this paragraph: As a concept, a service is the combination … [Ballot comment] Thanks for writing this document! Just one nit: On page 6 in this paragraph: As a concept, a service is the combination of ISO Layers 5-7 that represents an application protocol capability. For example www (port number 80) is a service that uses HTTP as an application protocol and provides access to a web server [RFC7230]. However, it is possible to use HTTP for other purposes, such as command and control. This is why some current service names (HTTP, e.g.) are a bit overloaded - they describe not only the application protocol, but a particular service. This paragraph introduces the term „service names“ which has not been used before. It would be good to define the term in contrast to the port numbers for naive readers. The explanation of service names comes later, probably too late (just before the beginning of Section 6). How about introducing service names just before? |
|
2015-02-17
|
07 | Martin Stiemerling | [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling |
|
2015-02-17
|
07 | Barry Leiba | [Ballot comment] Thanks for quickly addressing my DISCUSS points, two of which are cleared and two of which are now comments here: -- Section 7.4 … [Ballot comment] Thanks for quickly addressing my DISCUSS points, two of which are cleared and two of which are now comments here: -- Section 7.4 -- >> New services SHOULD support security, either directly or via a secure transport such as TLS [RFC5246]. In this context, "security" is too vague a term: what, exactly, does "SHOULD support security" mean? Are you talking about authentication? Access/authorization controls? Confidentiality? Specifically, encrypted communication? I think you mean the last. << Joe Touch responds: It would be useful to explain. Security depends on the service being offered; for some, encryption, integrity protection, and source identity are all expected, but for many services only a subset of these might be relevant. >> We should add such an explanation. -- Section 7.4 -- >> When simultaneously requesting both a secure and an insecure port, strong justification MUST be provided for the insecure port. Precedent (citing other protocols that use an insecure port) is not strong justification by itself. A strong case for utility of the insecure service is REQUIRED for approval of the insecure port. This seems significantly stronger than what RFC 6335 said, and this point was hotly debated in the development of that document. RFC 6335, Section 9, says this: Services are expected to include support for security, either as default or dynamically negotiated in-band. The use of separate service name or port number assignments for secure and insecure variants of the same service is to be avoided in order to discourage the deployment of insecure services. As this document does not update 6335, I don't see how the MUST and the REQUIRED are appropriate. But perhaps I can be convinced by some discussion. Joe Touch responds: << Again, one doc applies to IANA, the other to protocol designers. RFC6335 explains why IANA should avoid such an assignment; this doc explains that a designer is expected to justify the need in an request to IANA. It might be useful, as a result, to remove the 2119 language, e.g., to write this from the perspective of advice to the applicant: >> When simultaneously requesting both a secure and an insecure port, strong justification is expected for the utility and safety of a separate insecure port. Precedent (citing other protocols that use an insecure port) is not strong justification by itself. >> The rest of these are non-blocking, but please consider them -- many are meant to clarify the text, and I hope they succeed in that. In three places: -- Abstract -- This document provides recommendations to application and service designers on how to use the transport protocol port number space. -- Section 1 -- It also provides specific recommendations to designers on how to use assigned port numbers. -- Section 2 -- In this document, the characters ">>" preceding an indented line(s) indicates a compliance requirement statement using the key words listed above. First, recommendations on how to use *port number space* is not the same as recommendations on how to use *assigned port numbers*. I interpret the former as recommendations about making requests for port numbers, and the latter as recommendations about use of the port numbers after they've been assigned. These should be worded consistently. Second, recommendations, whichever type of recommendations they be, are not the same as compliance requirements. I read the former as suggestions, and the latter as, well, requirements. If the document is giving requirements that cover port-number requests -- and it is, complete with MUSTs -- it needs to clearly say that up front, and get rid of the "recommendations" stuff (or say both, that there are both requirements and recommendations here). -- Section 5 -- Consider a user wanting to run a web server. That service could run on any port number, provided that all clients knew what port number to use to access that service at that host. Such information can be distributed out-of-band, e.g., in the URI: http://www.example.com:51509/ It's a fine point, but having the port number in the URI doesn't actually distribute it "out of band" (which doesn't need hyphens in this context). I would say, "Such information can be explicitly distributed -- for example, by putting it in the URI:". IANA assigns port numbers so that Internet endpoints do not need pairwise, explicit coordination of the meaning of their port numbers. This is the primary reason for requesting assigned port numbers with IANA - to have a common agreement between all endpoints on the Internet as to the default meaning of a port number. This only says half of it, and omits a very important piece, I think. May I suggest this?: NEW IANA assigns port numbers so that Internet endpoints do not need pairwise, explicit coordination of the meaning of their port numbers. This is the primary reason for requesting assigned port numbers with IANA - to have a common agreement between all endpoints on the Internet as to the default meaning of a port number, and to provide the endpoints with a default port number for a particular protocol or service. END >> Each port requested MUST be justified as independently necessary. This is a fair statement, and yet I worry that including "necessary" may result in arguments between protocol designers and port experts about what is and isn't "necessary", and what the community's consensus is on it. I'm not sure how to minimize that. I'd say "MUST be independently justified," which does get the point you want (the independent justification) without using the loaded word "necessary". I'd prefer that wording, though I admit that it can just as easily result in the same arguments. -- Section 6.1 -- o Copies of an existing service can be differentiated by using different IP addresses, either on different hosts or as different real or virtual interfaces (or even operating systems) on the same host. As a guiding principle for protocol designers, this worries me: it's an operational point, not a point of protocol design. I'd have no objection if this were explicitly cast as an operational suggestion. o Services requiring varying performance properties can already be supported using separate endpoint associations (connections or other associations), each configured to support the desired properties. I can't figure out what you mean here. Do you have an example, or can you tweak the explanation? -- Section 7 -- 7. How to Use Assigned Port Numbers Port numbers are assigned by IANA by a set of documented procedures [RFC6335]. The following section describes the steps users can take to help assist with the use of assigned port numbers, and with preparing an application for a port number assignment. In both the title and the paragraph, you refer to the "use" of "assigned port numbers", and yet the entire section talks about getting port assignments, not about using the port numbers after they're assigned. I suggest this instead: NEW 7. Considerations for Requesting Port Number Assignments Port numbers are assigned by IANA by a set of documented procedures [RFC6335]. The following section describes the steps designers can take to help assist with the responsible assignment of port numbers, and with preparing an application for a port number assignment. END -- Section 7.1 -- o Port numbers are not intended for indicating different service versions. Version differentiation should be handled in-band, e.g., using a version number at the beginning of an association (e.g., connection or other transaction). This may not be possible with legacy assignments, but all new assignments should incorporate support for version indication. Is this meant to say "but all new protocols should incorporate support for version indication."? It's not the assignment that does that. Some users may not need assigned port numbers at all Is this meant to say "some uses may not" (or "some protocols", but not "some users")? -- Section 7.2 -- There are a variety of known ways to reduce port number use. Although some may be cumbersome or inefficient, they are always preferable to consuming additional port numbers. 1. I think "reduce port number consumption" might be a better way to say what you mean here. 2. I don't think "always preferable" is consistent with the consensus on RFC 6335. I would accept "usually preferable", but not something as strong as "always". Although automatic configuration protocols have been proposed and developed (e.g., STUN [RFC5389], TURN [RFC5766], and ICE [RFC5245]), application and service designers cannot yet rely on their presence. I wouldn't call STUN, TURN, and ICE "automatic configuration protocols". I'd refer to them as "NAT traversal protocols". -- Section 7.3 -- Would a TCP (or other transport protocol) port number assignment be useful by itself? If so, a TCP (UDP) port number can be assigned whose port number is already (or can be subsequently) assigned to a different transport protocol. I'm not sure what you're getting at here. Are you saying that if you need a TCP port, you might pick one where the UDP port of the same number is (or can be) used for something else, and vice versa? If so, I don't think it says that at all clearly. In any case, can you please rephrase this to make it clearer? >> Developers SHOULD NOT apply for System port numbers because the increased privilege they are intended to provide is not always enforced. Hm. This sounds odd to me: it seems that it's setting up a feedback loop that's self sustaining. You might want a system port number to get protection against running on that port by non-root. But you won't always get that protection. So you shouldn't ask. So no one asks, and so no one gets the protection even when it's available. Do you think this works as well for you?: NEW >> Developers SHOULD request User port numbers, to avoid using the more limited System port number space. Consider that the increased protection that System ports are intended to provide is not always enforced. END I would also move that paragraph down one, so that it's after the "Even when developers" paragraph. -- Section 7.4 -- >> Security SHOULD NOT rely on port number distinctions alone; every service, whether secure or not, is likely to be attacked. I find this underspecified. I don't know what I should be doing about this. As in the DISCUSS, "security" is a vague term, and I don't know how to determine whether I've met this requirement, nor how to assess whether my situation is suitable one for not following it. Optional security can penalize performance, requiring additional round-trip exchanges before a connection or other association can be established. As discussed earlier, port numbers are a critical resource and it is inappropriate to consume assignments to increase performance. As a result, the need for separate ports for both secure and insecure variants is not justified merely for performance Where was this discussed earlier? The only thing I see related to performance that was discussed earlier is that it's not appropriate to have different ports to support different performance levels. That's not the same thing that you're talking about here. I agree with the conclusion (in the final sentence I quote). - either for the connection or association establishment performance or differences in data performance between secure and insecure variants. I can't parse this. Are there words missing or some such? Note however that a new service might not be eligible for IANA assignment of both an insecure and a secure variant of the same service, and similarly applications requesting assignment for both an insecure port number for a secure service might not be appropriate. I'm having trouble with this one also; I can't parse what comes after the comma. Maybe split the sentence into two, and rephrase? -- Section 7.5 -- How can this apply retroactively to current assignments? And "the multiple versions" should probably lose the "the". -- Section 7.6 -- Spencer has been picking on the use of 793 as a reference for TCP. Spencer, is 793 an acceptable reference for TCP here? It would probably be better to attach the references to their protocols, rather than to have them in a group at the end of the list. Originally, IANA port number assignments were concurrent for both UDP and TCP; other transports were not indicated. Total nit: I think this sentence doesn't work well with a semicolon, and would prefer changing the ";" to ", and". When the services differ, their service names and descriptions should reflect that difference. I had a little trouble with this and the discussion leading up to it, which I think can be fixed by saying explicitly that in this case, it's OK (perhaps even encouraged) to use the same port, but different service names. Perhaps something like this?: NEW When the services differ, it may be acceptable or preferable to use the same port number, but the service names and descriptions should be different, reflecting the differences in the services. END The following convention has been used by IANA for several years to distinguish discovery services, such as are used to identify endpoints capable of a given service: >> Names of discovery services SHOULD use an identifiable suffix; the suggestion is "-disc". It reads oddly to have "the following convention" point to a normative requirement, and not just to the convention. Again, a nit, but I think it would read better like this: NEW IANA has, for several years, used the suffix "-disc" in service names to distinguish discovery services, such as are used to identify endpoints capable of a given service. >> Names of discovery services SHOULD use an identifiable suffix; the suggestion is "-disc". END because IP routers do not forward "all nodes" (all 1's, i.e., 255.255.255.255 for IPv4) broadcasts and have not been required The phrase << "all nodes" broadcasts >> needs to stay together, and splitting it with the explanation made me trip over it. I suggest moving the word "broadcasts" before the parenthesized bit. >> Services SHOULD NOT use UDP as a performance enhancement over TCP, i.e., to circumnavigate TCP's congestion control. Is circumventing congestion control the only possible performance enhancement here? This sentence really makes one ask whether "i.e." is correct, or you mean "e.g.", and I think it'd be better done one of these ways: If you mean to say that congestion control is the only reason: NEW >> Services SHOULD NOT use UDP to enhance performance by circumventing TCP's congestion control. END If there might be other performance-enhancement reasons: NEW >> Services SHOULD NOT use UDP as a performance enhancement over TCP. For example, do not use UDP to circumvent TCP's congestion control. END (The right word is "circumvent", not "circumnavigate".) -- Section 7.7 -- Applications made through Internet Draft / RFC publication (in any stream) ... When a document has been approved for publication and proceeds to IESG Approval The first sentence tries to make this stream-independent, but the "IESG Approval" later in the paragraph is specific to the IETF stream. Because you already say "approved for publication", you can just omit the "and proceeds to IESG Approval" phrase. -- Section 7.8 -- Such "squatted" port numbers remain unassigned, and IANA retains the right to assign them when requested by applicants. It might be good to be completely clear and say "requested by other applicants," lest readers think you mean to be talking about when the squatters make an application later. The last paragraph in this section starts by encouraging squatters to make registrations now, but then shifts to a discouraging tone. I wonder if you mind changing the tone a little, maybe changing the idea of "not justified" to something more like "unable to accommodate". Perhaps like this?: NEW Designers who are using such port numbers are encouraged to apply for an assignment. Every effort will be made to accommodate such requests, though even with widespread de-facto use, if the port number has already been assigned to another applicant such accommodation might not be possible. Note also that the application must pass review by the IANA Ports Expert Review team, as must any port application. END -- Section 8 -- The port number alone should not be used to avoid denial of service or firewall traffic because their use is not regulated or validated. To "avoid ... firewall traffic"? What's that mean? I think you mean "to avoid denial-of-service attacks or to manage firewall traffic", yes? And then what is the "they" in "their use"? |
|
2015-02-17
|
07 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss |
|
2015-02-17
|
07 | Brian Haberman | [Ballot comment] I have many of the same questions as Barry. |
|
2015-02-17
|
07 | Brian Haberman | Ballot comment text updated for Brian Haberman |
|
2015-02-17
|
07 | Barry Leiba | [Ballot discuss] I have four things I'd like to discuss, three of which have to do with the fact that this document does not update … [Ballot discuss] I have four things I'd like to discuss, three of which have to do with the fact that this document does not update 6335, and, therefore, needs to stay in line with what 6335 says. I don't think it'll be a big deal: let's talk, please. POINT 1: -- Section 5 -- IANA aims to assign only one port number per service, including variants [RFC6335] The "including variants" part is not correct; from 6335, Section 7.2: Note: At the time of writing of this document, there is no IETF consensus on when it is appropriate to use a second port for an insecure version of a protocol. What is correct is what 6335 states: NEW IANA aims to assign only one port number per service or application. END POINT 2: -- Section 7.1 -- o Separate port numbers are not intended for insecure versions of existing (or new) secure services. A service that already requires security would be made more vulnerable by having the same capability accessible without security. I understand that this is meant only in the secure -> insecure direction, and in that direction it's probably mostly right. And, yet, it does seem to go against the statement that I quoted above from 6335, Section 7.2, which also goes in the same secure -> insecure direction: Note: At the time of writing of this document, there is no IETF consensus on when it is appropriate to use a second port for an insecure version of a protocol. I'm not sure we can say this as strongly in a document that claims, multiple times, not to be changing 6335. Perhaps this is a reasonable way to make this point?: NEW o Separate port numbers should not normally be used for insecure versions of existing (or new) secure services. A service that already requires security would be made more vulnerable by having the same capability accessible without security. END POINT 3: -- Section 7.4 -- >> New services SHOULD support security, either directly or via a secure transport such as TLS [RFC5246]. In this context, "security" is too vague a term: what, exactly, does "SHOULD support security" mean? Are you talking about authentication? Access/authorization controls? Confidentiality? Specifically, encrypted communication? I think you mean the last. It would be good to replace "security" in this and much of the subsequent paragraphs with some clearer specification of what you're addressing. POINT 4: -- Section 7.4 -- >> When simultaneously requesting both a secure and an insecure port, strong justification MUST be provided for the insecure port. Precedent (citing other protocols that use an insecure port) is not strong justification by itself. A strong case for utility of the insecure service is REQUIRED for approval of the insecure port. This seems significantly stronger thaan what RFC 6335 said, and this point was hotly debated in the development of that document. RFC 6335, Section 9, says this: Services are expected to include support for security, either as default or dynamically negotiated in-band. The use of separate service name or port number assignments for secure and insecure variants of the same service is to be avoided in order to discourage the deployment of insecure services. As this document does not update 6335, I don't see how the MUST and the REQUIRED are appropriate. But perhaps I can be convinced by some discussion. |
|
2015-02-17
|
07 | Barry Leiba | [Ballot comment] These are non-blocking, but please consider them -- many are meant to clarify the text, and I hope they succeed in that. In … [Ballot comment] These are non-blocking, but please consider them -- many are meant to clarify the text, and I hope they succeed in that. In three places: -- Abstract -- This document provides recommendations to application and service designers on how to use the transport protocol port number space. -- Section 1 -- It also provides specific recommendations to designers on how to use assigned port numbers. -- Section 2 -- In this document, the characters ">>" preceding an indented line(s) indicates a compliance requirement statement using the key words listed above. First, recommendations on how to use *port number space* is not the same as recommendations on how to use *assigned port numbers*. I interpret the former as recommendations about making requests for port numbers, and the latter as recommendations about use of the port numbers after they've been assigned. These should be worded consistently. Second, recommendations, whichever type of recommendations they be, are not the same as compliance requirements. I read the former as suggestions, and the latter as, well, requirements. If the document is giving requirements that cover port-number requests -- and it is, complete with MUSTs -- it needs to clearly say that up front, and get rid of the "recommendations" stuff (or say both, that there are both requirements and recommendations here). -- Section 5 -- Consider a user wanting to run a web server. That service could run on any port number, provided that all clients knew what port number to use to access that service at that host. Such information can be distributed out-of-band, e.g., in the URI: http://www.example.com:51509/ It's a fine point, but having the port number in the URI doesn't actually distribute it "out of band" (which doesn't need hyphens in this context). I would say, "Such information can be explicitly distributed -- for example, by putting it in the URI:". IANA assigns port numbers so that Internet endpoints do not need pairwise, explicit coordination of the meaning of their port numbers. This is the primary reason for requesting assigned port numbers with IANA - to have a common agreement between all endpoints on the Internet as to the default meaning of a port number. This only says half of it, and omits a very important piece, I think. May I suggest this?: NEW IANA assigns port numbers so that Internet endpoints do not need pairwise, explicit coordination of the meaning of their port numbers. This is the primary reason for requesting assigned port numbers with IANA - to have a common agreement between all endpoints on the Internet as to the default meaning of a port number, and to provide the endpoints with a default port number for a particular protocol or service. END >> Each port requested MUST be justified as independently necessary. This is a fair statement, and yet I worry that including "necessary" may result in arguments between protocol designers and port experts about what is and isn't "necessary", and what the community's consensus is on it. I'm not sure how to minimize that. I'd say "MUST be independently justified," which does get the point you want (the independent justification) without using the loaded word "necessary". I'd prefer that wording, though I admit that it can just as easily result in the same arguments. -- Section 6.1 -- o Copies of an existing service can be differentiated by using different IP addresses, either on different hosts or as different real or virtual interfaces (or even operating systems) on the same host. As a guiding principle for protocol designers, this worries me: it's an operational point, not a point of protocol design. I'd have no objection if this were explicitly cast as an operational suggestion. o Services requiring varying performance properties can already be supported using separate endpoint associations (connections or other associations), each configured to support the desired properties. I can't figure out what you mean here. Do you have an example, or can you tweak the explanation? -- Section 7 -- 7. How to Use Assigned Port Numbers Port numbers are assigned by IANA by a set of documented procedures [RFC6335]. The following section describes the steps users can take to help assist with the use of assigned port numbers, and with preparing an application for a port number assignment. In both the title and the paragraph, you refer to the "use" of "assigned port numbers", and yet the entire section talks about getting port assignments, not about using the port numbers after they're assigned. I suggest this instead: NEW 7. Considerations for Requesting Port Number Assignments Port numbers are assigned by IANA by a set of documented procedures [RFC6335]. The following section describes the steps designers can take to help assist with the responsible assignment of port numbers, and with preparing an application for a port number assignment. END -- Section 7.1 -- o Port numbers are not intended for indicating different service versions. Version differentiation should be handled in-band, e.g., using a version number at the beginning of an association (e.g., connection or other transaction). This may not be possible with legacy assignments, but all new assignments should incorporate support for version indication. Is this meant to say "but all new protocols should incorporate support for version indication."? It's not the assignment that does that. Some users may not need assigned port numbers at all Is this meant to say "some uses may not" (or "some protocols", but not "some users")? -- Section 7.2 -- There are a variety of known ways to reduce port number use. Although some may be cumbersome or inefficient, they are always preferable to consuming additional port numbers. 1. I think "reduce port number consumption" might be a better way to say what you mean here. 2. I don't think "always preferable" is consistent with the consensus on RFC 6335. I would accept "usually preferable", but not something as strong as "always". Although automatic configuration protocols have been proposed and developed (e.g., STUN [RFC5389], TURN [RFC5766], and ICE [RFC5245]), application and service designers cannot yet rely on their presence. I wouldn't call STUN, TURN, and ICE "automatic configuration protocols". I'd refer to them as "NAT traversal protocols". -- Section 7.3 -- Would a TCP (or other transport protocol) port number assignment be useful by itself? If so, a TCP (UDP) port number can be assigned whose port number is already (or can be subsequently) assigned to a different transport protocol. I'm not sure what you're getting at here. Are you saying that if you need a TCP port, you might pick one where the UDP port of the same number is (or can be) used for something else, and vice versa? If so, I don't think it says that at all clearly. In any case, can you please rephrase this to make it clearer? >> Developers SHOULD NOT apply for System port numbers because the increased privilege they are intended to provide is not always enforced. Hm. This sounds odd to me: it seems that it's setting up a feedback loop that's self sustaining. You might want a system port number to get protection against running on that port by non-root. But you won't always get that protection. So you shouldn't ask. So no one asks, and so no one gets the protection even when it's available. Do you think this works as well for you?: NEW >> Developers SHOULD request User port numbers, to avoid using the more limited System port number space. Consider that the increased protection that System ports are intended to provide is not always enforced. END I would also move that paragraph down one, so that it's after the "Even when developers" paragraph. -- Section 7.4 -- >> Security SHOULD NOT rely on port number distinctions alone; every service, whether secure or not, is likely to be attacked. I find this underspecified. I don't know what I should be doing about this. As in the DISCUSS, "security" is a vague term, and I don't know how to determine whether I've met this requirement, nor how to assess whether my situation is suitable one for not following it. Optional security can penalize performance, requiring additional round-trip exchanges before a connection or other association can be established. As discussed earlier, port numbers are a critical resource and it is inappropriate to consume assignments to increase performance. As a result, the need for separate ports for both secure and insecure variants is not justified merely for performance Where was this discussed earlier? The only thing I see related to performance that was discussed earlier is that it's not appropriate to have different ports to support different performance levels. That's not the same thing that you're talking about here. I agree with the conclusion (in the final sentence I quote). - either for the connection or association establishment performance or differences in data performance between secure and insecure variants. I can't parse this. Are there words missing or some such? Note however that a new service might not be eligible for IANA assignment of both an insecure and a secure variant of the same service, and similarly applications requesting assignment for both an insecure port number for a secure service might not be appropriate. I'm having trouble with this one also; I can't parse what comes after the comma. Maybe split the sentence into two, and rephrase? -- Section 7.5 -- How can this apply retroactively to current assignments? And "the multiple versions" should probably lose the "the". -- Section 7.6 -- Spencer has been picking on the use of 793 as a reference for TCP. Spencer, is 793 an acceptable reference for TCP here? It would probably be better to attach the references to their protocols, rather than to have them in a group at the end of the list. Originally, IANA port number assignments were concurrent for both UDP and TCP; other transports were not indicated. Total nit: I think this sentence doesn't work well with a semicolon, and would prefer changing the ";" to ", and". When the services differ, their service names and descriptions should reflect that difference. I had a little trouble with this and the discussion leading up to it, which I think can be fixed by saying explicitly that in this case, it's OK (perhaps even encouraged) to use the same port, but different service names. Perhaps something like this?: NEW When the services differ, it may be acceptable or preferable to use the same port number, but the service names and descriptions should be different, reflecting the differences in the services. END The following convention has been used by IANA for several years to distinguish discovery services, such as are used to identify endpoints capable of a given service: >> Names of discovery services SHOULD use an identifiable suffix; the suggestion is "-disc". It reads oddly to have "the following convention" point to a normative requirement, and not just to the convention. Again, a nit, but I think it would read better like this: NEW IANA has, for several years, used the suffix "-disc" in service names to distinguish discovery services, such as are used to identify endpoints capable of a given service. >> Names of discovery services SHOULD use an identifiable suffix; the suggestion is "-disc". END because IP routers do not forward "all nodes" (all 1's, i.e., 255.255.255.255 for IPv4) broadcasts and have not been required The phrase << "all nodes" broadcasts >> needs to stay together, and splitting it with the explanation made me trip over it. I suggest moving the word "broadcasts" before the parenthesized bit. >> Services SHOULD NOT use UDP as a performance enhancement over TCP, i.e., to circumnavigate TCP's congestion control. Is circumventing congestion control the only possible performance enhancement here? This sentence really makes one ask whether "i.e." is correct, or you mean "e.g.", and I think it'd be better done one of these ways: If you mean to say that congestion control is the only reason: NEW >> Services SHOULD NOT use UDP to enhance performance by circumventing TCP's congestion control. END If there might be other performance-enhancement reasons: NEW >> Services SHOULD NOT use UDP as a performance enhancement over TCP. For example, do not use UDP to circumvent TCP's congestion control. END (The right word is "circumvent", not "circumnavigate".) -- Section 7.7 -- Applications made through Internet Draft / RFC publication (in any stream) ... When a document has been approved for publication and proceeds to IESG Approval The first sentence tries to make this stream-independent, but the "IESG Approval" later in the paragraph is specific to the IETF stream. Because you already say "approved for publication", you can just omit the "and proceeds to IESG Approval" phrase. -- Section 7.8 -- Such "squatted" port numbers remain unassigned, and IANA retains the right to assign them when requested by applicants. It might be good to be completely clear and say "requested by other applicants," lest readers think you mean to be talking about when the squatters make an application later. The last paragraph in this section starts by encouraging squatters to make registrations now, but then shifts to a discouraging tone. I wonder if you mind changing the tone a little, maybe changing the idea of "not justified" to something more like "unable to accommodate". Perhaps like this?: NEW Designers who are using such port numbers are encouraged to apply for an assignment. Every effort will be made to accommodate such requests, though even with widespread de-facto use, if the port number has already been assigned to another applicant such accommodation might not be possible. Note also that the application must pass review by the IANA Ports Expert Review team, as must any port application. END -- Section 8 -- The port number alone should not be used to avoid denial of service or firewall traffic because their use is not regulated or validated. To "avoid ... firewall traffic"? What's that mean? I think you mean "to avoid denial-of-service attacks or to manage firewall traffic", yes? And then what is the "they" in "their use"? |
|
2015-02-17
|
07 | Barry Leiba | [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba |
|
2015-02-16
|
07 | Joel Jaeggli | [Ballot comment] At some future date, it might be useful to deprecate the distinction between System and User port numbers altogether. Services typically … [Ballot comment] At some future date, it might be useful to deprecate the distinction between System and User port numbers altogether. Services typically require elevated ('root') privileges to bind to a System port number, but many such services go to great lengths to immediately drop those privileges just after connection or other association establishment to reduce the impact of an attack using their capabilities. Such services might be more securely operated on User port numbers than on System port numbers. operationaly we already have dropped the distinction. there is not practical distiction for a new service allocated out of the remaining 180 system ports and one allocated out of the user ports so we might as well treat the port space as flat. |
|
2015-02-16
|
07 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
|
2015-02-12
|
07 | Jean Mahoney | Request for Telechat review by GENART is assigned to Dan Romascanu |
|
2015-02-12
|
07 | Jean Mahoney | Request for Telechat review by GENART is assigned to Dan Romascanu |
|
2015-02-11
|
07 | Spencer Dawkins | IESG state changed to IESG Evaluation from Waiting for Writeup |
|
2015-02-11
|
07 | Spencer Dawkins | Ballot writeup was changed |
|
2015-02-05
|
07 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Dan Harkins. |
|
2015-01-27
|
07 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
|
2015-01-27
|
07 | Spencer Dawkins | Telechat date has been changed to 2015-02-19 from 2015-02-05 |
|
2015-01-27
|
07 | Spencer Dawkins | Placed on agenda for telechat - 2015-02-05 |
|
2015-01-27
|
07 | Spencer Dawkins | Changed consensus to Yes from Unknown |
|
2015-01-27
|
07 | Spencer Dawkins | Ballot has been issued |
|
2015-01-27
|
07 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
|
2015-01-27
|
07 | Spencer Dawkins | Created "Approve" ballot |
|
2015-01-27
|
07 | Spencer Dawkins | Ballot writeup was changed |
|
2015-01-23
|
07 | Joseph Touch | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
|
2015-01-23
|
07 | Joseph Touch | New version available: draft-ietf-tsvwg-port-use-07.txt |
|
2015-01-19
|
06 | Gorry Fairhurst | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? BCP The document provides guidance to protocol and application designers on best current practices for requesting and using ports; BCP status clearly conveys the nature, importance and relevance of that guidance. Some reviewers have noted that this application of BCP status may not be aligned with their understanding of BCP status (RFC 2026, Section 5) and/or with current IETF usage of BCP status in practice. Since this is intended to document best practice and design recommendations for areas beyond TSV, the IESG should consider whether BCP status is appropriate (e.g., vs. Informational status). (2) 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: This document provides recommendations to application and service designers on how to use the transport protocol port number space. It complements (but does not update) RFC6335, which focuses on IANA process. Document Quality: During document review the intended status was carefully considered. This resulted in changes, omission of some material and greater attention to the recommendations. This document is now thought ready for publication by TSVWG. Personnel: Who is the Document Shepherd? G Fairhurst (TSVWG Co-Chair) Who is the Responsible Area Director? Spencer Dawkins (TSV AD) (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd reviewed this document, and the recommendations that it makes. The shepherd, and TSVWG reviewers think this is ready to be published. The document does impact other IETF Areas and was therefore subject to cross-area review during the initial WGLC. I am happy that the comments received during this process have adequately been addressed in the current draft. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Yes - The material on allocation of secure and non-secure ports, the discussion of firewall interactions, and other matters, means that this draft contains significantly more security material than is typical for TSVWG drafts. The chairs therefore recommend a security directorate review. (6) Describe any specific concerns or issues that the Document Shepherd has 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. No (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Confirmed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. None are known (9) 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? The document has been presented and discussed at IETF TSVWG meetings since IEWTF-80. Production of a document on this topic had the strong support of TSVWG when adopted after IETF-86, March 2013. The ID completed a first WGLC completing in June 2014 including cross-area review requests to RAI, APPS, and SEC Areas, and comments received from people within an outside TSVWG. Comments were also received from IANA. This resulted in changes to the style of presentation and to the recommendations, including ensuring that the relationship to RFC 6335 was made more clear. To confirm these changes the document subsequently had a second TSVWG WGLC (14/10/2014, concluding 29/10/2014) The second stage reviewers were D Black, G Fairhurst and E Lear. There were no additional comments. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Some references are marked by the tool as Obsolete, the document editor and shepherd have reviewed these and checked these are correct. As context, all obsolete references are cited in the section that describes the history of ports. In many cases, the earliest occurrence of an idea is cited in preference to later (in some cases obsoleting) RFCs. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. None (13) Have all references within this document been identified as either normative or informative? Yes (14) 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 plan for their completion? OK (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This document requires no actions from IANA (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. None |
|
2014-12-28
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Tim Wicinski. |
|
2014-12-22
|
06 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
|
2014-12-19
|
06 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
|
2014-12-19
|
06 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-tsvwg-port-use-06, which is currently in Last Call, and has the following comments: IANA has one comment about the text … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-tsvwg-port-use-06, which is currently in Last Call, and has the following comments: IANA has one comment about the text in the IANA Considerations section of this document. We understand that, upon approval of this document, there are no IANA Actions that need completion. While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object. Comment: The following text is described in the IC section. We would like to edit the text as follows: CURRENT: > 9. IANA Considerations > > The entirety of this document focuses on IANA issues, notably > suggestions that help ensure the conservation of port numbers and > provide useful hints for issuing informative requests thereof. NEW: > 9. IANA Considerations > > The entirety of this document focuses on > suggestions that help ensure the conservation of port numbers and > provide useful hints for issuing informative requests thereof. Reasoning: Removed "IANA issues" here as the document really is focusing on the use of port numbers and not really issues related to IANA. IANA does get the benefit from users doing the right thing when it comes to port use as it helps with the process for applying for port numbers. If this assessment is not accurate, please respond as soon as possible. |
|
2014-12-15
|
06 | Dan Romascanu | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Dan Romascanu. |
|
2014-12-15
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Wicinski |
|
2014-12-15
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Wicinski |
|
2014-12-11
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
|
2014-12-11
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
|
2014-12-11
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Dan Harkins |
|
2014-12-11
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Dan Harkins |
|
2014-12-08
|
06 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
|
2014-12-08
|
06 | Cindy Morgan | The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <tsvwg@ietf.org> Reply-To: ietf@ietf.org Sender: … The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <tsvwg@ietf.org> Reply-To: ietf@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-tsvwg-port-use-06.txt> (Recommendations for Transport Port Number Uses) to Best Current Practice The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Recommendations for Transport Port Number Uses' <draft-ietf-tsvwg-port-use-06.txt> as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-12-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides recommendations to application and service designers on how to use the transport protocol port number space. IT complements (but does not update) RFC6335, which focuses on IANA process. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/ballot/ No IPR declarations have been submitted directly on this I-D. |
|
2014-12-08
|
06 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
|
2014-12-08
|
06 | Spencer Dawkins | Last call was requested |
|
2014-12-08
|
06 | Spencer Dawkins | Last call announcement was generated |
|
2014-12-08
|
06 | Spencer Dawkins | Ballot approval text was generated |
|
2014-12-08
|
06 | Spencer Dawkins | Ballot writeup was generated |
|
2014-12-08
|
06 | Spencer Dawkins | IESG state changed to Last Call Requested from AD Evaluation |
|
2014-12-08
|
06 | Spencer Dawkins | IESG state changed to AD Evaluation from Publication Requested |
|
2014-11-19
|
06 | David Black | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
|
2014-11-12
|
06 | Cindy Morgan | IESG state changed to Publication Requested from Dead |
|
2014-11-12
|
06 | Cindy Morgan | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? BCP. (2) 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: This document provides recommendations to application and service designers on how to use the transport protocol port number space. It complements (but does not update) RFC6335, which focuses on IANA process. Document Quality: During document review the intended status was carefully considered. This resulted in changes, omission of some material and greater attention to the recommendations. This document is now thought ready for publication by TSVWG. Personnel: Who is the Document Shepherd? G Fairhurst (TSVWG Co-Chair) Who is the Responsible Area Director? Spencer Dawkins (TSV AD) (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd reviewed this document, and the recommendations that it makes. The shepherd, and TSVWG reviewers think this is ready to be published. The document does impact other IETF Areas and was therefore subject to cross-area review during the initial WGLC. I am happy that the comments received during this process have adequately been addressed in the current draft. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Yes - The material on allocation of secure and non-secure ports, the discussion of firewall interactions, and other matters, means that this draft contains significantly more security material than is typical for TSVWG drafts. The chairs therefore recommend a security directorate review. (6) Describe any specific concerns or issues that the Document Shepherd has 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. No (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Confirmed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. None are known (9) 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? The document has been presented and discussed at IETF TSVWG meetings since IEWTF-80. Production of a document on this topic had the strong support of TSVWG when adopted after IETF-86, March 2013. The ID completed a first WGLC completing in June 2014 including cross-area review requests to RAI, APPS, and SEC Areas, and comments received from people within an outside TSVWG. Comments were also received from IANA. This resulted in changes to the style of presentation and to the recommendations, including ensuring that the relationship to RFC 6335 was made more clear. To confirm these changes the document subsequently had a second TSVWG WGLC (14/10/2014, concluding 29/10/2014) The second stage reviewers were D Black, G Fairhurst and E Lear. There were no additional comments. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Some references are marked by the tool as Obsolete, the document editor and shepherd have reviewed these and checked these are correct. As context, all obsolete references are cited in the section that describes the history of ports. In many cases, the earliest occurrence of an idea is cited in preference to later (in some cases obsoleting) RFCs. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. None (13) Have all references within this document been identified as either normative or informative? Yes (14) 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 plan for their completion? OK (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This document requires no actions from IANA (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. None |
|
2014-11-12
|
06 | David Black | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
|
2014-11-12
|
06 | David Black | IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
|
2014-11-11
|
06 | Joseph Touch | New version available: draft-ietf-tsvwg-port-use-06.txt |
|
2014-11-11
|
05 | David Black | Tag Revised I-D Needed - Issue raised by WGLC set. |
|
2014-11-11
|
05 | David Black | IETF WG state changed to Waiting for WG Chair Go-Ahead from WG Document |
|
2014-09-17
|
05 | Joseph Touch | New version available: draft-ietf-tsvwg-port-use-05.txt |
|
2014-05-14
|
04 | Joseph Touch | New version available: draft-ietf-tsvwg-port-use-04.txt |
|
2014-05-08
|
03 | (System) | Document has expired |
|
2014-05-08
|
03 | (System) | IESG state changed to Dead from AD is watching |
|
2014-03-05
|
03 | Gorry Fairhurst | Document shepherd changed to Gorry Fairhurst |
|
2013-11-04
|
03 | Joseph Touch | New version available: draft-ietf-tsvwg-port-use-03.txt |
|
2013-07-15
|
02 | Joseph Touch | New version available: draft-ietf-tsvwg-port-use-02.txt |
|
2013-05-20
|
01 | Cindy Morgan | Shepherding AD changed to Spencer Dawkins |
|
2013-03-06
|
01 | Martin Stiemerling | State changed to AD is watching from Dead |
|
2013-02-25
|
01 | Joseph Touch | New version available: draft-ietf-tsvwg-port-use-01.txt |
|
2012-12-02
|
00 | (System) | Document has expired |
|
2012-12-02
|
00 | (System) | State changed to Dead from AD is watching |
|
2012-07-23
|
00 | Martin Stiemerling | Intended Status changed to Best Current Practice |
|
2012-07-23
|
00 | Martin Stiemerling | IESG process started in state AD is watching |
|
2012-05-31
|
00 | Joseph Touch | New version available: draft-ietf-tsvwg-port-use-00.txt |