home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / vmsnet / networks / tcpip / multinet / 1830 < prev    next >
Encoding:
Text File  |  1992-07-29  |  3.3 KB  |  66 lines
  1. X-Gateway-Source-Info: INTERNET
  2. Path: sparky!uunet!wupost!usc!noiro.acs.uci.edu!unogate!mvb.saic.com!tgv.com!info-multinet
  3. Date: 30 JUL 92 01:00:02 GMT
  4. Newsgroups: vmsnet.networks.tcp-ip.multinet
  5. X-Return-path: <info-multinet-relay@TGV.COM>
  6. X-RFC822-From: "Ned Freed (Postmaster)" <NED@SIGURD.INNOSOFT.COM>
  7. From: "Ned Freed " <NED@SIGURD.INNOSOFT.COM>
  8. Subject: Re: RFC931 support?
  9. X-Envelope-to: Adelman@TGV.COM, info-multinet@tgv.com
  10. X-VMS-To: IN%"Adelman@TGV.COM"
  11. X-VMS-Cc: IN%"info-multinet@tgv.com"
  12. Organization: The INFO-MULTINET Community
  13. Message-ID: <23805E5230JUL92010002@TGV.COM>
  14. Nntp-Posting-Host: Mvb.Saic.Com
  15. Lines: 49
  16.  
  17. RFC931 is obsolete. There is work underway to replace it with a somewhat
  18. modified protocol. The new protocol is called the "identification protocol".
  19.  
  20. This functionality is _extremely_ useful in several situations. One that's
  21. near and dear to my heart is logging the identity associated with an
  22. incoming SMTP connection. This can be used to track many of the more obvious
  23. forms of mail spoofing back to their source. Sure, it is nowhere near secure,
  24. but it makes mail forging a matter requiring some technical expertise.
  25. Currently no technical expertise whatsoever is required.
  26.  
  27. This sort of protocol is also very useful with informal interactive
  28. applications like Internet Relay Chat and TALK. It is also useful for
  29. tracking usage of things like Gopher.
  30.  
  31. Nobody claims that any of this provides any sort of security or authentication.
  32. It certainly does not. But what it does provide is a reasonable mechanism
  33. for tracking certain types of usage in an informal manner. Often this sort
  34. of tracking is all that's needed, especially when more elaborate and 
  35. provably secure schemes either have substantial cost (either computationally
  36. or financially, take your pick) or have very substantial restrictions
  37. (as in export).
  38.  
  39. The identification protocol specification, once finished, will become a
  40. proposed standard. In other words, there is significant interest in this
  41. protocol and deployment of it has already reached a point where a standard
  42. for it is needed.
  43.  
  44. Finally, there is a competing protocol of sorts -- the identification
  45. MIB. This essentially embeds the functionality of the identification
  46. protocol (plus a bit more stuff) inside of SNMP. It is actually an
  47. interesting tradeoff for several reasons. First of all, the identification
  48. protocol is TCP-based, and that means more overhead in terms of setting up
  49. and tearing down connections. (SNMP is UDP based and hence there's no
  50. connection setup involved.) However, SNMP imposes its own sort of overhead
  51. (ASN.1 encode/decode, multiplexed agents, etc.). And insofar as client
  52. code goes the TCP protocol approach is a hell of a lot simpler to do.
  53. But then SNMP is starting to acquire a reasonable security infrastructure...
  54.  
  55. Anyway, there are a bunch of issues here, not the least of which is the fact
  56. that the development of the identification protocol specification has led
  57. to some really heated debate. (Readers of the IETF mailing list know what
  58. I'm talking about here!) But the bottom line is that this protocol is
  59. going to be popular (actually, it is already), it is going to be heavily used,
  60. it is very useful, and the problems with the protocol name have been
  61. eliminated. If TGV could see their way clear to implementing it it would
  62. save me the trouble of doing it myself ;-)
  63.  
  64.                 Ned
  65. 
  66.