On the Implementation of the TCP Urgent Mechanism
draft-ietf-tcpm-urgent-data-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the Yes position for Jari Arkko |
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Ronald Bonica |
2010-10-25
|
07 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2010-10-22
|
07 | (System) | IANA Action state changed to No IC from In Progress |
2010-10-22
|
07 | (System) | IANA Action state changed to In Progress |
2010-10-22
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent |
2010-10-22
|
07 | Amy Vezza | IESG has approved the document |
2010-10-22
|
07 | Amy Vezza | Closed "Approve" ballot |
2010-10-21
|
07 | Lars Eggert | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup by Lars Eggert |
2010-10-21
|
07 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Discuss by Tim Polk |
2010-10-16
|
07 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to Yes from Discuss by Jari Arkko |
2010-10-15
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2010-10-15
|
07 | (System) | New version available: draft-ietf-tcpm-urgent-data-07.txt |
2010-09-29
|
07 | Ron Bonica | [Ballot Position Update] Position for Ron Bonica has been changed to No Objection from Discuss by Ron Bonica |
2010-09-24
|
07 | (System) | Removed from agenda for telechat - 2010-09-23 |
2010-09-23
|
07 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan |
2010-09-23
|
07 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks |
2010-09-23
|
07 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded by Sean Turner |
2010-09-23
|
07 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded by Gonzalo Camarillo |
2010-09-23
|
07 | Ron Bonica | [Ballot discuss] This is a discuss-discuss. This sounds like a feature that never really worked. Applications have been discouraged from using it for years. Many … [Ballot discuss] This is a discuss-discuss. This sounds like a feature that never really worked. Applications have been discouraged from using it for years. Many deployed middle boxes defeat it. Maybe a better approach would be to deprecate the feature and talk about alternative methods of delivering urgent data (e.g. a separate TCP session for urgent data only). |
2010-09-23
|
07 | Ron Bonica | [Ballot Position Update] New position, Discuss, has been recorded by Ron Bonica |
2010-09-23
|
07 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2010-09-23
|
07 | Jari Arkko | [Ballot comment] > This means that if this > sysctl is set, an application might be unable to interoperate with > itself if both the … [Ballot comment] > This means that if this > sysctl is set, an application might be unable to interoperate with > itself if both the TCP sender and the TCP receiver are running on the > same host. Heh. Amusing, or perhaps a proof of the lack of real use. Some questions from a review by Ari Keranen: 3.2. Semantics of the Urgent Pointer [...] For example, Linux provides the sysctl "tcp_stdurg" (i.e., net.ivp4.tcp_stdurg) that, when set, supposedly changes the system behavior to interpret the semantics of the TCP Urgent Pointer as specified in RFC 1122. Since the Linux behavior may change later on, it would be a good idea to note the version of the Linux with this behavior (same probably applies to section 3.4 with Cisco PIX too). Maybe you could add a reference to the related appendix with this info. 5. Advice to new applications employing TCP As a result of the issues discussed in Section 3.2 and Section 3.4, new applications SHOULD NOT employ the TCP urgent mechanism. What about applications that supposedly do not use the urgent mechanism but an attacker might use it against them? Should it be recommended for all applications to always set the SO_OOBINLINE socket option to prevent the attack described in [phrack]? Or perhaps recommend this to be made the default in the kernels of the OSs -- even if they got it wrong the first time. |
2010-09-23
|
07 | Jari Arkko | [Ballot discuss] This is GREAT document, thank you for writing it. I am reading it very carefully due to the importance of the Updates clause. … [Ballot discuss] This is GREAT document, thank you for writing it. I am reading it very carefully due to the importance of the Updates clause. With this in mind, please consider the following: As discussed in Section 1, the TCP urgent mechanism simply permits a point in the data stream to be designated as the end of urgent information, but does NOT provide a mechanism for sending out of band data. As far as I can tell, Section 1 does not discuss this. The intended semantics of the urgent mechanism are also a crucial point for the changes suggested in this document, so I hope to see a clear reference and a rock solid explanation why this the case. That being said, I think the matter is pretty clear, given that there is no start pointer for the urgent data. However, RFC 793 confuses this a bit by saying: If the sending user also indicates a push, timely delivery of the urgent information to the destination process is enhanced. whereas in reality all data up to and including the urgent information gets a higher priority treatment. I have no comments on the rest of the contents of the document. However, I think the document is lacking in two respects. First, as far as I can tell, it does not describe the problems (if any) that result from a different interpretation of the pointer and other semantics on the two endpoints. Second, if there are significant problems, perhaps all the evidence from this document should be taken as an indication that urgent data is simply not used in the Internet (and might be deprecated). If there are no problems, what's the fuss? |
2010-09-23
|
07 | Jari Arkko | [Ballot comment] > This means that if this > sysctl is set, an application might be unable to interoperate with > itself if both the … [Ballot comment] > This means that if this > sysctl is set, an application might be unable to interoperate with > itself if both the TCP sender and the TCP receiver are running on the > same host. Heh. Amusing, or perhaps a proof of the lack of real use. Some questions from a review by Ari Keranen: 3.2. Semantics of the Urgent Pointer [...] For example, Linux provides the sysctl "tcp_stdurg" (i.e., net.ivp4.tcp_stdurg) that, when set, supposedly changes the system behavior to interpret the semantics of the TCP Urgent Pointer as specified in RFC 1122. Since the Linux behavior may change later on, it would be a good idea to note the version of the Linux with this behavior (same probably applies to section 3.4 with Cisco PIX too). Maybe you could add a reference to the related appendix with this info. 5. Advice to new applications employing TCP As a result of the issues discussed in Section 3.2 and Section 3.4, new applications SHOULD NOT employ the TCP urgent mechanism. What about applications that supposedly do not use the urgent mechanism but an attacker might use it against them? Should it be recommended for all applications to always set the SO_OOBINLINE socket option to prevent the attack described in [phrack]? Or perhaps recommend this to be made the default in the kernels of the OSs -- even if they got it wrong the first time. |
2010-09-23
|
07 | Jari Arkko | [Ballot discuss] This is GREAT document, thank you for writing it. I am reading it very carefully due to the importance of the Updates clause. … [Ballot discuss] This is GREAT document, thank you for writing it. I am reading it very carefully due to the importance of the Updates clause. With this in mind, please consider the following: As discussed in Section 1, the TCP urgent mechanism simply permits a point in the data stream to be designated as the end of urgent information, but does NOT provide a mechanism for sending out of band data. As far as I can tell, Section 1 does not discuss this. The intended semantics of the urgent mechanism are also a crucial point for the changes suggested in this document, so I hope to see a clear reference and a rock solid explanation why this the case. That being said, I think the matter is pretty clear, given that there is no start pointer for the urgent data. However, RFC 793 confuses this a bit by saying: If the sending user also indicates a push, timely delivery of the urgent information to the destination process is enhanced. whereas in reality all data up to and including the urgent information gets a higher priority treatment. I have no comments on the rest of the contents of the document. However, I think the document is lacking in two respects. First, as far as I can tell, it does not describe the problems (if any) that result from a different interpretation of the pointer and other semantics on the two endpoints. Second, if there are significant problems, perhaps all the evidence from this document should be taken as an indication that urgent data is simply not used in the Internet (and might be deprecated). If there are no problems, what's the fuss? Second, |
2010-09-22
|
07 | Jari Arkko | [Ballot comment] Some questions from a review by Ari Keranen: 3.2. Semantics of the Urgent Pointer [...] For example, Linux provides the sysctl … [Ballot comment] Some questions from a review by Ari Keranen: 3.2. Semantics of the Urgent Pointer [...] For example, Linux provides the sysctl "tcp_stdurg" (i.e., net.ivp4.tcp_stdurg) that, when set, supposedly changes the system behavior to interpret the semantics of the TCP Urgent Pointer as specified in RFC 1122. Since the Linux behavior may change later on, it would be a good idea to note the version of the Linux with this behavior (same probably applies to section 3.4 with Cisco PIX too). Maybe you could add a reference to the related appendix with this info. 5. Advice to new applications employing TCP As a result of the issues discussed in Section 3.2 and Section 3.4, new applications SHOULD NOT employ the TCP urgent mechanism. What about applications that supposedly do not use the urgent mechanism but an attacker might use it against them? Should it be recommended for all applications to always set the SO_OOBINLINE socket option to prevent the attack described in [phrack]? Or perhaps recommend this to be made the default in the kernels of the OSs -- even if they got it wrong the first time. |
2010-09-22
|
07 | Jari Arkko | [Ballot discuss] This is GREAT document, thank you for writing it. I am reading it very carefully due to the importance of the Updates clause. … [Ballot discuss] This is GREAT document, thank you for writing it. I am reading it very carefully due to the importance of the Updates clause. With this in mind, please consider the following: As discussed in Section 1, the TCP urgent mechanism simply permits a point in the data stream to be designated as the end of urgent information, but does NOT provide a mechanism for sending out of band data. As far as I can tell, Section 1 does not discuss this. The intended semantics of the urgent mechanism are also a crucial point for the changes suggested in this document, so I hope to see a clear reference. |
2010-09-22
|
07 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko |
2010-09-22
|
07 | Jari Arkko | [Ballot comment] Some questions from a review by Ari Keranen: 3.2. Semantics of the Urgent Pointer [...] For example, Linux provides the sysctl … [Ballot comment] Some questions from a review by Ari Keranen: 3.2. Semantics of the Urgent Pointer [...] For example, Linux provides the sysctl "tcp_stdurg" (i.e., net.ivp4.tcp_stdurg) that, when set, supposedly changes the system behavior to interpret the semantics of the TCP Urgent Pointer as specified in RFC 1122. Since the Linux behavior may change later on, it would be a good idea to note the version of the Linux with this behavior (same probably applies to section 3.4 with Cisco PIX too). Maybe you could add a reference to the related appendix with this info. 5. Advice to new applications employing TCP As a result of the issues discussed in Section 3.2 and Section 3.4, new applications SHOULD NOT employ the TCP urgent mechanism. What about applications that supposedly do not use the urgent mechanism but an attacker might use it against them? Should it be recommended for all applications to always set the SO_OOBINLINE socket option to prevent the attack described in [phrack]? Or perhaps recommend this to be made the default in the kernels of the OSs -- even if they got it wrong the first time. |
2010-09-22
|
07 | Peter Saint-Andre | [Ballot comment] 1. Section 2.1 states: TCP incorporates an "urgent mechanism" that allows the sending user to stimulate the receiving user to accept … [Ballot comment] 1. Section 2.1 states: TCP incorporates an "urgent mechanism" that allows the sending user to stimulate the receiving user to accept some "urgent data" and to permit the receiving TCP to indicate to the receiving user when all the currently known urgent data have been received by the user. The phrase "have been received by the user" is ambiguous -- do you mean the sending user or the receiving user here? I would assume the receiving user, but it would be good to make that explicit. You could change "by the user" to "by the receiving user" or simply remove "by the user" at the end of the sentence. |
2010-09-22
|
07 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded by Peter Saint-Andre |
2010-09-22
|
07 | Amy Vezza | State changed to IESG Evaluation from In Last Call by Amy Vezza |
2010-09-22
|
07 | Tim Polk | [Ballot comment] While consistent with RFC 793, I found the references to "user" in section 2.1 (paragraphs 1 and 2) a little odd. Is … [Ballot comment] While consistent with RFC 793, I found the references to "user" in section 2.1 (paragraphs 1 and 2) a little odd. Is this still the accepted terminology for TCP implementations? |
2010-09-22
|
07 | Tim Polk | [Ballot discuss] This is a discuss-discuss. To be clear, I am not requesting any changes in the document at this time. I would like to … [Ballot discuss] This is a discuss-discuss. To be clear, I am not requesting any changes in the document at this time. I would like to discuss several issues before I either clear or make this an actionable discuss. (1) Given the content in the preceding sections, I was somewhat disappointed with the scope of sections 4, 5 and 6. Why did the wg choose not to update the allowed length of urgent data, given that almost every implementation supports only one byte of urgent data? Even if the wg was not comfortable updating the specifications in section 4, wouldn't it be prudent to admonish applications not to use this mechanism for more than a single byte in section 6? Similarly, section 5 reiterates that TCP implementations MUST support the urgent mechanism. Do these implementations need to support urgent data of a single byte or "any length"? (2) I wonder why section 6 does not reiterate the closing text in 3.4: that applications need to be designed for correct operation even in the case where the URG flag is cleared by middleboxes. (3) I think the most important sentence in this document is the first sentence of section 5: "... new applications SHOULD NOT employ the TCP urgent mechanism." Reading the Abstract and Introduction provides no clue that such important guidance is hidden within. Shouldn't this be highlighted? (4) Last, but perhaps most important of all: given the guidance cited in (3), did the wg consider making this a BCP? |
2010-09-22
|
07 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk |
2010-09-21
|
07 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel |
2010-09-21
|
07 | Ralph Droms | [Ballot comment] Section 2.1 (editorial): are "sending user" and "receiving user" typical terms in specifications of urgent data; do they imply human users? Would "sender" … [Ballot comment] Section 2.1 (editorial): are "sending user" and "receiving user" typical terms in specifications of urgent data; do they imply human users? Would "sender" and "receiver" be more general? In section 3.2, I'm guessing "net.ivp4.tcp_stdurg" is a typo (ipv4?) |
2010-09-21
|
07 | Ralph Droms | [Ballot comment] Section 2.1 (editorial): are "sending user" and "receiving user" typical terms in specifications of urgent data; do they imply human users? Would "sender" … [Ballot comment] Section 2.1 (editorial): are "sending user" and "receiving user" typical terms in specifications of urgent data; do they imply human users? Would "sender" and "receiver" be more general? In section 3.2, I'm guessing "net.ivp4.tcp_stdurg" is a typo (ipv4?) |
2010-09-21
|
07 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms |
2010-09-20
|
07 | Alexey Melnikov | [Ballot comment] 3.4. Interaction of middle-boxes with TCP urgent indications This should discourage applications from depending on urgent indications for their correct … [Ballot comment] 3.4. Interaction of middle-boxes with TCP urgent indications This should discourage applications from depending on urgent indications for their correct operation, as urgent indications may not be not reliable in the Did you mean "may not be *reliable*"? current Internet. <> |
2010-09-20
|
07 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov |
2010-09-18
|
07 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2010-09-15
|
07 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Dave Cridland. |
2010-09-14
|
07 | Amanda Baber | We understand that this document doesn't require any IANA actions. |
2010-09-11
|
07 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Dave Cridland |
2010-09-11
|
07 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Dave Cridland |
2010-09-07
|
07 | Amy Vezza | Last call sent |
2010-09-07
|
07 | Amy Vezza | State changed to In Last Call from Last Call Requested by Amy Vezza |
2010-09-07
|
07 | Lars Eggert | Placed on agenda for telechat - 2010-09-23 by Lars Eggert |
2010-09-07
|
07 | Lars Eggert | Last Call was requested by Lars Eggert |
2010-09-07
|
07 | Lars Eggert | State changed to Last Call Requested from AD Evaluation by Lars Eggert |
2010-09-07
|
07 | Lars Eggert | [Ballot Position Update] New position, Yes, has been recorded for Lars Eggert |
2010-09-07
|
07 | Lars Eggert | Ballot has been issued by Lars Eggert |
2010-09-07
|
07 | Lars Eggert | Created "Approve" ballot |
2010-09-07
|
07 | (System) | Ballot writeup text was added |
2010-09-07
|
07 | (System) | Last call text was added |
2010-09-07
|
07 | (System) | Ballot approval text was added |
2010-09-07
|
07 | Lars Eggert | State changed to AD Evaluation from Publication Requested by Lars Eggert |
2010-09-07
|
07 | Lars Eggert | Responsible AD has been changed to Lars Eggert from Jari Arkko by Lars Eggert |
2010-09-03
|
07 | Amy Vezza | [Note]: 'Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd.' added by Amy Vezza |
2010-09-03
|
07 | Amy Vezza | draft-ietf-tcpm-urgent-data (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of … draft-ietf-tcpm-urgent-data (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd. He has personally reviewed this version and believes it is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has had review in the TCPM working group, and underwent several revisions based on mailing list discussion, face-to-face presentations at IETF meetings, and interaction with the stewards of several TCP implementations. The shepherd has no concerns about the depth or breadth of review. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No concerns. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There has been no resistance to this document and reasonable support for it at its inception. It is felt that this resolves a long-standing issue in specification and implementation divergence. (1.f) 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 entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? There are three IDNITS warnings, two of which appear to be spurious, and the third is merely an unused reference, which the RFC Editor can correct. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The references are properly split. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA Considerations are present and specify no actions for IANA. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Not Applicable. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. From abstract: This document analyzes how current TCP implementations process TCP urgent indications, and how the behavior of some widely-deployed middle-boxes affect how urgent indications are processed by end systems. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, provides advice to applications that make use of the urgent mechanism, and raises awareness about the reliability of TCP urgent indications in the current Internet. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Nothing exceptional occurred during the working group process for this document. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This document specifically is aimed at bringing the specification and existing implementations into line clearly with each other. The implementation practices in this document have been adopted in multiple implementations and this document provides guidance to aid in future compatibility with applications in new and old TCP implementations. |
2010-09-03
|
07 | Amy Vezza | Draft Added by Amy Vezza in state Publication Requested |
2010-08-23
|
06 | (System) | New version available: draft-ietf-tcpm-urgent-data-06.txt |
2010-03-05
|
05 | (System) | New version available: draft-ietf-tcpm-urgent-data-05.txt |
2010-03-04
|
04 | (System) | New version available: draft-ietf-tcpm-urgent-data-04.txt |
2010-02-20
|
03 | (System) | New version available: draft-ietf-tcpm-urgent-data-03.txt |
2009-11-26
|
02 | (System) | New version available: draft-ietf-tcpm-urgent-data-02.txt |
2009-11-10
|
01 | (System) | New version available: draft-ietf-tcpm-urgent-data-01.txt |
2009-05-20
|
00 | (System) | New version available: draft-ietf-tcpm-urgent-data-00.txt |