Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-00

[Fernando Gont <[e-mail]>]

At 02:42 a.m. 28/10/2008, David Borman wrote:

>>Firstly, the recv(2) with MSG_OOB only returns a single byt of
>>urgent data, whereas according to your explanation it should return
>>all data prior to, and including, the Urgent pointer.
>
>No, applications shouldn't be using recv() with MSG_OOB on TCP
>sockets.  That is the interface for the old, broken BSD interpretation
>of the urgent pointer.  TCP does not have out of band data.  The
>SO_OOBINLINE option was added so that new applications (new, circa
>1989, the date of RFC 1122) could turn this broken interface off and
>leave the data in the data stream where it belongs.

By default, the byte pointer byte (UP-1) is till kept OOB, nowadays.

Even worse, it has been reported to me that some major operating 
system did things even worse: it would queue what it thought was 
urgent data until the application read it by a recv(")/MSG_OOBB-like 
call. If the app didn't recv() this "OOB", then the urg data would 
pile up, until a DoS condition....


>  It was felt that
>we couldn't just change the BSD TCP implementation to the new
>behavior, because that would break all the existing applications.
>With SO_OOBINLINE, applications could switch over without there
>needing to be a flag day.

I believe this should be clarified. Do you?

I will prepare some text to update our draft before the 
non-00-version deadline....


>>>it to the application out-of-band.  To fix that, the SO_OOBINLINE
>>>socket option was introduced, and is still around today.  All
>>>applications that use urgent data should be using the SO_OOBINLINE
>>>option, there's no excuse for using the old, broken BSD
>>>interpretation
>>>about urgent data.
>>
>>Well, this seems to be the default for all major TCP implementations
>>(see our survey).
>
>Ok, there are two issues here.  First, SO_OOBINLINE turns off the old,
>broken BSD interpretation that removed a byte of data from the data
>stream and presented it to the application with the recv()/MSG_OOB
>call.

Agreed. I believe this should be clarified.


>The second issue is which byte is indicated in the packet with
>the urgent pointer.  If the application knows what the kernel does, it
>can adjust accordingly so that the correct byte gets marked in the TCP
>data stream.

Not sure what you mean. The issue here is how the *remote* TCP sets 
the urgent pointer. How could you know whether the remote TCP set the 
UP such that it points to the last byte of urgent data (RFC1122) or 
to the byte following the last byte of urgent data?

Considering that even SO_OOBINLINE doesn't change the semantics of 
the UP, I think RFC 1122 could be updated to reflect what current 
implementations are doing. (this is one of the "updates" that our 
draft was aiming)


>I will say that using the recv()/MSG_OOB interface is the bigger
>issue.  You just have to look at the BSD Telnet implementation and the
>dances that it does if SO_OOBINLINE isn't defined to understand why
>that broken interface is such a bad idea.

So we have to issues:

* Deprecate recv(2)/MSG_OOB and encourage SO_OOBINLINE. (with which 
you seem to agree)

* Update RFC 793/RFC1122 wrt where the UP points to, to reflect what 
everybody does and has been doing. (with which I don't know whether 
you agree or not).

Please let me know what you think, so that we can update our draft accordingly.

Thanks!

Kind regards,

--
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm