Date: 30 JUL 92 01:00:02 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From: "Ned Freed (Postmaster)" <NED@SIGURD.INNOSOFT.COM>
From: "Ned Freed " <NED@SIGURD.INNOSOFT.COM>
Subject: Re: RFC931 support?
X-Envelope-to: Adelman@TGV.COM, info-multinet@tgv.com
X-VMS-To: IN%"Adelman@TGV.COM"
X-VMS-Cc: IN%"info-multinet@tgv.com"
Organization: The INFO-MULTINET Community

RFC931 is obsolete. There is work underway to replace it with a somewhat
modified protocol. The new protocol is called the "identification protocol".

This functionality is _extremely_ useful in several situations. One that's
near and dear to my heart is logging the identity associated with an
incoming SMTP connection. This can be used to track many of the more obvious
forms of mail spoofing back to their source. Sure, it is nowhere near secure,
but it makes mail forging a matter requiring some technical expertise.
Currently no technical expertise whatsoever is required.

This sort of protocol is also very useful with informal interactive
applications like Internet Relay Chat and TALK. It is also useful for
tracking usage of things like Gopher.

Nobody claims that any of this provides any sort of security or authentication.
It certainly does not. But what it does provide is a reasonable mechanism
for tracking certain types of usage in an informal manner. Often this sort
of tracking is all that's needed, especially when more elaborate and 
provably secure schemes either have substantial cost (either computationally
or financially, take your pick) or have very substantial restrictions
(as in export).

The identification protocol specification, once finished, will become a
proposed standard. In other words, there is significant interest in this
protocol and deployment of it has already reached a point where a standard
for it is needed.

Finally, there is a competing protocol of sorts -- the identification
MIB. This essentially embeds the functionality of the identification
protocol (plus a bit more stuff) inside of SNMP. It is actually an
interesting tradeoff for several reasons. First of all, the identification
protocol is TCP-based, and that means more overhead in terms of setting up
and tearing down connections. (SNMP is UDP based and hence there's no
connection setup involved.) However, SNMP imposes its own sort of overhead
(ASN.1 encode/decode, multiplexed agents, etc.). And insofar as client
code goes the TCP protocol approach is a hell of a lot simpler to do.
But then SNMP is starting to acquire a reasonable security infrastructure...

Anyway, there are a bunch of issues here, not the least of which is the fact
that the development of the identification protocol specification has led
to some really heated debate. (Readers of the IETF mailing list know what
I'm talking about here!) But the bottom line is that this protocol is
going to be popular (actually, it is already), it is going to be heavily used,
it is very useful, and the problems with the protocol name have been
eliminated. If TGV could see their way clear to implementing it it would
save me the trouble of doing it myself ;-)

				Ned

X-Gateway-Source-Info: INTERNET