|
|
ARCHIVE: TCP-IP Distribution List - Archives (1987)
DOCUMENT: TCP-IP Distribution List for January 1987 (197 messages, 100868 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1987/01.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: 01-Jan-87 01:48:31-UT From: mills@huey.udel.edu To: tcp-ip@sri-nic.arpa, nsfnet@sh.cs.net Subject: Ask not for whom the chimes tinkle
Folks, Every year it's the same - I forget UT midnight comes five hours before the ball drops in Times Square. For an hour and sixteen minutes after the hoot and holler in Trafalgar Square at least four radiofuzz timetellers still squawked yesteryear. DCN1, UMD1, FORD1 and NCAR springs have now been rewound to 1987 and all you guys can forget those whopping disk-usage refunds. Thanks to Hans-Werner Braun, who reminded me of my annual first duty of the new year and annual first resolution to figure out how to avoid paw to keyboard in the absence throughout the world, as far I know, of a highly reliable electronic way to find out what year it is. Dave -------
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: 1 Jan 1987 12:26-EST From: CERF@A.ISI.EDU To: mills@HUEY.UDEL.EDU Cc: tcp-ip@SRI-NIC.ARPA, nsfnet@SH.CS.NET Subject: Re: Ask not for whom the chimes tinkle
Dave, If you ran all clocks in universal time (GMT) they would all switch years at the same time (Einstein, forgive me). If you need advice as to the time and date according to a given time zone, apply the appropriate conversion locally (at the point of query) when the GMT answer comes back. That's what we finally did with MCI Mail to avoid confusion in our accounting system - everything was GMT internally. Would that help your problem? Vint
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: Thu, 1-Jan-87 15:34:05 EST From: Mills%udel.edu@LOUIE.UDEL.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: Ask not for whom the chimes tinkle
Vint, Every single clock I can reach out and touch, and some others I can bully, ALWAYS tick UT. Fuzzballs would never come within two picofarads of anything local or I would pull their ears off. In fact, there are a few people out there that get mad at me for this hard-line position. Now I can tell my buddies MCI Mail came to the same conclusion. Goodie. The problem occurs because the radio formats do not include the year; so, from first principles a Rip van Winkle waking up with no prior information doesn't know the year. Yes, thee have been numerous suggestions to avoid the problem, but they all use previous state in the file system, collective buddies and so forth. In principle, all it takes is one grand HEMP and the chimes would tinkle for us, no matter who asks. Dave
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: Fri, 2-Jan-87 05:25:58 EST From: hedrick@TOPAZ.RUTGERS.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: Becomming an Internet site
Authorization is required to connect a network to the Arpanet, whether the connection is direct or indirect. More paperwork and time is needed to connect directly to it, but you must register even if you use a friendly local University as an intermediary, or connect to some other network with indirect connections to the Arpanet (e.g. NSFnet). Note that even such indirect connections require your network to appear in the Arpanet's routing tables. I.e. some Arpanet gateway must advertise your network to the core gateways using EGP. Note that it is not just your network that must be authorized to connect to the Arpanet. Individual users who use the Arpanet must be using it for authorized purposes. So when you connect a network to the Arpanet, even indirectly, you are accepting the responsbility to monitor your users and make sure that their use is appropriate.
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: Fri, 2-Jan-87 13:32:07 EST From: farber@HUEY.UDEL.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: Becomming an Internet site
I would suggest that if your company is engaged in Computer Science Research or the support of it, you consider joining many other industrial firms in becoming members of CSNET. Dave Conflict: I Chair the CSNET Exec Committee
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: Fri, 2-Jan-87 14:45:09 EST From: mckee@MITRE.ARPA.UUCP To: mod.protocols.tcp-ip Subject: Re: Ask not for whom the chimes tinkle
>Every single clock I can reach ... never come within two picofarads ... Come now Dave - the capacity of a clock that ticks farads is bound to have an erratic charge; no doubt you meant two mho milli-henries; or is this the sort of pedantic nonsense up with which you will not put. You mentioned the lack of year information in the radio format; what about date info? Do your fuzzballs handle years divisible by 4, 40, and 400; or must we place our (recently abused) trust in the clock czar? Regards - Craig
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: Fri, 2-Jan-87 15:12:37 EST From: Mills%udel.edu@LOUIE.UDEL.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: Ask not for whom the chimes tinkle
Craig, Your current is clear. Millsiamps it is and don't resistor or you'll be rectified. I know when my grid leaks anyway. Fuzzballs leap the years properly, but sometimes don't leap the seconds, as you might know from my experiments previously reported to this list. Time and day-of-year are reliably reported in both US (WWV, WWVH, WWVB) and UK (MSF) broadcasts, but not the year. A "daylight-time" bit is now included (which I consider useless to dangerous), but not advance notice of a leap-second (see NTP in RFC-958). We gotta infiltrate more computer hackers into NBS. Scenario: Martian comes to Earth, asks the year. Whatever you say, he says he doesn't believe you. Think about it. Did Julian's astronomers get the rate right but the date wrong? Think about that, too, and mumble a prayer to the Axioms Peano. Dave
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: Fri, 2-Jan-87 15:19:18 EST From: UUCP@seismo.CSS.GOV@vu-vlsi.UUCP To: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip
Path: vu-vlsi!cbmvax!rutgers!ames!ucbcad!ucbvax!news@seismo.CSS.GOV@sun.UUCP From: news@seismo.CSS.GOV@sun.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8612290824.AA11689@sun.Sun.COM> Date: 29 Dec 86 08:24:26 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 31 App@wved: tcp-ip@sri-nic.arpa Path: sun!gorodish!guy From: guy%gorodish@Sun.COM (Guy Harris) Newsgroups: mod.protocols.tcp-ip Subject: Re: More NFS discussion Summary: OK, what *about* "tmpfile"? Message-ID: <10850@sun.uucp> Date: 29 Dec 86 08:24:25 GMT References: <8612242233.AA06278@cbosgd.MIS.OH.ATT.COM> Sender: news@sun.uucp Lines: 20 > In all this discussion of ways that NFS doesn't quite meet the > "UNIX semantics" (this means "UNIX System V semantics", since > UNIX is a trademark of AT&T and AT&T considers only its own > releases to be UNIX) there is one more gotcha lurking. > > The traditional implementation of (tmpfile) is to make up a name > in /tmp, create the file, keep it open, and unlink it. This works fine > on System V and 4BSD. It probably fails on VMS/Eunice. As far as I'm > aware, it also fails when /tmp is NFS mounted on a remote system. Well, you aren't aware of how the Sun NFS implementation works; it works just fine when "/tmp" is NFS mounted on a remote system. (I just tried it, with "tmpfile" - "tmpnam", actually - modified to use an NFS-mounted file system.) The local kernel knows that the file is open, and instead of unlinking it, it renames it to a temporary name and deletes the temporary file when the last program on the client that created it finishes with it. Yes, this will fail if a process on a *different* machine unlinks it. However, it's difficult for another such process to unlink it under UNIX, since it only has a name for a very short time.
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: Fri, 2-Jan-87 15:19:59 EST From: UUCP@seismo.CSS.GOV@vu-vlsi.UUCP To: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip
Path: vu-vlsi!cbmvax!rutgers!ames!ucbcad!ucbvax!SAPSUCKER.SCRC.SYMBOLICS.COM!Margulies
From: Margulies@SAPSUCKER.SCRC.SYMBOLICS.COM (Benson I. Margulies)
Newsgroups: mod.protocols.tcp-ip
Subject: Submission for mod-protocols-tcp-ip
Message-ID: <861229093712.6.MARGULIES@REDWING.SCRC.Symbolics.COM>
Date: 29 Dec 86 14:37:00 GMT
References: <8612291349.AA17416@seismo.CSS.GOV>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 41
App@oved: tcp-ip@sri-nic.arpa
Date: 29 Dec 86 08:32:06 GMT
From: sun!news@seismo.CSS.GOV
Path: sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Need information on NFS
Summary: Pathname syntax/semantics and file formats are two separate issues.
Message-ID: <10851@sun.uucp>
Date: 29 Dec 86 08:32:06 GMT
References: <8612250637.AA05517@seismo.CSS.GOV> <861225195214.5.MARGULIES@REDWING.SCRC.Symbolics.COM>
Sender: news@sun.uucp
Lines: 15
> Consider TOPS-20 directory structure, VM/CMS mini-disks, file system
> that permit "/" characters in their filenames, or especially file
> systems (like VMS and VM/CMS) that have structured (non-byte stream)
> files. None of them map very quietly into a hierarchical set of
> directories separated by "/" characters, and there are more and harder
> where they came from.
The problem with VMS pathnames has nothing whatsoever to do with the fact
that some operating systems keep file attributes like file format around and
that a certain level of those OSes (not the kernel, in the case of VMS, but
RMS) imposes a certain interpretation of the bytes in the file, based on
these file attributes, on its clients. Those are separate issues; you can
build a system with a VMS-style pathname syntax but with no interpretation
of the file's contents below user-mode code, or a system with UNIX-style
pathnames but with VMS-style file attributes handled by something like RMS.
Indeed. Perhaps if I changed the last sentence to:
"None of them map very quietly into a hierarchical set of directories
separated by "/" characters where all of the files are expected to be
simple vectors of 8bit bytes"
you would like it better. They are separate problems. They are both
hard.
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: 2 Jan 1987 15:27-EST From: CERF@A.ISI.EDU To: Mills%udel.edu@LOUIE.UDEL.EDU Cc: mills@HUEY.UDEL.EDU, tcp-ip@SRI-NIC.ARPA nsfnet@SH.CS.NET Subject: Re: Ask not for whom the chimes tinkle
AAAAAAAGGGGGHH! I'm astonished. Didn't anyone at NBS ever hear of date-time groups for uniqueness? Or should I be blaming some other (date-time) group? Vint
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: Fri, 2-Jan-87 17:38:11 EST From: leiner@ICARUS.RIACS.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: Becomming an Internet site
JOhn, Actually, permission is not needed from DARPA in order to become an internet site; only to have your traffic (in either direction) pass over networks supported by DARPA. What is needed is to be incorporated into the internet addressing structure, which means basically obtaining a network number. Barry ----------
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: Fri, 2-Jan-87 21:26:09 EST From: Mills%udel.edu@LOUIE.UDEL.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: Ask not for whom the chimes tinkle
Vint, International clocks are coordinated by the BIH in Paris, so I suppose they might take a timewarp or to of blame; however, my quarrel is only with the shadowy figures who design the radio-time broadcast formats. Originally we could blame the Inter_Range Instrumentation Group (IRIG), which coordinated the Atlantic Missile Testing Range long, long ago when WWV was in Beltsville, MD, and kept time with eight buried crystal oscillators. The original WWV format as developed by the IRIG and still used, provides 54 bits per minute, but I count only 27 being used in the WWV format (one less in the WWVB format). The day of year takes 23 bits (in BCD!), the UTC-1 correction three and the daylight indicator one. The 23 bits are coded minutes/hours/days in BCD fergawshakes, and this in our age of microcomputers. Now, if the slate could be wiped clean, it should not be hard to include the year, leap-second alert, propagation forecasts, UTC-1 correction, daylight indicator (ugh) and probably lots more, while encoding the whole thing in the same 54-bit frame with some error-correction info to reduce the vulnerability to time-warps, as every Heath clock owner knows. Dave
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Sat, 3-Jan-87 20:58:17 EST From: LYNCH@A.ISI.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: Ask not for whom the chimes tinkle
Dave, Your IRIG time story brings back gorry memories for me. I was a "computor" in the USAF about 20 years ago and the reason we had those ghastly BCD encodings of time was because we humans had to read that time data manually when in debug or panic mode. Have you ever tried to look for a specific time, like 3 PM, in binary milleseconds since anything??? We were grateful for that encoding scheme even though we knew it was wasteful. The bit about not being able to note the change of year was also amusing. Because I was designing a missile tracking system and we did not think the enemy would give us a grace period on New Year's Eve, we had to put in logic to snake around that wraparound so we could track the suckers through the (last?) champaigne toasts. And, oh yes, we even tested that code... Dan -------
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: 3 Jan 1987 20:58:17 EST From: Dan Lynch <LYNCH@A.ISI.EDU> To: Mills@HUEY.UDEL.EDU Cc: tcp-ip@SRI-NIC.ARPA, nsfnet@SH.CS.NET, lynch@A.ISI.EDU Subject: Re: Ask not for whom the chimes tinkle
Dave, Your IRIG time story brings back gorry memories for me. I was a "computor" in the USAF about 20 years ago and the reason we had those ghastly BCD encodings of time was because we humans had to read that time data manually when in debug or panic mode. Have you ever tried to look for a specific time, like 3 PM, in binary milleseconds since anything??? We were grateful for that encoding scheme even though we knew it was wasteful. The bit about not being able to note the change of year was also amusing. Because I was designing a missile tracking system and we did not think the enemy would give us a grace period on New Year's Eve, we had to put in logic to snake around that wraparound so we could track the suckers through the (last?) champaigne toasts. And, oh yes, we even tested that code... Dan -------
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Sat, 3-Jan-87 21:43:20 EST From: tim@cgl.ucsf.edu@hoptoad.UUCP To: mod.protocols.tcp-ip Subject: Re: More NFS discussion
Two comments on PC NFS.
A server side is not made impossible by the OS lack of support for
process-based multi-tasking. If TOPS is any indication, acceptable
performance is possible with a background server design.
Second, floppies were mentioned. Floppies are irrelevant. The average
MS/DOS machine these days has a ten or twenty megabyte internal hard disk,
parts of which might often be made public.
--
Tim Maroney, Electronic Village Idiot
{ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Mon, 5-Jan-87 15:23:41 EST From: PERILLO@SRI-NIC.ARPA (Francine Perillo) To: mod.protocols.tcp-ip Subject: Contacting the NIC
To Charles Bacon: The DDN Network Information Center (NIC) edited and distributes the DDN Protocol Handbook (3 vols.). (The previous sentence uses both the "official" name of the group and the complete title of those big books.) SRI is the official name of the company that houses the NIC. To Jeff Siegal: For information about DDN or Internet access, contact the NIC at 1-800-235-3155 or 415-859-3695. Our information mailbox is NIC@SRI-NIC.ARPA. -Francine /NIC -------
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: Tue, 6-Jan-87 11:08:56 EST From: whna%cgcha.UUCP%cernvax.BITNET@WISCVM.WISC.EDU (Heinz Naef) To: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip
Path: cgcha!whna
From: whna@cgcha.UUCP (Heinz Naef)
Newsgroups: mod.protocols.tcp-ip
Subject: Please put me on the tcp-ip mailing list
Message-ID: <202@cgcha.UUCP>
Date: 6 Jan 87 16:08:54 GMT
Organization: CIBA-GEIGY AG, FO/WIRZ/WRZ, Basel, CH
Lines: 7
Please enter the following symbolic mail address into the distribution list
for TCP/IP related mail/news:
tcpip@cgcha.UUCP
Thanks and best regards,
Heinz Naef
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: Thu, 8 Jan 87 07:34:16 EST From: jqj@gvax.cs.cornell.edu (J Q Johnson) To: arpa.tcp-ip Subject: Authentication (was: No more NFS flames)
In his message earlier this week Joe Pallas did, I think, an excellent
job of clearing the air on SUN NFS. I would, though, be interested in
people's comments on the issues of authentication raised during the
discussion. I had argued that authentication was necessary at the NFS
(or RFS, or whatever) level, not just in the transport mechanism (RPC;
Note that this is the transport *mechanism* required by SMI for SUN
NFS, but that it is not, of course, in the ISO transport *layer*).
Brad Taylor disagreed, arguing that it was natural to place in the RPC
layer those things (presumably including authentication) common to
different RPC applications in the common RPC code.
My position is that in a layered network protocol suite ANY layer is a
candidate for some form of authentication or credentials. As an
example, any file-specific authentication in a remote file system (e.g.
an encryption key, or an account string [perhaps password protected] to
be associated with a file) is necessarily idiosyncratic to the remote
file system, and hence is arguably a proper part of the RFS rather than
the underlying RPC layer.
Arguing the kinds of authentication appropriate to other layers takes
me further out on a limb, but as a first attempt:
physical layer should allow verification of sender's physical
(e.g. Ethernet) address
network/datagram should allow verification of sender's logical
layer (e.g. IP) address
transport/stream should allow verification that all component
layer (e.g. TCP) packets in fact are part of the stream
session layer should allow verification of user ids, etc.
i.e. traditional "login"-style authentication
application layer whatever...
It should be noted that the TCP/IP suite is woefully inadequate in
providing the kinds of authentication I'd like to see possible at the
lower levels of a protocol suite. It is trivial for an intruder with
access to the transmission media to interject false traffic, masquerade
as any host, and even insert data in the middle of a TCP stream (though
that implies that the receiver will probably get 2 different IP packets
with the same sequence number, which might set off an alarm in some
implementations...). In the days when most IP traffic was restricted
to the ARPAnet this was not a problem but nowadays who knows by what
devious paths my packets may wend their way across country?
Note that their are provisions for "security" at the IP level; so far as
I can see they are totally useless. What I have in mind might (?) be
implemented as an (optional) public-key encryption of a packet checksum,
where the public key was distributed along with the network address of
the destination by the domain name server.
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 87 15:18 PST From: Tom Perrine <Perrine@LOGICON.ARPA> To: mills@huey.udel.edu Cc: tcp-ip@sri-nic.arpa, Tom Perrine <Perrine@LOGICON.ARPA> Subject: Re: Ask not for whom the chimes tinkle
WARNING! TIME WARPS AHEAD! Well the chimes sure tinkled for us! On Thursday 8 Jan (1987 A.D.) at about 1400 PST we queried DCN1 as we booted our PWB UNIX system and received a 1986 date stamp! (Gee Mr. Peabody, set the Wayback machine for 1987!) Further investigation shows that DCN6 and GW.UMICH.EDU are also stuck in a time warp. UMD1 seems to be the only un-nostalgic clock. (FORD1 was not reachable.) For now, everyone better keep one eye on the Timex, and another on the packets, and another on the Seiko! Tom Perrine Logicon - OSD p.s. What (Where?) is the previously mentioned NCAR clock/site? I can't find a net address for this place in the NIC host table.
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: Thu, 8-Jan-87 18:18:00 EST From: Perrine@LOGICON.ARPA (Tom Perrine) To: mod.protocols.tcp-ip Subject: Re: Ask not for whom the chimes tinkle
WARNING! TIME WARPS AHEAD! Well the chimes sure tinkled for us! On Thursday 8 Jan (1987 A.D.) at about 1400 PST we queried DCN1 as we booted our PWB UNIX system and received a 1986 date stamp! (Gee Mr. Peabody, set the Wayback machine for 1987!) Further investigation shows that DCN6 and GW.UMICH.EDU are also stuck in a time warp. UMD1 seems to be the only un-nostalgic clock. (FORD1 was not reachable.) For now, everyone better keep one eye on the Timex, and another on the packets, and another on the Seiko! Tom Perrine Logicon - OSD p.s. What (Where?) is the previously mentioned NCAR clock/site? I can't find a net address for this place in the NIC host table.
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: Thu, 8-Jan-87 19:16:51 EST From: Murray.pa@XEROX.COM To: mod.protocols.tcp-ip Subject: What's a repeater, bridge, router, or gateway?
From Rudy: I have yet to hear a solid definition that is not disputed by someone for the terms "gateway", "router", "repeater" and "bridge". It's mailbox housecleaning time. I don't remember seeing a response to this corner of Rudy's message, so here is my 2 cents worth. I believe that the standards groups (ISO, ANSI, IEEE...) have converged upon the following meanings. This is an informal description, and slanted towards ethernets, but the translation to other hardware should be simple. In order of increasing complexity: Repeater: A box that copies each bit of a packet from one segment of a network to another. Thus if you put a scope on several chunks of coax connected by repeaters, you would observe the same packet at the "same" time if you are willing to ingore timing jitter up to several bit times. (On an ethernet, a repeater also has to copy the collision signal in the reverse direction.) It's possible to pry a repeater into 2 halves and connect them somehow, say with a pair of fibers. This gives you wider goegraphical coverage. The ethernet specs, for example, left room in their timing budget for 1000 meters of fiber inside the repeaters. Bridge: A box that selectivly copies raw packets from one one network to another network of the same type. This is reasonable to do, at least in theory, on an ethernet because the first few bytes of a raw ethernet packet contain the destination address, so a bridge that's watching all the traffic on an ethernet can deduce "Aah, host 12345657 is sending packets on segment 13, so it must be connected there and I should copy packets for it from other segments over to segment 13" and add that entry to its tables. There are several interesting ideas in bridges. First, the copy is selective so traffic on each section of the network is reduced from what would happen if you used repeaters rather than bridges. Second, raw packets get copied so this scheme works for all higher lever protocols, even ones that haven't been invented yet. Third, since whole packets get copied, the geographical or timing constraints of the basic physical network can be extended. Bridges can be split just like repeaters. Because of the filtering action, it might make sense to connect a pair of ethernets (10 megabits per second) with a (slower) T1 line (1.5 megabits per second). In theory, connections like this are "invisible" to the software on all the machines on the network so everything should just works fine, and probably does when things are lightly loaded. This isn't the place to go into the complications. Dave Mills has already contributed several war storys to TCP-IP. Router: A box that forwards packets of a particular protocol type (eg IP) from one logical network to another. The networks may be be of different physical types - eg ethernet to ring or arpanet to a phone line. (They can be the same - eg ethernet to another ethernet on a different floor.) In order to forward a packet, a router looks inside the packet to find the destination address, then consults its routing table which is normaly kept up to date by having routers talk to eachother via some routing protocol. Note that it's quite reasonable to have a multilingual router - a single machine that forwards packets for several protocol types - eg IP, Pup, and Chaos. Gateway: A box that translates from one protocol family to another, for example from Asyc RS232 connected to a dumb terminal to IP/TCP/Telnet, or from IP/TCP/SMTP mail to (Xerox) Pup/Grapevine mail. I think that "gateway" is the word responsible for most of the confusion. The Arpanet community (as well as the research corner of Xerox) uses "gateway" to mean what much of the rest of the world would call a "router". When I am being careful, I say "router", "packet gateway" or "mail gateway" in hopes of getting the correct binding. "Bridge" also contributes some confusion since several RFCs and messages refer to "mail bridges". I usually ignore that aspect and don't get burned very often. Another way to look at this mess is "What's a network?" In the ethernet world, a physical segment is a single length of coax. A physical network is several segments connected by repeaters. A logical network makes sense only relative to a particular protocol, and has a single network number. Logical networks have network numbers. Usually there is a one-to-one mapping between physical network and logical network, but things get blurred by subnets and bridges. An internet is a collection of logical networks (all speaking the same protocol) connected via routers. We also need a term for a clump of internets connected by, for example, mail gateways. I'd probably call it a metanet, but I don't think that term is in common usage. (If I get enough/any corrections, I'll collect and summarize.)
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: Thu, 8-Jan-87 21:36:52 EST From: Hans-Werner_Braun@um.cc.umich.edu To: mod.protocols.tcp-ip Subject: Re: Ask not for whom the chimes tinkle
Tom:
GW.UMICH.EDU is NTP synchronized to a bunch of machines and a change in
DCN1's view of the year has noticable impact on the well-behaving of
GW.UMICH.EDU. There is another host on the same machine (WWV.UMICH.EDU)
which is locked on a local WWV clock and which will tell you the right
year. WWV.UMICH.EDU is probably slightly more inaccurate (may be by some
50 msec or so (may be less (infinity in Dave Mills' terms!))) than the
GW.UMICH.EDU time.
I will tell you the NCAR address if you promise not to send TCP/TIME
requests.
-- Hans-Werner
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: Fri, 9-Jan-87 00:16:58 EST From: karn@FLASH.BELLCORE.COM (Phil R. Karn) To: mod.protocols.tcp-ip Subject: Re: Authentication (was: No more NFS flames)
I am also interested in ways to add authentication to TCP/IP. The specific motivation for this is amateur packet radio. FCC rules prohibit encryption per se, though authentication based on cryptographic techniques is okay as long as the actual information content of the message is in the clear. I have therefore been thinking along the lines of adding an option to IP containing an authenticator. This field would be computed only across the data portion of the datagram (i.e., everything past the IP header) since intermediate gateways must be able to modify the IP header. The specific algorithm is open for discussion, but as an initial proposal I would suggest running the data portion of the packet through DES in the cipher block chaining mode, padding out the data to a multiple of 8 bytes with zeros if necessary. Then the final 8-byte ciphertext is put into the IP option. The receiver performs the same calculation and compares its result with the field in the IP header. Any modification or spoofing of the contents of the data field without knowledge of the DES key used to generate the authenticator would result in the received and computed authenticators being different, and the receiver would ignore the packet. Any modification or spoofing of the data field (which includes the TCP header, if TCP is in use) would cause the authentication check to fail. The normal duplicate packet detection facilities already in TCP (or other transport protocol) would protect against "playback" attacks (recording and repeating valid traffic). Basically this is a form of "checksum" or "CRC" with an algorithm complex enough to protect against deliberate attack by humans as well as random attacks from nature. Is the floor open for an RFC on this subject? Phil
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Fri, 9-Jan-87 01:05:53 EST From: Mills%udel.edu@LOUIE.UDEL.EDU To: mod.protocols.tcp-ip Subject: Re: Ask not for whom the chimes tinkle
Tom, [expletive deleted]. From the DCN1 log, it appears some NTP peer came up claiming to be an NTP primary radio clock, but one year off, argued with DCN1 and won. I suspect it happened during the interval immediately following reboot and when the radio clock direclty attached to DCN1 stabilized. Although the year is initialized from the file system during reboot, until the local radio clock engages an broken NTP peer can latch the wrong year. DCN1 has been rebooted maybe once every two weeks, almost always to install software updates. The spoof window lasts maybe a minute. What can I say? Yes, the window can probably be shut. Independent, operational radio clocks are presently at DCN1 (128.4.0.1), UMD1 (128.8.0.1) and FORD1 (128.5.0.1). The new NCAR clock is probably best left alone until the NSFnet Backbone configuration changes have completely stabilized. What these should do is provide up to six NTP "servers" on various campus nets, all slaved to NCAR and will avoid congestion on the network links serving NCAR itself. Dave
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Fri, 9-Jan-87 01:24:44 EST From: Mills%udel.edu@LOUIE.UDEL.EDU To: mod.protocols.tcp-ip Subject: Re: Ask not for whom the chimes tinkle
HW, Unfortunately, Hans-Werner's clock can be spoofed in the same way mine was (both us the same synchronization code). The problem is rather tricky. Every host is told at reboot what year it is and remembers this until told otherwise. Let's assume some j-random glitch comes along and sets the local clock using NTP or even eyeball-and-wristwatch, which causes the year to be changed. Then the radio clock comes up and starts ticking the seconds but using the bogus year. How can you protect against this? The radio clock may never come up. In its absence the local host falls back to NTP and believes what it is told. If it is peering with a sufficient number of other reliable clocks, then the bog should be overcome. However, the fuzzball bog-suppressant code does not yet do all it can in comparing multiple clocks and at the moment of failure had only one other (presumably broken) player. Once again to the breech, dear hearts, and reflect on the fact that nothing is quite so public and excites so many so quickly as a timewarp. Mr. Sulu would understand. Dave
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: Fri, 9-Jan-87 07:32:52 EST From: Hans-Werner_Braun@um.cc.umich.edu.UUCP To: mod.protocols.tcp-ip Subject: Re: Ask not for whom the chimes tinkle
Dave, I don't think this is true for the Heath clock. After all, I don't
have a DATE statement in STARTF.COM as I think you do. This thing needs
to be opened every 31st December in the hours between the time where
UT and local time think that the next day started and a switch gets thrown
to define the exact year (!@#$%^&). While you were able to fix your chimes
from home I had to go to the radio clock and use a screwdriver.
-- Hans-Werner
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Fri, 9-Jan-87 10:26:58 EST From: van@LBL-CSAM.ARPA.UUCP To: mod.protocols.tcp-ip Subject: tcp monitor available for anonymous ftp (long msg)
An incredible number of people have requested my tcp monitor.
It's available via anonymous ftp from host lbl-rtsg.arpa
(128.3.254.68 or 128.3.255.68), file tcpdump.tar. This is
a binary file in Unix tar format (remember to set binary
mode before you ftp it). It contains the program executable,
manual entry, README file and a couple of data analysis awk
scripts. The file is about 100KB. A copy of the README
file, describing the program and giving examples of some
of the things you can do with it, is appended to this
message (and I apologize for the length of this message).
The program runs on a Sun-3 under version 3.2 or later of
the Sun OS. It may run under earlier versions of the system.
It won't run on a Sun-2.
The source isn't available (don't even ask). The program was,
unfortunately, originally based on Sun's etherfind so I won't
distribute it without permission from Sun. It doesn't matter
if you have a Sun source license, we are not an authorized
re-distributor of Sun source. If anyone from Sun is reading
this, it would be nice if you could
- send me a letter saying it's ok to distribute the source, or
- send me a letter saying it's ok to submit the source for the
upcoming Sun user group tape.
If neither of the above is acceptable, maybe I'll just give you
the source and you can figure out what to do with it.
I would appreciate it if someone would post the tar to mod.sources
or any other appropriate redistribution points. I'll be traveling
most of the next month. Please don't send me mail asking if I'll
mail the program to you.
Best of luck using the program. Hope it helps dispel some of the
tcp mis-information and folklore that's been floating around.
- Van
------------------------
Fri Jan 9 05:40:50 PST 1987
This directory contains the binary and manual entry for an
ethernet monitor program, tcpdump. The program runs on a Sun-3
under Sun OS version 3.2 or later (kernel bugs in earlier
versions of the system make it inadvisable to run this program).
The program is loosely based on SMI's "etherfind" although very
little of the etherfind code remains. It was written by Van
Jacobson, Lawrence Berkeley Laboratory, as part of an ongoing
research project to investigate and improve tcp and internet
gateway performance.
The current versions of these files are available via anonymous
ftp from host lbl-rtsg.arpa (128.3.254.68 or 128.3.255.68), file
tcpdump.tar (a Unix tar file). The source to the program is not
currently available (pending distribution permission from Sun).
The author would welcome comments, bug reports, etc. I can be
reached via electronic mail to van@lbl-csam.arpa or van@lbl-rtsg.arpa.
As of this writing, I have a backlog of 6 months of unread mail
(2500 msgs) so don't expect a prompt reply. It is, for all
practical purposes, impossible to reach me by telephone.
The program is copyright (C) 1987 by Van Jacobson, Lawrence
Berkeley Laboratory. You are free to copy and redistribute
it as long as you don't charge for it. If you try to sell
tcpdump or claim that it's yours, I'll sic our overpaid,
underworked lawyers on you.
This directory also contains two short awk programs intended as
examples of ways to reduce tcpdump data when you're tracking
particular network problems. The problem I was looking at was
the bulk-data-transfer throughput of medium delay network paths
(1-6 sec. round trip time) under typical DARPA Internet conditions.
The trace of the ftp transfer of a large file was used as the raw
data source. The method was:
- On a local host (but not the Sun running tcpdump), connect to
the remote ftp.
- On the monitor Sun, start the trace going. E.g.,
tcpdump between local remote and port ftp-data >tracefile
- On local, do either a get or put of a large file (~500KB),
preferably to the null device (to minimize effects like
closing the receive window while waiting for a disk write).
- When tranfer is finished, stop tcpdump. Make a copy of the
tracefile and delete the initial SYN packets and final FIN
packets from the copy (using the editor). While doing this,
make note of the average packet size.
- Use awk to make up the two files of summary data:
awk -f send-ack.awk packetsize=avgsize tracecopy >sa
awk -f packetdat.awk packetsize=avgsize tracecopy >pd
- Do all of the above steps several times, both directions,
at different times of day, with different protocol
implementations on the other end.
- Using one of the Unix data analysis packages (in my case,
S and Gary Perlman's Unix|Stat), spend a few months staring
at the raw and reduced data.
- Change something in the local protocol implementation and
redo the steps above.
- Once a week, tell your funding agent that you're discovering
wonderful things and you'll write up that research report
"real soon now".
In both the awk programs we assume that all packets are about
the same size, the tcp max segment size (a size variation of
about 40% is handled ok). Given this, we can regard the
sequence space as consecutive mss-size "chunks" and can label
each packet by the "chunk" it transports rather than the bytes
it transports. I.e., the packet numbers will be 1, 2, 3, ...
instead of 1, 513, 1025, .... (This simply makes it easier
to spot holes and duplicates, plot different views of the data,
etc.) Keeping this chunking in mind, the awk programs are:
send-ack.awk
Simplifies the tcpdump trace for an ftp (or other unidirectional
tcp transfer). Since we assume that one host only sends and
the other only acks, all address information is left off and
we just note if the packet is a "send" or an "ack". Sequence
numbers are converted to "chunk numbers" by assuming all
packets are about the same size and dividing the start sequence
number by that size.
There is one output line per line of the original trace.
Field 1 is the packet time in decimal seconds, relative
to the start of the conversation. Field 2 is delta-time
from last packet. Field 3 is packet type/direction.
"Send" means data going from sender to receiver, "ack"
means an ack going from the receiver to the sender. A
preceding "*" indicates that the data is a retransmission.
A preceding "-" indicates a hole in the sequence space
(i.e., missing packet(s)). Field 4 has the packet flags
(same format as raw trace). Field 5 is the "chunk
number", essentially the start sequence number divided by
the max segment size (rounded down to the nearest mss).
Send and ack numbers correspond, e.g., "ack 7" is the ack
for "send 7". The number in parens following an ack is
the delta-time from the first send of the packet to the
ack. A number in parens following a send is the
delta-time from the first send of the packet to the
current send (on duplicate packets only). Duplicate
sends or acks have a number in square brackets showing
the number of duplicates so far.
Here is a short sample from near the start of an ftp:
3.00 0.20 send . 7
3.20 0.20 ack . 7 (0.20)
3.20 0.00 send P 8
3.40 0.20 ack . 8 (0.20)
3.80 0.40 * send . 1 (3.80) [2]
3.82 0.02 * ack . 8 (0.62) [2]
Three seconds into the conversation, chunk 7 was sent. 200ms
later it was acked. Shortly thereafter chunk 8 was sent and,
again, it was acked after 200ms. Then, for no apparent reason,
chunk 1 is retransmitted, 3.8 seconds after its initial
send (the round trip time for this ftp was 1sec, +-500ms).
Since the receiver is expecting chunk 9, chunk 8 is re-acked
when chunk 1 arrives.
packetdat.awk
Computes chunk summary data for an ftp (or similar
unidirectional tcp transfer).
A summary line is printed showing the number of chunks,
the number of packets it took to send that many chunks
(if there are no lost or duplicated packets, the number
of packets should equal the number of chunks) and the
number of acks.
Following the summary line is one line of information
per chunk. The line contains eight fields:
1 - the chunk number
2 - the start sequence number for this chunk
3 - time of first send
4 - time of last send
5 - time of first ack
6 - time of last ack
7 - number of times chunk was sent
8 - number of times chunk was acked
(all times are in decimal seconds, relative to the start
of the conversation.)
As an example, here is the first part of the output for
an ftp trace:
# 134 chunks. 536 packets sent. 508 acks.
1 1 0.00 5.80 0.20 0.20 4 1
2 513 0.28 6.20 0.40 0.40 4 1
3 1025 1.16 6.32 1.20 1.20 4 1
4 1561 1.86 15.00 2.00 2.00 6 1
5 2049 2.16 15.44 2.20 2.20 5 1
6 2585 2.64 16.44 2.80 2.80 5 1
7 3073 3.00 16.66 3.20 3.20 4 1
8 3609 3.20 17.24 3.40 5.82 4 11
9 4097 6.02 6.58 6.20 6.80 2 5
This says that 134 chunks were transfered (about 70KB
since the average packet size was 512 bytes). It took
536 packets to transfer the data (i.e., on the average
each chunk was transmitted four times). Looking at,
say, chunk 4, we see it represents the 512 bytes of
sequence space from 1561 to 2048. It was first sent
1.86 seconds into the conversation. It was last
sent 15 seconds into the conversation and was sent
a total of 6 times (i.e., it was retransmitted every
2 seconds on the average). It was acked once, 140ms
after it first arrived.
(The data for this and the preceding example were
taken from a Stanford-to-LBL ftp. As of this
writing, Stanford provides several fine sources of
"interesting" tcp behavior.)
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Fri, 9-Jan-87 13:00:26 EST From: Mills%udel.edu@LOUIE.UDEL.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: Authentication (was: No more NFS flames)
Phil, It's even easier than that. Simply encrypt the existing TCP/UDP checksum, which includes the pseudo-header. Don't bother recomputing it. I have a little toy proposal which might be used to distribute keys. If you would like to see a copy, ftp the file nsa.txt from udel2.udel.edu with anonymous/guest. Dave
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: Fri, 9-Jan-87 13:09:28 EST From: gross@MITRE-GATEWAY.ARPA.UUCP To: mod.protocols.tcp-ip Subject: Re: What's a repeater, bridge, router, or gateway?
> We also need a term for a clump of internets connected by, for example, > mail gateways. I'd probably call it a metanet, but I don't think that > term is in common usage. When discussing a (future) large conglomeration of DoD and ISO nets that might include application level gateways, dual protocol gateways, dual protocol hosts and some form of interoperable DoD/ISO routing, we came up with the term "Teranet". (The greek prefix "tera-" means "so large and malformed as to be monsterous"; as in "teratology- the study of serious deviations from the normal type in organisms".)
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Fri, 9-Jan-87 13:19:38 EST From: Mills%udel.edu@LOUIE.UDEL.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: Ask not for whom the chimes tinkle
HW, You are right, as usual, and I wrote the code. The year is in fact read off the clock and I twitched my screwdriver just like you. I double-checked all the configuration files on all the fuzzies known to me and found the right year in the startup files. The mystery deepens, because now we have to find some player somewhere who has his year wrong and is torqueing via NTP. Distributed algorithms are a gas... Dave
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: Fri, 9-Jan-87 18:03:59 EST From: karn@FLASH.BELLCORE.COM.UUCP To: mod.protocols.tcp-ip Subject: Re: Authentication (was: No more NFS flames)
Just encrypting the existing Internet checksum won't protect against someone monitoring good packets and modifying them in such a way that the checksum is unchanged. This is easy since Internet checksums use a simple linear algorithm; consider that swapping any pair of 16-bit integers within the message leaves the checksum unchanged. Also, since the checksum is only 16 bits, it isn't at all hard to watch the channel and construct a lookup table mapping all 65536 possible checksum values to their encrypted counterparts. The value of the cipher checksum needs to depend in a highly nonlinear and unpredictable (without the key) way on both the values and the positions of bits within the message. It needs an "error extension" property. Cipher block chaining does this. Phil
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: Fri, 9-Jan-87 22:41:46 EST From: Mills%udel.edu@LOUIE.UDEL.EDU To: mod.protocols.tcp-ip Subject: Re: Authentication (was: No more NFS flames)
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
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: Sat, 10-Jan-87 17:31:19 EST From: mills@huey.udel.edu.UUCP To: mod.protocols.tcp-ip Subject: Clocks moving relatively
Folks, Be advised on or about 22 January there will be a configuration change affecting the connectivity of the NSFnet Backbone and client nets, as well as the WWVB radio clock at Linkabit in Vienna, VA. The change results from the rehoming of some DCNET (128.4) hosts and gateways from Linkabit to the University of Delaware and the assignment of a new net MACOMNET (192.5.8) for Linkabit hosts. The physical configuration of the hosts now at Linkabit, including the WWVB radio clock, will remain the same. Only the net numbers will change. Timekeepers ticking with host DCN1.ARPA aka POGO aka DCN-GATEWAY.ARPA at Internet addresses 128.4.0.1 or 10.0.0.111 should re-tick following the cutover with MACOM1.ARPA aka LINKABIT-GW.ARPA at its Internet addresses 192.5.8.1 or 10.0.0.111. Use of the ARPANET address 10.0.0.111 is discouraged, since the clock may be reconfigured in future or moved to another host. Be also advised the TCP/TIME service is to be removed from all fuzzballs at some time in the near future. This service will no longer be advertised in the NIC data base HOSTS.TXT following the cutover. The TCP/DAYTIME, UDP/NTP and UDP/TIME services will continue indefinately. Use of the TCP/DAYTIME service on a regular, recurring basis is strongly discouraged and may lead to discontinuing all TCP-based time services in future. Dave -------
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: Sat, 10-Jan-87 19:03:27 EST From: hedrick@TOPAZ.RUTGERS.EDU.UUCP To: mod.protocols.tcp-ip Subject: secure replacements for passwords
Does anyone know of good replacements for the normal "please type your password" approach to login validation? We're thinking of moving our administrative computing onto a campus-wide network. I'm nervous about having people updating student records on a system that is as easy to tap as the typical Ethernet. Obviously we'd like to prevent people from seeing the data at all. But I'm most concerned with preventing people from changing it. My theory is that once a TCP connection is established, it's likely that no one will be able to break in on it. The gateways and backbone are likely to be physically secure, so any breaking in would have to happen on the local net. I think we can tweak the implementations so that is either impossible or leaves immediately obvious evidence. So what I'd like is a way, once the connection is established, to validate the person who is on it. It strikes me that fairly simple cryptographic techniques should work here. I had in mind something like the host sends me a random number, I ask the user for his password, I encrypt the random number with the password, and send back the results. The host knows the password (This is not Unix, so the password files are not public.), and duplicates the results at its end. The only constraint on the encryption technique is that it has to be able to survive a known plaintext attack on the random number. Presumably that is short enough that any reasonable technique (DES?) would work, as long as we choose the passwords. Obviously if the user chooses the passwords, the space of passwords will be so small that it would be easy to search. Does this seem reasonable? Anybody have a better idea? I'm looking for something that I can practically implement myself. Probably all access with be a micro running pc/tn3270, when it becomes available, and the mainframe will be running the UCLA MVS TCP/IP code. I'm looking for something I can hack into that software. Also, it would be sort of nice to encrypt the data itself. Does anybody know whether this is practical? My feeling is that it might be worth coming up with a random bit stream once for each connection and just XOR'ing all the data with it. Of course this would be a sitting duck for known plaintext attack, but at least it would require some work to see what was going on. The security against change would not depend upon this, but upon the security of the connections and the password mechanism. This would be designed simply to discourage casual wiretapping. I know nothing I'm going to come up with is going to prevent the NSA from finding out our student grades. But what bothers me is the common approach that because the perfect is unobtainable, we do nothing. What I'd really like to do is to get something that is at least as secure as locking your gradebook in your desk and then locking your office door. There are obviously many people on our campus who can get past those locks. But there is still a difference between using the locks and leaving the grade book out on a coffee table in a public lounge.
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: Sat, 10-Jan-87 21:05:09 EST From: weltyc%cieunix@CSV.RPI.EDU.UUCP To: mod.protocols.tcp-ip Subject: Ask not for whom the chimes tinkle
>You are right, as usual, and I wrote the code. The year is in fact read off >the clock and I twitched my screwdriver just like you...... Isn't it funnay how things like this happen... Right after I got this message I saw the following "fortune" when I logged out: "Beware of programmers carrying screwdrivers" Hmmm. perhaps I should notify the police... -Chris
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: 10-Jan-87 22:20:04-UT From: mills@huey.udel.edu To: tcp-ip@sri-nic.arpa, nsfnet@sh.cs.net Subject: Clocks moving relatively
Folks, Be advised on or about 22 January there will be a configuration change affecting the connectivity of the NSFnet Backbone and client nets, as well as the WWVB radio clock at Linkabit in Vienna, VA. The change results from the rehoming of some DCNET (128.4) hosts and gateways from Linkabit to the University of Delaware and the assignment of a new net MACOMNET (192.5.8) for Linkabit hosts. The physical configuration of the hosts now at Linkabit, including the WWVB radio clock, will remain the same. Only the net numbers will change. Timekeepers ticking with host DCN1.ARPA aka POGO aka DCN-GATEWAY.ARPA at Internet addresses 128.4.0.1 or 10.0.0.111 should re-tick following the cutover with MACOM1.ARPA aka LINKABIT-GW.ARPA at its Internet addresses 192.5.8.1 or 10.0.0.111. Use of the ARPANET address 10.0.0.111 is discouraged, since the clock may be reconfigured in future or moved to another host. Be also advised the TCP/TIME service is to be removed from all fuzzballs at some time in the near future. This service will no longer be advertised in the NIC data base HOSTS.TXT following the cutover. The TCP/DAYTIME, UDP/NTP and UDP/TIME services will continue indefinately. Use of the TCP/DAYTIME service on a regular, recurring basis is strongly discouraged and may lead to discontinuing all TCP-based time services in future. Dave -------
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: Sun, 11-Jan-87 08:35:00 EST From: NS-DDN@DDN2.UUCP.UUCP To: mod.protocols.tcp-ip Subject: Password Security for the UCLA ACP
I heard of a fascinating alternative to standard access validation which may be right up your alley. Instead of a password, the user is presented with five random numbers and asked to compute the result using his secret access validation algorithm. Traces and taps will only show a plaintext response to the specific access request. The algorithm is not apparent unless many accesses are traced and analyzed. A good algorithm mechanism would support conditionals; e.g., If 3rd number is odd, then result is 4th number minus 5th number, else result is 1st number times 1st number plus 2nd number. While this is complex, it avoids the overhead of DES (I shudder to think what that would do to the ACP's resource consumption). The ICT ACACCESS module (invoked via the PACCESS macro) is not designed to work this way since it assumes it is merely interfacing to an MVS security package which is password-driven. Worse still, the commutator is not party to TCP and VTAM sessions; hence, it cannot solicit the userid, prompt for the result, and capture the result. Consequently, implementation of this idea cannot be easily be centralized within the PACCESS service. There is no standard routine for solicitation of the userid/password. I would suggest adding an A-service to provide a common solicitor routine which would be knowledgeable of both TELNET and VTAM connections to deal with each appropriately. Then modify the modules which obtain this information to use the A-service instead. Another problem with this would be the creation of an access table containing each user's id, privileges, and algorithm. This should be part of ACACCESS. PACCESS and ACACCESS would have to modified to expect six numbers (the prompted five and the user's response) instead of the existing eight-byte password. Be very careful with enhancements to the commutator! While this is not a trivial enhancement, I believe it would serve your needs (and maybe ours, as well). Best regards, Dave Craig Network Solutions, Inc.
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: 11 Jan 87 08:35 EST From: NS-DDN @ DDN2 To: hedrick @ TOPAZ Cc: tcp-ip @ SRI-NIC Subject: Password Security for the UCLA ACP
I heard of a fascinating alternative to standard access validation which may be right up your alley. Instead of a password, the user is presented with five random numbers and asked to compute the result using his secret access validation algorithm. Traces and taps will only show a plaintext response to the specific access request. The algorithm is not apparent unless many accesses are traced and analyzed. A good algorithm mechanism would support conditionals; e.g., If 3rd number is odd, then result is 4th number minus 5th number, else result is 1st number times 1st number plus 2nd number. While this is complex, it avoids the overhead of DES (I shudder to think what that would do to the ACP's resource consumption). The ICT ACACCESS module (invoked via the PACCESS macro) is not designed to work this way since it assumes it is merely interfacing to an MVS security package which is password-driven. Worse still, the commutator is not party to TCP and VTAM sessions; hence, it cannot solicit the userid, prompt for the result, and capture the result. Consequently, implementation of this idea cannot be easily be centralized within the PACCESS service. There is no standard routine for solicitation of the userid/password. I would suggest adding an A-service to provide a common solicitor routine which would be knowledgeable of both TELNET and VTAM connections to deal with each appropriately. Then modify the modules which obtain this information to use the A-service instead. Another problem with this would be the creation of an access table containing each user's id, privileges, and algorithm. This should be part of ACACCESS. PACCESS and ACACCESS would have to modified to expect six numbers (the prompted five and the user's response) instead of the existing eight-byte password. Be very careful with enhancements to the commutator! While this is not a trivial enhancement, I believe it would serve your needs (and maybe ours, as well). Best regards, Dave Craig Network Solutions, Inc.
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Sun, 11-Jan-87 09:38:20 EST From: LYNCH@A.ISI.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: secure replacements for passwords
Charles, I hope Brian Reid at DECWRL reads this list as he has dealt with this problem at STanford and, as you note, no one has done anything yet to at least put up a line of defense for "us nice citizens who once in a while get tempted". Your concern in advance is commendable. I have been secretly worring about "security" of internetworking for a long while now because I fear the backlash when the first big "thefts/damages" happen and the world finds out how spartan our security features are. I have worked in the security arena long enough to know that anything that one comes up with as a protective measure can be countervailed. It is only a matter of the price one is willing to pay. So, please, some of you out there who know of some reasonable barriers to tampering on campus LANs, give Charles some feedback on his request. Thanks, Dan -------
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: 11 Jan 1987 09:38:20 EST From: Dan Lynch <LYNCH@A.ISI.EDU> To: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Cc: tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU Subject: Re: secure replacements for passwords
Charles, I hope Brian Reid at DECWRL reads this list as he has dealt with this problem at STanford and, as you note, no one has done anything yet to at least put up a line of defense for "us nice citizens who once in a while get tempted". Your concern in advance is commendable. I have been secretly worring about "security" of internetworking for a long while now because I fear the backlash when the first big "thefts/damages" happen and the world finds out how spartan our security features are. I have worked in the security arena long enough to know that anything that one comes up with as a protective measure can be countervailed. It is only a matter of the price one is willing to pay. So, please, some of you out there who know of some reasonable barriers to tampering on campus LANs, give Charles some feedback on his request. Thanks, Dan -------
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: 11 Jan 1987 14:55-PST From: STJOHNS@SRI-NIC.ARPA To: LYNCH@A.ISI.EDU Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: secure replacements for passwords
I'd like to remind all of you to be careful when addressing the subject of network security on this mailing list. General problems are OK for discussion, while specific instances or attack are not. I realize this is skirting the issue and may in the final analysis give us no protection at all, but it may give us some breathing space to address the problems/solutions. (BTW, I come from the old Multics community where the main security maxim was "Security through obscurity is no security at all") Lastly, those of you who have "security incidents" can address questions and requests for help to DDN-NSO@SRI-NIC.ARPA or USNail Maj Steve Rudd, DCA Code B652, Washington, DC 20305-2000. (I realize the above really has no relationship to the subject I am replying to, but it looked like the discussion might be heading in that direction) Mike (DDN-PMO, Code B612)
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: Sun, 11-Jan-87 16:37:50 EST From: Murray.pa@XEROX.COM To: mod.protocols.tcp-ip Subject: Re: secure replacements for passwords
As long as you can work on the software at both ends, then your goals are reasonable. Needham and Schroeder published a scheme back in '78. Check out the Dec '78 CACM. The basic idea you are looking for is pretty much the following. The user calls the server, and sends his claimed identity (username) in the clear. The server picks a random number and a session key, encrypts them with the users password and sends them back to the user. The user decrypts them, and uses the session key to encrypt the random number and sends that back to the server. DES will eat a lot of cycles if you do it in software. That's not a problem if you only use it for authentication, but if you are encrypting everything going to/from a terminal session, response will probably be unacceptably slow. Micros are getting pretty fast these days. Check it out. You might just make it. (Sorry I don't have any numbers handy.) I strongly suggest a physically separate network for administrative work. Don't even connect it to the rest of the world via any gateways. This transforms the problem back into physical security. Most administrative people understand that. In any case, it becomes their problem and you (we?) can't get a black eye because some tricky point got overlooked. Keep in mind that observing terminal traffic is just the tip of the iceberg. As your users get more sophisticated and upgrade to more powerful machines, you will have to worry about printing things directly from a workstation, swapping to remote disks, remote debugging sessions, and strange new things that nobody has even imagined yet. Our administrative people upstairs have their own ethernet (and printer and file server and ...).
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: Mon, 12-Jan-87 10:26:00 EST From: JSLove@MIT-MULTICS.ARPA.UUCP To: mod.protocols.tcp-ip Subject: Re: secure replacements for passwords
Both TELNET and FTP-CONTROL (not FTP-DATA) sessions use the TELNET
protocol, so you could do some password protection in that layer. For
example, if the TELNET turns off echoing, you could turn on encryption,
which would protect a password (and also emacs sessions, but you could
deal with that separately). You could define negotiations to turn some
form of data protection on and off.
The alternative is to invent new protocols for login, file transfer and
so on. This has been done already for Unix (at least in part), so specs
and implementations exist of protocols which dispense with the normal
login dialogue for user authentication. You will probably have to
design and implement your own authenticator.
I recommend against keeping a cleartext password file. Even if it is
secure, scramble the passwords. You can use the scrambled passwords as
encryption keys. Since the password will be supplied to the
authentication server scrambled by another key, the initial password
scrambling (when new passwords are set) might be done at the
authentication server as well.
In your login dialogue, start out using a key used by that
workstation-server pair. Scramble the userid with this key (K1) so that
a listener can't easify find out who owns the connection. The server
will unscramble it and look up the user. Then the server will send back
a session key and a random number, encrypted with the userid and
workstation-server keys. The workstation will decrypt this and ask the
user for a password. It will then scramble the password, and encrypt
the random number with the session key and the scrambled password as
keys, returning the result to the server. The server checks the
returned random number after decryption.
The session key is remembered for use during the session by operations
which require a high degree of protection, such as changing passwords.
However, it would probably use DES or some other form of encryption
which might be too expensive to use on all traffic. I believe there are
network interfaces available for some machines which will encrypt your
entire packet with special hardware, but they may make it difficult to
communicate with any machine which doesn't have exactly the same
interface hardware.
For regular traffic, there are cheap forms of encipherment which will be
better than using the same XOR string for every connection. For
example, you could use a character translate table, which is harder to
break than an XOR mask. Don't use the same table for every byte. You
could cycle between several, or you could select which table based on
some more complex algorithm. For example, if you had 64K of table
space, you could use the previous byte to select the translation. You
could have a circular list of tables and step to the next table using
the modular addition of the current table index and the previous
character.
This is certainly breakable in principle, but it is cheaper than
software DES. Each translate table must be isomorphic (invertible) but
no relationship need exist between multiple tables. The tables could be
mechanically generated and changed often, perhaps being distributed over
the network in encrypted form. Encipherment would be done only on the
byte stream, so it probably could be implemented outside the operating
system kernal or without changes deep within the TCP/IP.
Rather than partition the network physically, consider an implementation
based on IP security options in the IP headers. This would be enforced
by the gateways. An IP gateway must be present between the ethernets
which have sensitive traffic and the rest of the internet. The gateway
would refuse to pass packets off the sensitive network which contained
the security option. Ideally, the hosts on the sensitive networks would
place the security options in the packets. If that isn't feasible, the
gateways could. Consider a campus network with subnets A, B, C, D and
E:
B D
\ /
A---C
\
E---ARPANET
Subnets B and D belong to the administration. The AB gateway passes
packets from A to B only if the have the security option, and passes
packets from B to A adding the security option to the IP header.
Gateway CD has similar behavior. Gateway AC ignores the option.
Gateway CE refuses to pass in either direction packets which contain the
security option. (This description has been simplified for pedagogical
purposes so much that it resembles "community of interest" routing,
which is also a possibility, but which is more limiting.)
Subnets A and C must be physically secured just as networks B and D.
However, they can carry traffic from unsecured subnets. It is desirable
for backbone networks to be able to carry traffic from all subnets. The
AB, CD and CE gateways must be secured from tampering, but anyone on
subnet E or other networks connected to it will be completely unable to
send packets to or receive packets from subnets B and D.
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: Mon, 12-Jan-87 10:34:08 EST From: ron@BRL.ARPA (Ron Natalie) To: mod.protocols.tcp-ip Subject: Re: Password Security for the UCLA ACP
Of course the problem with this is that the users who are likely to be using a Unversity Administration system aren't likely to be able to deal with too hard an algorithm and a Ethernet wiretapper probably could deduce it over a period of time. The only way I can think of getting around it is to use a PC or some other semi-smart device as the user terminal and encrypt some or all of the authentication information. It's really the same idea, except that the terminal has most of the smart algorithm in it, the user just has some key. -Ron
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: Mon, 12-Jan-87 10:41:10 EST From: PADLIPSKY@A.ISI.EDU To: mod.protocols.tcp-ip Subject: FTAM Implications Wrap-up (Maybe)
Several messages were exchanged "off to the side" recently on the
FTAM Implications topic that I thought would be of interest (and
maybe even amusement) to all readers, so with Marshall Rose's kind
concurrence (which induced me to leave the last word with him...for
now), here they are:
[First he wrote (in reference to my public msg that contained the
observation that you can't do Top-down and Bottom-up simultaneously):]
2-Jan-87 12:28:36-EST,776;000000000001
Return-Path: <mrose@nrtc-gremlin.arpa>
Received: FROM NRTC-GREMLIN.ARPA BY USC-ISI.ARPA WITH TCP ; 2 Jan 87 12:25:24 EST
Received: from nrtc-gremlin by nrtc-gremlin.arpa id a015756; 2 Jan 87 9:24 PST
To: PADLIPSKY@a.isi.EDU
Subject: Re: "FTAM" Implications
In-reply-to: Your message of 30 Dec 86 10:42:00 -0500.
Date: Fri, 02 Jan 87 09:24:28 -0800
Message-ID: <15752.536606668@nrtc-gremlin.arpa>
From: Marshall Rose <mrose@nrtc-gremlin.arpa>
Nah. It just says that you can't do it all at once unless there are
timely communication between groups. If they all could have met at say,
NY, for a week, the problem would have been done. I put more blame on the
FTAM people for just not waiting for the presentation people to finish,
than anything else.
/mtr
[And then I wrote (with a sentence more at the end about including
his msg that I've deleted here since it made more sense to put his
msg first in this context):]
Marshall--
Rats. Here I went to all the trouble to compose the semielegant
bit of technicoaesthetic righteousness below and then when I
was in the midst of sending it I discovered that the msg I was
responding to was a private aside, not one you'd sent to TCP-IP.
If you think it would be amusing, do feel free to send it along
to the list anyway, with this preface on it so readers will know
there are no hard feelings going around (at least, I assume there
aren't).
cheers, map
I can't agree that the mismatch between what ISO FTAM needed and
what ISO Presentation offered can be passed off as just a peccadillo.
After all, on a practical level people apparently did waste time,
energy, and funds implementing to the DP in the unfullfilled but not
unreasonable expectation that the committee had "done its homework"
properly, and on a theoretical level the fact that the mismatch
happened at all still strikes me as being Wrong. Perhaps I was
too concise in my last msg, though, as to the reasoning, so as
one last shot in my current mini-salvo on the theme that Going
ISO Is Throwing Bad Money After Good (a brand-new Slogan), let's
try looking at it this way:
In the zeroth place, the designers of _any_ "Application" protocol
ought to be the best judges of what they need to virtualize. (If
they aren't, they shouldn't be the designers.) Therefore, they
shouldn't be expected/required to depend on whatever primitives
the Presntation committee happened to deem appropriate in the first
place. In other words, it's wrong to think of L6 as a monolith;
it should be a repository of the virtualizations dictated by the
L7 protocols that need them. Indeed, L6 is only defensible as
a separate layer at all because making it one might happen to
force modularity on the functions it offers; even that view assumes,
however, that there wouldn't be the desired modularity if there
were no layer boundary between the control and virtualization aspects
of an L7 protocol, and that doesn't have to be the case. We needn't
waste time on FTP's using Telnet on its control connection here, but as
things stand, L6 seems to be being treated as the de facto fiefdom
of its committee, and this amounts to letting non-carpenters dictate
the contents of the carpenters' toolboxes for all L7 carpenters,
not just FTAM.
That, without boring everybody, is a bit more on the It's Level [sic]
5-7 charge. Now to expand a bit on the other, related charge.
The relevant Slogan, assuming almost nobody ran off to find p. 215 of
The Book (especially since I didn't even bother to cite the page
last time) goes as follows:
The more layers, the more committees--
A bureaucrat's dream of the Feudal.
The more committees, the more disparities--
An implementor's nightmare of the futile.
That is, I take the FTAM misadventure to be evidence that it's
even worse to view a layer as a fiefdom than it is to view it
as a monolith. My vague understanding of "CASE" is that it wouldn't
have been invented if L6 hadn't "belonged" to the L6ers: another
case related to the FTAM one. But that's only a problem with
Presentation's being tardy, according to Marshall, or a problem that
would go away if L7ers could dictate what went into L6 (or even if
there were no pretense that 6 and 7 were different) according to
me. The real nastiness of the Layer-as-fiefdom psychology, it seems
to me, is exposed when you look at the deliberations of the
Reference Model Security Appendix committee. Two of them have
told me independently that the Security Appendix will call for the
vesting of _no_ security functionality in L5 (the "Session" level),
because--to paraphrase--there's nothing useful in the current L5
protocol (DIS or IS or whatever status it's reached). When you stop
and think that many approaches to "security" _require_ that audit
trails be kept on a per-session basis, I submit you should realize that
it's ludicrous for their approach to Security to have nothing to do
with their Session layer. What I think is happening is that, once
again, a committee's layer/"turf" if being viewed as sacred, and
it it gets things wrong the Reference Model gets distorted rather
than the layer/protocol gets fixed.
Now, not only don't I want this to go on too long, I also really
_don't_ want it to turn into "anything personal" with regard to
Marshall (whom I don't even know, and who probably isn't an ISORMite
in TCP-IPer's clothing to begin with), but my bottom line for all
this is that I think the recruiting poster we were originally
shown (when he said that FTAM looked like a good alternative to NFS)
turns out to have, when looked at under a magnifying glass, little
pictures of atrocities being committed in the background; if anybody
wants to join such an army, I can't stop them, of course--though I
do hope they won't do their campaign planning on TCP-IP. (Note that
I'm not saying I'm _for_ NFS, just against FTAM.) (Note also that
I'm not challenging his right to have shown the recruiting poster,
just what I take to be the implications of the poster.)
As a reward to those who have waded through all the metaphors, I'll
climb off the soapbox for now ... provided I don't have to rebut
the rebuttal, of course. (Which I hope and trust won't prove
to be necessary, since I should certainly be entitled to call
what I take to be Bad Art, Bad Art--which is really what all this
has been about, in some sense.)
[And finally he wrote:]
9-Jan-87 16:59:53-EST,2214;000000000001
Return-Path: <mrose@nrtc-gremlin.arpa>
Received: FROM NRTC-GREMLIN.ARPA BY USC-ISI.ARPA WITH TCP ; 9 Jan 87 16:57:16 EST
Received: from killer-rat by nrtc-gremlin.arpa id a013062; 9 Jan 87 13:56 PST
To: PADLIPSKY@a.isi.EDU
Subject: Re: "FTAM" Implications
In-reply-to: Your message of 08 Jan 87 16:21:16 -0500.
Date: Fri, 09 Jan 87 13:56:31 -0800
Message-ID: <15141.537227791@nrtc-gremlin.arpa>
From: Marshall Rose <mrose@nrtc-gremlin.arpa>
Mike - if you want to redistribute our last few messages back to
TCP-IP, fine with me. In response to your last message:
Since neither of us were on the two committees in question, it's
not really enlightening to second-guess why they did what they did.
However:
All ISO DPs are clearly marked as being subject to radical change.
If vendors want to implement the DP FTAM, then they do so at their
own risk. I imagine that they would do so just to say "We have an
FTAM" in order to scoop the market. Rather silly from the technical
viewpoing actually. From having observed the way standards bodies
operate, I know that unless a DP is based on some other existing
standard (e.g., a fully fleshed-out ECMA or ANSI contribution), that
the DP will change dramatically when it goes to DIS.
One observation I will make is, recently at a TCP/IP conference, a
speaker noted something to the effect that "the lack of
interoperability with TCP/IP offerings is what is pushing ISO
forward". My experience is quite the reverse: nothing has pushed
the acqusition of TCP/IP in the corporation I work for more than the
fact that ISO isn't ready yet (and the fact that if you look deep
enough through the sales glossies, you can figure that out).
As to the ISO poster: it's hard to argue with you, since I don't
like committees in general. As far as turf wars and all that
nonsense goes, the more I understand the ISO model, the more I like
it. I tend to like the final form of things more than the inital
stuff. So the security draft, for example, is a WD (working draft),
I believe, not even a DP. I'm ignoring it!
/mtr
-------
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: Mon, 12-Jan-87 11:18:44 EST From: mckee@MITRE.ARPA (H. Craig McKee) To: mod.protocols.tcp-ip Subject: Re: secure replacements for passwords
Charles Hedrick I suggest you review DoD Password Management Guideline (CSC-STD-002-85), 12 April 85. The Guideline was developed by the Computer Security Center, Ft. Meade, Maryland 20755. The point of contact is the Office of Standards and Products, Attn: Chief, Computer Security Standards. (If you like I'll make a copy and mail it to you.) The Guideline offers many recommendations, two of which follow. The password should be a three-word phrase, because it is easier to remember, rather than a random string of characters. The words are drawn randomly from a dictionary of at least 2000 words. The passwords should be encrypted; thus, the clear text form of the password exists only in the mind of the user, and very briefly in the memory of the host. Regards - Craig
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: Mon, 12-Jan-87 16:56:31 EST From: geof@decwrl.DEC.COM@apolling.UUCP (Geof Cooper) To: mod.protocols.tcp-ip Subject: Re: secure replacements for passwords
> My theory is that once a TCP
> connection is established, it's likely that no one will be able to
> break in on it....
I'm not sure you'll have enough secure pieces. All networks
traversed by packets that are part of the "secure" tcp connection must
be physically secure. Otherwise, it is easy to interpose data into a
TCP connection and monitor the result.
For example:
Monitor the connection and wait until it has been idle for some time
(around lunch time, so the user is probably not looking at the terminal).
Then spoof the server into receiving a packet with a particular input
command in it. Examine the data that results. Then spoof a packet that
causes the server to clear the screen. Note that the legit TCP client
will merrily receive all the data. I wonder if it will get upset that
the ACK numbers are too high... I'd bet few TCP's would.
When the legit user returns, he/she will type a bit with no results
(since the server will ignore those packets). Eventually things will
start working again, and he/she will probably just think it a magical
glitch and not report the problem.
The idea of Needham/Schroeder authentication is the best way to go. One
option in the scheme was to have the encryption key for the next packet
in this packet, so the above kind of spoofing would be hard (and would
certainly be detected at the legitimate receiver).
Needham/Schroeder doesn't assume that DES is used (as I remember, certainly
there is no need for them to make that assumption). You can
increase the work factor needed to spoof the system sufficiently by just
XOR-ing passwords into the datastream. I would think that this would be
"enough security" for a campus environment for the next few years.
- Geof
PS: On further consideration, you could probably get around TCP spoofing by
just arranging to never leave a connection idle for more than 30 seconds or so.
If the system dis- and re-connected to the server automatically, the
users probably wouldn't rebel. - GHC
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: Mon, 12-Jan-87 18:44:29 EST From: yerazuws@CSV.RPI.EDU (Crah) To: mod.protocols.tcp-ip Subject: Re: secure replacements for passwords
In article <8701111745.AA01536@ucbvax.Berkeley.EDU>, LYNCH@A.ISI.EDU (Dan Lynch) writes: > So, please, > some of you out there who know of some reasonable barriers to > tampering on campus LANs, give Charles some feedback on his request. > Here at RPI we have a relatively tamperproof LAN system - but it wasn't meant to be that way. For example, Professor A gets a pair of Sun 2's. One diskless Sun goes in his office up on the sixth floor, and the fileserver goes down in the basement lab. A piece of Ethernet goes in between them. Then Center for XXX gets in a flock of uVAXen and puts them on an Ethernet. Different piece of coax, of course. Then Center for YYY interconnects their MV10000 and their /780's and a couple of GPX's - on yet a third Ethernet. All of these Ethernets coexist physically in the same building, run down the same cable trays, etc. But they're all physically separate and since the watchword is cost - there are NO bridges/gateways. You see, who pays for the gateway? What "added value" is there in a gateway? Ah, you say that XXX and YYY should have gone on A's cable? Well, A already paid for that cable and it's his bandwidth and he doesn't want to clog down his diskless SUN 2 with all that DECnet traffic (which, having used a diskless Sun 2, I do not blame him at all for. I wouldn't either, if I had any way to avoid sharing that cable.) But XXX and YYY should have used the same cable? Then who pays for it? Each center has to bill out expenditures. So, financially speaking, it isn't reasonable for either party to put in some LAN that it isn't going to use. Or that might need to be upgraded because a "sharing" arrangement is overloading the LAN. Now you say "Why not at least install bridges/gateways"? Again, who pays for it? So there are no gateways. Instead, each machine has one or two RS232 lines to a data switch. At 9600 baud. You dial out and tell the data switch where to connect- and then you log in there. Meanwhile, those three Ethernets sit there, safe and protected from the "other" guy. Forgive the sarcasm and the flames, dear reader. But restricting use of a LAN (or access to bandwidth on a broadband system) may be what you want, although it pretty much negates the usefulness of the LAN in the first place. I'd personally advise against such physical protection systems where the stakes are low (How much can a college campus net intruder get for his trouble? Ten grand maybe, at best?). If the stakes were higher (like a case of national security) I'd say this is the way to go. Hang the multiple Ethernet coaxes or fiber optics along the ceiling in the middle of a patrolled hall and NOBODY is going to get to it without much pain. What it boils down to is that you can have security, or you can have a useful LAN, or you can go crazy. Those are your options. -Regrets for the depressing truth... Bill Yerazunis
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: Tue, 13-Jan-87 00:58:34 EST From: mills@HUEY.UDEL.EDU To: mod.protocols.tcp-ip Subject: How sweet it is
Folks, Mike Petry, fierce swamprat from U Maryland, staggered from the muck waving an ACC 5250 X.25 interface driver in one hand and dragging an awesome alligator in the other. Shortly before he passed out (the swampgas was just too much - he began to see UFOs) he whispered "only ten keystrokes did the varmits in." I rushed to the ooze and tossed a ping raft between dcn-gateway (56-Kbps 1822/ECU 10.0.0.111) and terp (56-Kbps X.25 10.8.0.111) and reeled in 5000 packets of catfish, a possum and two owls. The swamp never smelled so good. Relative to my gruesome scatter plots mentioned previously to the list, the X.25 circuit has much joy. The Sun-format bitmap file is on udel2.udel.edu under anonymous/guest as terp1.bit, should you care to light it up. The max delay was almost five seconds, but only five samples were more than two seconds. The regression line had a y intercept of 32 and 576-octet intercept of 238, for a slop of 22411 bps, about to be expected for the two-hop dcn-gateway PSN 111 terp path. Mike tells me the problem was a simple bug in the driver, so I suggested he set a reasonable price for ransome at just $500 per keystroke. Comes to one 5250, unless you can find a ripoff in Filene's basement basement. I don't know about you guys, but I am mighty relieved and would like to be one of the first to throw Mike a towel so he can wipe off that icky, smelly swamp stuff and take a bath. Dave -------
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: Tue, 13-Jan-87 05:08:43 EST From: van@LBL-CSAM.ARPA.UUCP To: mod.protocols.tcp-ip Subject: Re: Analyzing Acknowledgement Strategies
Craig -
I tried to do some work on analytic models of transport
protocols a couple of years ago. I have kept watching but
haven't found much in the ARQ literature that reflects realistic
protocol implementations. There were 6 or so papers whose
*method* looked like it could be adapted to the analysis of TCP
or RDP. Two that I kept in my "potentially useful" file were
Easton's "Batch Throughput Efficiency of ADCCP/HDLC/SDLC
Selective Reject Protocols", IEEE COM-28, No.2, Feb, 80, and Wai
Sum Lai's "Analysis of Piggybacking in Packet Networks", (this
was in the proceedings of one of the Berkeley Workshops on
Distributed Data Management and Computer Networks but I don't
know which one. Probably the fourth, 1979). A more recent paper
that looked interesting was "Performance Analysis of the
Selective Repeat ARQ Protocol" in COM-34, No.2, Feb, 86.
I wasn't sure from your msg what objective function you wanted
to optimize and what you viewed as constraints. I was trying to
model a net where
- each connection wished to maximize its throughput (as opposed
to maximizing total network throughput)
- aggregate network bandwidth is a limitting resource (i.e., data,
acks and other connections all compete for the same bandwidth)
- the population of users is large (i.e., the potential offered
load is many times the available bandwidth)
- all connections use the same send/ack policy and sends from
different connections are initially i.i.d.
- all packets go through gateways and the host-gateway path has
much higher bandwidth than the gateway-gateway path.
- gateways have finite buffer capacity
- packets are subject to loss by both damage and congestion.
Using some of the ALOHA analysis, you can show that any protocol
that deals the first six constraints must be fair and must be very
conservative with retransmissions (because congestive collapse is
exponential). The congestive-loss constraint made the problem
novel and I got some simulation results that might explain some of
the behavior you observe.
If we make the usual assumption of a constant bit error rate,
damage loss is a linear function of the traffic. Congestive loss
is a function of the packet interarrival times (i.e., the derivative
of traffic w.r.t. time). I made a loss model that looked like
L(N) = (a + b dN/dt) N
where L is the number of packets lost and N is the number of
packets sent (including retransmissions). I then did a cluster
analysis and a regression on a bunch of trace data to get
empirical values for a and b. Since I had first become interested
in gateway behavior when I noticed the large amount of congestive
loss, I wasn't surprised to find that b was three to four orders
of magnitude larger than a.
This note is already too long so I'll state, without background,
some preliminary, *simulation* results (I hope to one day have
analytic results but am presently hampered by massive mathematical
ignorance).
- The network is wildly unstable under most send/receive policies
if the rtt estimates are bad.
- If the window is W packets and the round trip time is R, the
sender policy that maximized throughput was to keep
W/R <= dN/dt <= 2W/R (i.e., spread the packets uniformly over
the rtt interval but still fill the pipe). Under heavy
congestion it also helped to inject some random variation into
the packet send times.
- If the sender doesn't try to spread out packets, it is unwise
for the receiver to delay an ack for more than half the average
packet interarrival time. An ack for multiple packets will
make the sender generate a burst of packets to fill the
window. Any time a burst is sent, the probability of loss goes
up quickly. (If you were testing on a lossy path, this may have
been what was happening when you observed that increasing the
number of acks increased the throughput.)
- If the sender doesn't try to spread packets, retransmissions
(usually) result in a burst of packets, that results in loss, that
results in retransmissions, that .... Most tcp's are guilty of
this burst, including 4.[23]bsd. It's this mis-behavior of
tcp which I believe accounts for you and others observing better
throughput with RDP than TCP. This is simply because the EACK
makes it less likely that a naive protocol implementation will
generate a burst of packets. ("Naive" means "naive of interarrival
time effects".)
While I never got any of the preceeding into a publishable form, I
have gone over some of the trace data and simulation results with
Mike Karels. I think we've agreed on a change to the 4bsd tcp
retransmission policy and hope to implement and test it soon. In
(limited) simulation, the new policy reduced the number of
retransmissions by a factor of four and increased the throughput
under heavy congestion by a factor of two.
Hope some of this was useful. If you have time to summarize, I'd
be interested in anything you learned from the replies to your query.
- Van
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: Tue 13 Jan 87 05:18:16-EST From: Dennis G. Perry <PERRY@VAX.DARPA.MIL> To: ron@BRL.ARPA Cc: NS-DDN@DDN2.ARPA, hedrick@TOPAZ.RUTGERS.EDU, tcp-ip@SRI-NIC.ARPA, perry@VAX.DARPA.MIL Subject: Re: Re: Password Security for the UCLA ACP
Actually, I would investigate some of the smart cards around for authentication and potentially encryption. Codercard at one time was thinking about putting in their card the ability to not only have the one time password, but to encrypt the data and change the encryption key in a period short compared to the amount of data transfered, so that even if some was able to break the key, the amount of data obtained would be small and then they would have to start all over. dennis -------
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: Tue, 13-Jan-87 08:50:32 EST From: Richard_S._Conto@UM.CC.UMICH.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: Password Security for the UCLA ACP
In the message ( Message-Id: <8701121034.aa13795@SEM.BRL.ARPA>)
of Mon, 12 Jan 87, Ron Natalie (<ron@BRL.ARPA>) suggests:
> ... The only way I can think of
>getting around it is to use a PC or some other semi-smart device as
>the user terminal and encrypt some or all of the authentication information.
>It's really the same idea, except that the terminal has most of the smart
>algorithm in it, the user just has some key.
Is this really 'safe'? If you're really so terribly worried about the
privacy and the secure validation (which I'd like to consider as seperate,
though linked issues), then doesn't this end also need to be secure? I
can see specialized hardware possibly being secure, but a program that
resides on a PC can be easily duplicated. In fact, with one person
borrowing another's copy to get some work done quickly, it would soon seem
to loose any real security at all and just become a nuisance.
--- Richard
ARPA Richard_S._Conto@um.cc.umich.edu
USnail Richard S. Conto
Computing Center
1075 Beal Ave.
University of Michigan
Ann Arbor, Mi. 48109
"It's too early in the day to be cute and funny."
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: Tue, 13-Jan-87 09:30:00 EST From: JSLove@MIT-MULTICS.ARPA.UUCP To: mod.protocols.tcp-ip Subject: Re: secure replacements for passwords
I don't know about your TCP, but the Multics TCP will send a RST immediately if it receives a packet with an ACK that it`s too high. I believe that this is clearly spelled out in the specification, but I am at home and don't have the specification handy. To prevent this, your penetrator must break network routing (e.g., using ARP) to prevent the acknowledgements from reaching the workstation or the RSTs they provoke from getting back to the server. If you don't mind breaking the connection, any damage you can do with a single packet is perfectly possible. I don't think most TCPs would give out any indication of why the connection was broken, either on the scren or in a debugging log. An workstation in debug mode might note that an out-of-sequence acknowledgement was received, but the server would only note that the user had aborted the connection. If you really have control of network routing, it would be interesting to see if you could insert the penetrator between the workstation and server, effectively splitting an existing session into two sessions with the penetrator in the middle. The potential for mischief would be awesome. Receiving a packet which contains out-of-sequence acknowledgement should probably ring alarm bells. Even out-of-sequence packets which don't contain acknowledgement (and thus must be SYN packets) are illegal, but they probably indicate that the other end has crashed or a TTL anomaly, rather than a penetration attempt. Something else that might help is putting reasons for aborts into RST packets as data, and having the receiving TCP log the abort reason. Then there would be a record of the break-in at both ends of the connection. I believe that there are TCPs which implement this, but have no idea which ones. It certainly isn't in the spec. (This could be circumvented by having the penetrator abort the connection, but unless routing is subverted, this gives too short a window to do much other mischief.)
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: 13-Jan-87 05:32:42-UT From: mills@huey.udel.edu To: tcp-ip@sri-nic.arpa, nsfnet-routing@mcr.umich.edu Subject: How sweet it is
Folks, Mike Petry, fierce swamprat from U Maryland, staggered from the muck waving an ACC 5250 X.25 interface driver in one hand and dragging an awesome alligator in the other. Shortly before he passed out (the swampgas was just too much - he began to see UFOs) he whispered "only ten keystrokes did the varmits in." I rushed to the ooze and tossed a ping raft between dcn-gateway (56-Kbps 1822/ECU 10.0.0.111) and terp (56-Kbps X.25 10.8.0.111) and reeled in 5000 packets of catfish, a possum and two owls. The swamp never smelled so good. Relative to my gruesome scatter plots mentioned previously to the list, the X.25 circuit has much joy. The Sun-format bitmap file is on udel2.udel.edu under anonymous/guest as terp1.bit, should you care to light it up. The max delay was almost five seconds, but only five samples were more than two seconds. The regression line had a y intercept of 32 and 576-octet intercept of 238, for a slop of 22411 bps, about to be expected for the two-hop dcn-gateway PSN 111 terp path. Mike tells me the problem was a simple bug in the driver, so I suggested he set a reasonable price for ransome at just $500 per keystroke. Comes to one 5250, unless you can find a ripoff in Filene's basement basement. I don't know about you guys, but I am mighty relieved and would like to be one of the first to throw Mike a towel so he can wipe off that icky, smelly swamp stuff and take a bath. Dave -------
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: Tue, 13 Jan 87 11:44:59 EST From: hurf@tcgould.tn.cornell.edu (Hurf Sheldon) To: arpa.tcp-ip Subject: Hot setup for PC-AT?
We have two PC-AT's (not clones) & would like to connect
them to our ethernet. What hardware/software would be good choices?
Both systems are msdos. Will h4000 decoders work with the hardware
& does the software support full tcp/ip - bsd4.3 networking?
I willsummarize any email replies-
thanks
Hurf Sheldon Arpa.css: hurf@ionvax.tn.cornell.edu
Lab of Plasma Studies
369 Upson Hall phone: 607 255 7267
Cornell University
Ithaca, N.Y. 14853
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: Tue, 13-Jan-87 12:51:34 EST From: weltyc%cieunix@CSV.RPI.EDU.UUCP To: mod.protocols.tcp-ip Subject: Tektronics TCP/IP for VMS
Sorry to ask a question that I know was answered previously, but I can't seem to find it in my own archive... There was mentioned a list for people interested in the Tek TCP/IP at cornell or cmu or someplace like that. Can anyone tell me the actual address for that??? -Chris
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: Tue, 13-Jan-87 13:22:46 EST From: Mills@LOUIE.UDEL.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: Analyzing Acknowledgement Strategies
Van, You are doing some fantastically wonderful stuff that should have been done long ago. Your conclusions coincide closely to my observations and probably many others, especially with respect to bunching (aka spasms), especially with Unix systems using humungus windows over lossy paths. One thing was not clear from your note. Did your simulations include the use of the Nagle Algorithm? Some years ago when I was experimenting along with others on TCP models I built a flow estimator into the code which produced in effect your dN/dt. It was designed to produce exactly the result you describe - spreading the packets uniformly over time. I also intended to build an estimator for dL/dt as the loss rate (did I get your nomenclature backwards?), but something else distracted me. However, I did wire up a couple of D/A converters to panel meters on my desk so I could see the estimators in action. One was the SRTT and the other the dN/dt. Boy, did I get an eyeful watching these gizmos in action as tings clogged and unclogged. If there weren't so many other beasties squealing for attention, I'd like to dive back in those issues again. The results might well have a profound effect on second-generation ISO transport protocol implementations. Idea: Use median-filter estimators instead of linear, recursive-filter ones. I found the former extraordinarily effective for comparing clocks across the swamps, which means they should work well for SRTT as well. My variant, which doesn't have a proper name, is as follows: save the last n RTT samples and sort them. Identify the median (dither if you have to if the number of samples is even), then toss out the extremum furthest from the median. Repeat until only a single sample is left. Season for the endgames. Serve with appropriate timeout, so that really old info is discarded. I have been using sample windows of eight. Keep up the good work. Dave
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: Tue, 13-Jan-87 19:26:43 EST From: ron@BRL.ARPA.UUCP To: mod.protocols.tcp-ip Subject: Re: Re: Password Security for the UCLA ACP
Yes, last I heard DARCOM (er, AMC) headquarters was contemplating such a system. I haven't heard if it has been installed yet. -Ron
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: Wed, 14-Jan-87 09:12:14 EST From: whna%cgcha.UUCP%cernvax.BITNET@WISCVM.WISC.EDU (Heinz Naef) To: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip
Path: cgcha!whna From: whna@cgcha.UUCP (Heinz Naef) Newsgroups: comp.sources.wanted,mod.computers.sun,mod.protocols.tcp-ip Subject: SLIP (Serial IP over asynchronous line) Keywords: SLIP, IP, PC/IP, TCP/IP, asynchronous. Message-ID: <204@cgcha.UUCP> Date: 14 Jan 87 14:12:11 GMT Organization: CIBA-GEIGY AG, FO/WIRZ/WRZ, Basel, CH Lines: 15 Does anybody have implemented a piece of software on a UN*X 4.2bsd system that supports the DoD Internet Protocol (IP) over asynchronous serial lines? There are products available for MS/DOS PC's that offer this type of attachment. These would allow PC-like systems that are located far away from the Ethernet to get connected to the UN*X systems over phone lines. PC users could take advantage of the Telnet, FTP etc. client functions as if they were directly attached to the Ethernet, except they would experience slower speed and some operational differences (dial-up, point-to-point etc.). Thanks for your help, Heinz Naef. Please respond by electronic mail: ..!mcvax!cgcha!whna.
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: Wed, 14-Jan-87 10:54:17 EST From: bob@OHIO-STATE.ARPA.UUCP To: mod.protocols.tcp-ip Subject: Re: Tektronics TCP/IP for VMS
In article <8701131751.AA17600@cieunix.rpi.edu> weltyc%cieunix@CSV.RPI.EDU (Christopher A. Welty) writes: > ... a list for people interested in the Tek TCP/IP ... ? The list is resident at `TEKTCP%KLA.WESLYN@WESLEYAN.BITNET'. Be quite careful of the spelling, because those missing vowels will getcha.
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: 14 Jan 87 16:21:00 PST From: <art@acc.arpa> To: "tcp-ip" <tcp-ip@sri-nic> Subject: PSN Interoperability
I am trying to obtain information which I think is extremely important for designing and maintaining interface hardware and software which must interconnect to BBN PSNs. Does anyone out there have a detailed understanding of how PSN 6.0 maps between the 1822, X.25 Basic and X.25 Standard services and a description of the underlying packetization performed between PSNs. There doesn't appear to be any publically available documents and BBN seems to be unwilling or unable to communicate any information to us. The original IMPs (PSNs) would take 1822 "messages" of up to roughly 1K and split them up into 128 byte "packets" which were independently shipped throught the IMP network. When all of the "packets" were received and reassembled by the destination IMP and the "message" delivered to the destination host, a Request For Next Message (RFNM - pronounced "ruf num") was sent back to the sending host. For resource control, only 8 messages were allowed to be outstanding to any specific remote host per 1822 "link number". IP datagrams were assigned a specific "link number" to use. Does anyone know whether the current PSNs operate this way for 1822 interfaces? I would like to find out how HDH "packet mode" and HDH "message mode" interacts with the internal PSN transport. I would like to know how DDN Basic mode and DDN Standard mode interacts with the internal PSN transport. Specifically I would like to understand what happens (in DDN Standard Mode) to an IP datagram which is sent as a sequence of X.25 "m-bit" packets and is delivered elsewhere via an 1822 interface. I would like to know how the contents of the X.25 packets are handled and how the X.25 packet window is controlled. My understanding is that PSN 7.0 will change the behavior of X.25 through the PSN network. Anyone have any real information? Art Berggreen <Art@ACC.ARPA> ------
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: Thu, 15-JAN-1987 16:40 N From: <POSTMASTER%FINFUN.BITNET@WISCVM.WISC.EDU> To: TS0400%OHSTVMA.BITNET@WISCVM.WISC.EDU Subject: Returned Network Mail
----------------------------Original message----------------------------
Your mail is being returned to you.
Reason for return is:
%MAIL-E-LOGLINK, error creating network link to node VTTEL1
-SYSTEM-F-LINKEXIT, network partner exited
Returned mail follows:
------------------------------
Received: From BYUADMIN(MAILER) by FINFUN with RSCS id 5461
for VTTTELTY@FINFUN; Thu, 15-JAN-1987 16:40 N
Received: by BYUADMIN (Mailer X1.23b) id 5420; Thu, 15 Jan 87 06:59:06 MST
Date: Thu, 15 Jan 87 08:46:02 EST
Reply-To: "(TCP-IP ARPA Digest)" <TCPIP-L@BYUADMIN>
Sender: "(TCP-IP ARPA Digest)" <TCPIP-L@BYUADMIN>
From: Bob Dixon <TS0400@OHSTVMA>
Subject: Password security
To: "(no name)" <VTTTELTY@FINFUN>
Another way of minimizing the effect of possible ethernet tappers
is to use bridges and gateways which isolate groups of users appropriately.
Then a member of any given group cannot intercept messages which do not
involve that group, because other packets do not flow in their ethernet.
Bob Dixon
Ohio State University
Acknowledge-To: <TS0400@OHSTVMA>
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: Wed, 14-Jan-87 17:16:47 EST From: ron@BRL.ARPA (Ron Natalie) To: mod.protocols.tcp-ip Subject: Re: Password Security for the UCLA ACP
Well, any point of the system where the data is going to exist unencrypted is going to have to be secured. But consider the original application. He was concerned about ethernet spies grabbing the passwords and such off the wire. You can do this even if the spy has a copy of your encryption program. Many people have the UNIX password crypt routine, but as of yet no one has announced a way to use it to decrypt totally random passwords (other than by exhaustive search, which even on our X/MP-48 takes a long time...it does vectorize nicely though :-)). Consider the following scenario... A BIG SECURE UNIVERSITY ADMINISTRATIVE COMPUTER named I'm Big Money An IBM PC in the Bursars Office named Petty Cash and the campus ethernet spine with the above plus random PC's and SUNs on it called "RU-YELLOW" Petty Cash: I'd like to talk to Big Bucks ( now big brother makes up a verification string of random letters) I'm Big Money: Encrypt "AWALKER" for me using your password as key. (PC now encrypts the random phrase with the user's password "TUITION") PC: The encrypted string is "*HOBBIT*". (IBM now encrypts "AWALKER" with the user's passord "TUITION" and sees that they match and allows access.) IBM: OK PC...what shall we do today? See at no time did the user's password "TUITION" ever exist in the clear. The Spy, seeing the random string and the encrypted answer can not deduce the password. He can't use the encrypted answer because next time IBM will send a different string. It makes no difference here whether or not he has a copy of the program running in PC or not. Of course, he can probably get all kinds of juicy data if the transactions are not encrypted as the authentication was. In addition, there is always the chance that the spy can infiltrate either end (like by modifying the software in the PC to also keep track of the cleartext passwords). -Ron
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: Wed, 14-Jan-87 19:21:00 EST From: art@ACC.ARPA To: mod.protocols.tcp-ip Subject: PSN Interoperability
I am trying to obtain information which I think is extremely important for designing and maintaining interface hardware and software which must interconnect to BBN PSNs. Does anyone out there have a detailed understanding of how PSN 6.0 maps between the 1822, X.25 Basic and X.25 Standard services and a description of the underlying packetization performed between PSNs. There doesn't appear