Markus Stumpf <maex-lists-spam-ietf-asrg(_at_)Space(_dot_)Net> wrote:
On Sat, Dec 20, 2003 at 09:53:35AM -0500, Alan DeKok wrote:
Of course. But the *intent* behind SMTP was to enable two-way human
communication.
Says who?
Says the protocol.
Nearly all protocols on the Internet I know of have the itent to enable
two-way human communication. Even router protocols like BGP do.
Now you're being cute. Isn't that nice.
HTTP, POP3, DNS, LDAP, FTP they all do, just like SMTP does and SMTP does
it in no way more special than any of these,
All those protocols are just like SMTP, so that's why we have so
many protocols, right? They all do the same thing!
e.g. UDP "notification" packets, containing URL's where the
information may be found.
At the time SMTP was designed URLs didn't even exist. UDP was really
unreliable and lines were as flaky as hell.
And nothing on the Net has changed since then. So if, as I said, we
WERE to design such a notification protocol, we would not (of course)
use anything we've learned in the past two decades.
If TCP had a
"protocol" field, in addition to "src/dst port" fields, then a number
of network problems, and application insecurities could have been
avoided.
No. Nothing stops me from abusing the HTTP Protocol like in
POST http://some.mail.server:25/ for SMTP
...
As SMTP, telnet, HTTP operate at another protocol level they don't know
(and need not know) about any fields in TCP/UDP or IP packets.
You've taken my statement exactly backwards. Congratulations!
The point ( to re-iterate) was that TCP would contain information
about the protocol it was carrying. I said nothing about SMTP knowing
about fields in TCP or IP packets. I have no clue how you totally
inverted the meaning of my statements.
When you have nested protocols, each protocol SHOULD contain
information about any sub-protocol it contains. The failure to do so
leads to huge problems when examining network traffic.
I should know. My day job is writing software for multi-protocol,
multi-field, gigabit packet classification, that other people put into
network devices. Issues like TCP ports being loosely coupled to the
protocol in the TCP data are a *huge* problem for anyone wanting to
examine network traffic.
The idea behind protocol stacks should show you that ports or "protocol
fields" don't say *anything* about the data contained, at best they
give information about the encoding and protocol used to transport the
data and thus it is useless.
When your protocol stack gets IP packets with proto TCP, and the IP
data contains something other than TCP, your stack still does
something useful with it? That protocol field has no bearing on how
you treat the encapsulated data?
Nonsense. Have you ever done any work with networks, or protocols?
Alan DeKok.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg