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

[Bill Squier <[e-mail]>]

On Feb 27, 2009, at 5:29 PM, Christos Zoulas wrote:

> In article <[e-mail]> you write:
>> Hello, folks,
>>
>> We have published a revision of our IETF Internet-Draft entitled  
>> "On the
>> implementation of TCP urgent data". The document is available at:
>> http://tools.ietf.org/id/draft-gont-tcpm-urgent-data-01.txt (you can
>> also get the document in other fancy formats, such as PDF, at
>> http://www.gont.com.ar/drafts).
>>
>> This document describes current issues relevant to the implementation
>> and use of TCP urgent data, aims to change the IETF specifications so
>> that they accommodate what virtually all implementations have been  
>> doing
>> wrt urgent data.
>>
>> The TCPM working group of the IETF is currently deciding whether to
>> adopt this document as a working group item, so that your input  
>> will be
>> very much appreciated.
>>
>> To voice your opinion, please send it to [e-mail], and CC me
>> ([e-mail]), so that I make sure that your post makes it  
>> to
>> the mailing-list, even if you are not subscribed to it.  
>> (Alternatively,
>> you can send me your input, and I could forward it to the [e-mail]
>> mailing-list).
>
> The behavior on Windows is more complex than this. I think that it  
> maintains
> much more data than a single byte and this can lead to resource  
> exhaustion.
> This behavior is used and required to be present by SQL Server, so  
> Microsoft
> is unwilling to change it. Bill Squier <[e-mail]> discovered  
> this and
> can provide you with details.

I haven't had time to read the article completely, but I did skim the  
Windows section, and Christos is correct.  Windows exhausts a non- 
paged fixed size pool of kernel memory (leading to a crash) whenever  
the receiver does not drain OOB data.  Thus, any Windows TCP receiver  
which does not expect OOB data is an avenue of attack.  For example,  
the NetBIOS listener.  I refer here to Windows versions <= XP.  I have  
not performed any testing on Vista and later.  Microsoft has been  
aware of this issue for years.  Jerry and James can speak to whether  
they have ever addressed it.

Further, I noticed that some of your analysis discusses OOB data  
bleeding in-line.  This is almost certainly caused by an interaction  
(on the _sender_) of Nagle and the fact that TCP defines only a single  
OOB pointer.  The receiver is not returning bytes which it knows to be  
OOB bytes inline, the _sender_ is accidentally placing more than a  
single byte of OOB in each packet that it sends.

The receiver has no way to know that, as the only means of  
communication about OOB data between sender and receiver is a single  
pointer.

I have added James and Jerry to this thread as well.

[note to [e-mail]; we are not subscribers, please preserve the  
cc: if you wish to solicit our feedback]

-wps