Re: [tcpm] On the implementation of TCP urgent data (IETF Internet Draft)

[Jerry Leichter <[e-mail]>]

On Mar 2, 2009, at 11:19 PM, James Chacon wrote:
> Actually we have seen leaks in-band when simply sending one byte at  
> a time of OOB. It appears if the distance between 2 bytes exceeds  
> the available OOB marker (which from memory was 16 bits) and nothing  
> reads on the receiving end then on some impls the bytes leak in-band.
>
> We've seen that on linux and on Solaris to my recollection.
I don't dispute the observations, but the explanation makes no sense  
to me.  Yes, the Urgent Pointer is a 16-bit offset from the beginning  
of the segment in which it appears (or something very much like  
that).  It would make no sense to store the UP position as just the 16- 
bit offset inside the implementation, since that's impossible to  
interpret without the segment starting point.  The received segment  
itself already has the (32 bit) position in the stream of the segment,  
and the pair is unambiguous.  An implementation could store the pair,  
but why?  The 32-bit sum of the UP and the segment starting position  
is 2 bytes smaller and contains exactly the same information.

With bugs anything is possible, of course, but it's hard to see why  
having the distance between successive OOB bytes being > 2^16 should  
be significant in and of itself.  How was this tested?  Are you sure  
it's really "gap > 2^16" or could it be "gap large enough" or "enough  
data buffered"?  I can see this leading to the failure mode that I  
described earlier:  User receiver hasn't read data for a long time;  
receiving TCP lets its receive window close as it's running out of  
buffer space; data piles up in sender's TCP stack buffers; eventually  
we have two OOB bytes within the data to be sent; sender doesn't keep  
track of this, or tries to send a segment with two OOB bytes and can  
only encode one.
                                                         -- Jerry