On the Implementation of the TCP Urgent Mechanism
RFC 6093

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

Lars Eggert Yes

(Jari Arkko; former steering group member) (was Discuss) Yes

Yes (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.

(Adrian Farrel; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Alexey Melnikov; former steering group member) No Objection

No Objection (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>>

(Dan Romascanu; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Peter Saint-Andre; former steering group member) No Objection

No Objection (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.

(Ralph Droms; former steering group member) No Objection

No Objection (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?)

(Robert Sparks; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ron Bonica; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Sean Turner; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Tim Polk; former steering group member) (was Discuss) No Objection

No Objection (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?