Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!genrad!decvax!ucbvax!LOUIE.UDEL.EDU!Mills%udel.edu
From: Mills%udel.edu@LOUIE.UDEL.EDU
Newsgroups: mod.protocols.tcp-ip
Subject: Re:  Authentication (was: No more NFS flames)
Message-ID: <8701092241.a029933@Huey.UDEL.EDU>
Date: Fri, 9-Jan-87 22:41:46 EST
Article-I.D.: Huey.8701092241.a029933
Posted: Fri Jan  9 22:41:46 1987
Date-Received: Sat, 10-Jan-87 03:46:41 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 19
Approved: tcp-ip@sri-nic.arpa

Phil,

Yes, you're right; however, my model has rather less weight than yours. It
is intended as a hotpatch that can be dropped into the code at a conenient
place, not require a lot of computation (I assume it to be done in software)
and to done for all UDP and TCP connections for a particular host. A perpetrator
surely can take advantage of the weaknesses of the checksum algorithm whether
encrypted checksums are used or not. I did not intend the simple function I
suggested to fix that - I'd rather fix the checksum algorithm itself. As for
the size of the checksum; well, we could always stuff it in an IP option.
Every time I get going in this vein I drown in the tradeoffs, then try to
remember I only need a lifevest, not a SAR team. Discussion on just how hard
is hard with respect not only to your model and mine, but also with respect to
distributed protocols such as gateway routing protocols and (heaven help me)
network time protocols would be welcome (but not specifics with respect to the
ciphers themselves). I would be glad to summarize comments sent to me at
mills@huey.udel.edu.

Dave