tcp urgent data
David A. Borman
> From HYS1@rs_hcomm.rsvl.unisys.com Wed Sep 22 14:24:19 1993
> To: ietf-...@ISI.EDU, end2end-...@ISI.EDU
> From: "Kurt Matthys" <HYS1@rs_hcomm.rsvl.unisys.com>
> Date: 22 Sep 93 14:17:01 CST
> Subject: tcp urgent data
> Reply-To: ku...@rsvl.unisys.com
> Priority: normal
> X-Mailer: Pegasus Mail v2.3 (R5).
>
> I am wondering if there is a standard, approved way to handle tcp
> urgent data when an rfc793 compliant host is communicating with an
> RFC 1122 compatible host. If the 793 host is sending, the 1122
> host thinks that there is more urgent data than there really is. The
> problem here is that Telnet is supposed to keep looking for the IAC
> DM after running out of urgent data. The DM will be in the
> penultimate byte of urgent data as far as the 1122 host is concerned.
> Telnet will look at the last byte of what it thinks is urgent data,
> see that it is not a DM, and continue discarding input. This is not
> good.
>
> One way to handle the situation is for the 1122 TCP to lie to Telnet,
> saying that there is one less urgent byte than TCP thinks there is.
> This will work whether the 1122 host is communicating with a 793 host
> or a 1122 host. This sounds like a kludge to me, and is esthetically
> not pleasing as TCP is now lying to the applications. Can someone
> shed some light on this for me?
No, you don't want TCP to lie to Telnet. You want Telnet to lie
to TCP...
Think about the application, and what it will do. RFC 854 says:
The Synch is sent via the TCP send operation with the Urgent
flag set and the DM as the last (or only) data octet.
and:
If TCP indicates the end of Urgent data before the DM is found,
TELNET should continue the special handling of the data stream
until the DM is found.
If the IAC DM is sent as:
seq# 101 IAC
seq# 102 DM
Then the correct urgent pointer would be seq#102. The incorrect
urgent pointer would be seq#103. If a correct TCP got the packet
from an incorrect TCP, it would continue to have urgent notification
after the IAC DM was read, and would thus keep reading, looking for
another IAC DM.
If an incorrect TCP got the packet from a correct TCP, it would get
to the end of the urgent notification before reading the DM. But
the rules say to keep reading until an IAC DM is found, so it will
read the next byte, find the DM, and properly terminate the Synch.
So, if the Telnet application sends the IAC as the last byte of
urgent data, rather than the DM, then it doesn't matter whether
the telnet is running on top of a correct or an incorrect TCP.
Correct to correct, and incorrect to incorrect will have the
Urgent terminate 1 byte early. Incorrect to correct will appear
to have the urgent terminate at the right point. Correct to
incorrect will have the urgent terminate 2 bytes early. In all
cases, since the urgent notification terminates before or at
the DM, the telnet application will do the right thing.
Of course, if the application knows that it is running on
a correct TCP, it can send send the urgent data normally.
If it know that it is running on an incorrect TCP, it can
send one less byte as urgent data, and assume that when it
reads urgent data that there is really one more byte of
urgent data than what TCP says.
-David Borman, d...@cray.com
Kurt Matthys
Dave,
Thanks for the info. I still have some questions though. Your
solution works fine for Telnet if you have control over the
end sending the urgent data. It also works if you are sending two or
more bytes of urgent data. It doesn't seem to work if only one byte
of urgent data is being sent and Telnet is not being used, or if you
only have control over the receiving end.
With your solution, if an application on an incorrect host wants to
send only one byte of urgent data, it will tell TCP that it wants to
send zero bytes of urgent data. TCP will probably not send
anything. The same application on a correct host would tell TCP to
send one byte of urgent data but an incorrect host receiving it would
think that there are no urgent bytes even though the urgent flag is
set.
I am interested in the case where I don't have control over all the
sending ends (they are existing applications), Telnet is not being
used, and only one byte of urgent data is being sent in each
direction. Any ideas?
BTW, did the BSD code ever change to do urgent data correctly? I
understand that USL also did it incorrectly. Did they ever change?
What kind of a market does a correct implementation have? What
percent of the implementations out there will it interoperate with?
What are the prospects in the long run? I can see where it would be
difficult for any vendor that supplies an incorrect TCP to change
since his implementation would not even interoperate with old
versions of his implementation.
Kurt
----------------------------------------------------------------------
Kurt Matthys
Unisys Corp Tel: (612) 635-5693
M.S. 4123 Fax: (612) 635-7523
P.O. Box 64942 email: ku...@rsvl.unisys.com
St. Paul, MN 55164 0942
----------------------------------------------------------------------
Mike Karels
the protocol actions, including Telnet, and the programmatic interface
to the network (I hate the API acronym). I suspect that you are assuming
the BSD socket interface, soon to be POSIX as well, although I'm not sure
of that.
> With your solution, if an application on an incorrect host wants to
> send only one byte of urgent data, it will tell TCP that it wants to
> send zero bytes of urgent data. TCP will probably not send
> anything. The same application on a correct host would tell TCP to
> send one byte of urgent data but an incorrect host receiving it would
> think that there are no urgent bytes even though the urgent flag is
> set.
This depends on the interface. With the socket interface in BSD,
this is roughly what you would do. However, a quick check of the code
(based on the Berkeley Net/2 release) suggests that a send of zero octets
with the MSG_OOB flag would in fact cause TCP to set the urgent pointer
to the desired place and to send a segment, which might be empty.
However, whether you would do this also depends on the application.
For example, the BSD rlogin uses "one byte of urgent data", but the
convention with respect to the urgent pointer is different. Looking
at the rlogin "protocol" with respect to the current TCP spec, it looks
very odd (the magic byte is one before the urgent pointer, and is thus
the second-to-last octet of urgent data). But, it is far too late
to change rlogin now (except to replace it with Telnet, of course).
> BTW, did the BSD code ever change to do urgent data correctly? I
> understand that USL also did it incorrectly. Did they ever change?
> What kind of a market does a correct implementation have? What
> percent of the implementations out there will it interoperate with?
> What are the prospects in the long run? I can see where it would be
> difficult for any vendor that supplies an incorrect TCP to change
> since his implementation would not even interoperate with old
> versions of his implementation.
I would argue that the BSD code does urgent data "correctly", for any
definition of "correct" derived from the Internet standards. (For those
who don't know, I maintained the code at Berkeley for many years.)
Note that the Internet standards on this do not include programmatic
interfaces. The use of the socket interface to send urgent data with
TCP is definitely strained, but changing it would break existing applications.
(Sorry, I've been at too many POSIX meetings and it's rubbing off.)
The history of this issue is a problem deriving from the ambiguity
in RFC793, with BSD doing things one way and the Internet standard
going another way, but here we are.
Mike
mins...@wc.novell.com
>Thanks for the info. I still have some questions though. Your
>solution works fine for Telnet if you have control over the
>end sending the urgent data. It also works if you are sending two or
>more bytes of urgent data. It doesn't seem to work if only one byte
>of urgent data is being sent and Telnet is not being used, or if you
>only have control over the receiving end.
My humble suggestion is to work VERY hard trying to convince application
developers NOT to use the urgent data feature of TCP.
The only application which uses urgent data, besides telnet, is a database
application, and my impression is that it has caused that application a
fair amount of grief over the years.
Greg