On the Implementation of the TCP Urgent Mechanism
Note: This ballot was opened for revision 07 and is now closed.
(Jari Arkko) (was Discuss) Yes
> 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.
(Lars Eggert) Yes
(Ron Bonica) (was Discuss) No Objection
(Gonzalo Camarillo) No Objection
(Ralph Droms) No Objection
Comment (2010-09-21 for -)
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?)
(Adrian Farrel) No Objection
(Russ Housley) No Objection
Alexey Melnikov No Objection
Comment (2010-09-20 for -)
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. <<Need to check Dave Cridland's SecDir/Apps review>>
(Tim Polk) (was Discuss) No Objection
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?
(Dan Romascanu) No Objection
(Peter Saint-Andre) No Objection
Comment (2010-09-22 for -)
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.