On the Implementation of the TCP Urgent Mechanism
RFC 6093

Note: This ballot was opened for revision 07 and is now closed.

(Jari Arkko) (was Discuss) Yes

Comment (2010-09-23)
No email
send info
> 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 -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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 -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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

Comment (2010-09-22)
No email
send info
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 -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Robert Sparks) No Objection

(Sean Turner) No Objection