On Sun, Dec 21, 2003 at 10:54:55AM -0500, Alan DeKok wrote:
Says the protocol.
Blah.
All those protocols are just like SMTP, so that's why we have so
many protocols, right? They all do the same thing!
Yes they are all just like SMTP with regard to
*> But the *intent* behind SMTP was to enable two-way human
*> communication.
Read what I write.
And nothing on the Net has changed since then.
Changes are irrelevant. You said it was the design intent with SMTP
otherwise they would have used URLs. This is nonsense as URLs didn't
exist when they designed SMTP.
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.
No, you didn't talk about future protocols or future design, you talk
about the intent of the design of SMTP.
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?
What happens depends on the protocol stack that the sender and the
receiver use. But whether this will be "real" TCP data or something only
decodable by sender/receiver is absolutely irrelevant to the IP stack.
Totally damages TCP data will be transported on IP level from sender to
receiver without and problems and this is good as it is. So setting
a protocol identifier in the underlying protocol may be a nice idea,
but the underlying protocol has to ignore it. It's not its business.
If this is a problem for IDS than this is the problem of the IDS, as it
tries to interpret data that may not be encoded for it to decode. This
is a problem that has always been present for listeners that listen to
data they're not supposed to receive.
Nonsense. Have you ever done any work with networks, or protocols?
You're always so easy with your "nonsense". And it's always easy for you
to try to discredit others by asking them "are you on crack or what?".
Maybe you should simply think before writing all those bullshit.
You just can't stand it if others have a different opinion that doesn't
match your - of course - unfailing point of (limited) view.
When e.g. the ethernet stack gets a frame it doesn't care what the contents
is. The ethernet stack takes the packet, drops the envelope and hands
it off to the next stack. This looks at the content and dispatches it
e.g. to the IP stack handler. This drops the IP envelope and hands it
off to the next handler which decides whether to e.g. dispatch it to
TCP/UDP/ICMP. It is an explicit design goal of protocol stacks that the
higher level protocol doesn't have to know anything about the lower
level protocols to peer communicate with its partner and the lower
level protocol doesn't have to know anything about the
contents/data/encoding of the higher level protocol to transport it.
If the sender and receiver agree on using an UDP ident for TCP stack and
an TCP ident for UDP stack they will communicate perfectly, as will the
underlying and overlying protocols.
So if sender and receiver agree to use the http ports for smtp is the
same thing as if they would agree to use the HTTP ident for SMTP and put
it in the underlying protocol.
Your IDS would choke, just like it would if they'd use port 80 for SMTP.
\Maex
--
SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
proportional to the amount of vacuity between the ears of the admin"
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg