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

[James Chacon <[e-mail]>]

On Mar 3, 2009, at 7:24 AM, Jerry Leichter wrote:

> 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
>

It's entirely possible your reasoning is also the cause. To be honest  
I never felt like diving into linux networking code to figure out the  
reason :)

I just know we have a reasonably reliable test which can replicate  
this on linux and the likelihood of seeing that fixed was low based on  
experiences with the select API and it's bugs.

James