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

[Fernando Gont <[e-mail]>]

FYI

-------- Original Message --------
Subject: Re: On the implementation of TCP urgent data (IETF Internet Draft)
Date: Tue, 3 Mar 2009 10:14:55 -0500
From: Jerry Leichter <[e-mail]>
To: Fernando Gont <[e-mail]>
References: <[e-mail]>
<[e-mail]>
<[e-mail]>
<[e-mail]>
<[e-mail]>
<[e-mail]>
<[e-mail]>

OK, I read your draft.  A number of comments:

	You refer to the data pointed to by the urgent pointer as the urgent
data.  This is incorrect.  TCP doesn't directly have a concept of
urgent *data*; what it has is an urgent *mode*.  At best, you could
describe data received while in urgent mode as being urgent data - and
sometimes this is done.  That's what the RFC means when it requires
that any amount of urgent data must be supported:  That one can send
any amount of data while in urgent mode.  And, in fact, you can -
though you need to work at it:  Since the UP can only be 2^16 bytes
from the beginning of the current segment, what you need to do is
keeping moving the UP forward as you send more data.  There's no
concept of "leaving and immediately re-entering urgent mode" - you
simply stay in it.

Note that this is a fine concept, but *it's completely unsupported by
the socket API*.  While the socket API can tell you that you've
reached the end of the urgent data (a read() stops at the urgent byte,
and there's an ioctl() that tells you that you've just read it),
there's no way to know when you've *entered* urgent mode.  At best,
you can get a signal, but there's no way to figure out how that
relates to the position in the TCP stream.  (Of course, the TCP spec
isn't entirely clear on how the sender can control when you enter
urgent mode.  At the receiver, it's easy:  At the beginning of a
segment that has UP set.)

Given all that, I think your suggestion that there is no OOB data,
only Urgent Mode, is exactly backwards.  Unless I'm inside of the TCP
stack, Urgent Mode is a meaningless concept.  I can't control when it
starts, I can't detect when it starts, I can't even ask if I'm *in*
urgent mode.  Yes, this is a TCP RFC, but it's simply repeating the
existing problem:  TCP implementers worry about urgent mode, socket
API users see OOB data - and the how it all works remains a mystery.

In fact, you consistently describe the socket API's that read OOB data
as reading "urgent data".  This is wrong; at best, it reads *the last
byte* of urgent data.  The rest of the urgent data is *always* read in
line.

	You comment that based on tests under Cygwin, OOB data is always
delivered in-line.  If so, this is a Cygwin issue - I can tell you
quite definitely that if you use the Windows socket implementation, by
default OOB data does *not* get delivered in-line.

	You recommend that applications that use OOB data request that it be
delivered in line.  This is pointless - it fixes nothing.  There are
two cases:  Either the code simply ignores the OOB setting, or it use
an ioctl() to check if the last byte it just read was OOB.  If the
former - there's absolutely no point to using OOB data, hence no point
to urgent mode.  If the latter, the code is just as vulnerable as code
that reads OOB data separately:  When OOB data "slips in-band" in
current implementations/middle boxes, *all information that it was
ever OOB is lost*.  A read won't be required to stop at that byte, and
the ioctl() will never report that the byte was initially OOB.  You've
helped nothing.

	The RFC's today *do not allow* middle boxes to turn of the UP bit.
Either we change the spec to completely eliminate the whole concept of
urgent data, or we assert that the spec is right, and these middle
boxes don't conform.  It's absurd to specify something and then tell
applications "well, it's in the spec, but you can't rely on it".  And,
frankly, if NDIS's can't get this right - too bad.  Fix them.

	BTW, Microsoft actually *relies* on OOB data.  I don't know the
details - something to do with aborting database transactions.  I
expect you'd see significant opposition from them to an attempt to
remove Urgent Mode from the specs.

	When you come right down to it, Urgent Mode as specified by TCP is
unambiguous (ignoring the age-old RFC793/RFC961 which is irrelevant in
today's world:  Everyone has agreed on the same interpretation).  The
actual problems are:

	- Middle-box implementations that *illegally* modify data in transit;
	- Poorly specified, ambiguous definitions of how OOB data is supposed
		to work in the socket API;
	- Many incorrect implementations of the socket API.

None of these can be fixed at the TCP spec level, since that's not
where the problem is.  (Well, the first is a matter of politics:
Getting implementers to actually implement the specs as they exist!)
So while I think it's important to raise these issues with IETF, this
document is aimed at the wrong target.
                                                        -- Jerry



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