On the Implementation of the TCP Urgent Mechanism
draft-ietf-tcpm-urgent-data-07
Yes
(Lars Eggert)
No Objection
(Adrian Farrel)
(Dan Romascanu)
(Gonzalo Camarillo)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Tim Polk)
Note: This ballot was opened for revision 07 and is now closed.
Jari Arkko Former IESG member
(was Discuss)
Yes
Yes
(2010-09-23)
Unknown
> 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 Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
()
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
(2010-09-20)
Unknown
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>>
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Peter Saint-Andre Former IESG member
No Objection
No Objection
(2010-09-22)
Unknown
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.
Ralph Droms Former IESG member
No Objection
No Objection
(2010-09-21)
Unknown
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?)
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
(was Discuss)
No Objection
No Objection
(2010-09-22)
Unknown
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?