Skip to main content

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)

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?