|
|
ARCHIVE: TCP-IP Distribution List - Archives (1987)
DOCUMENT: TCP-IP Distribution List for November 1987 (403 messages, 234858 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1987/11.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Sun, 1-Nov-87 07:05:06 EST From: farber@UDEL.EDU (Dave Farber) To: comp.protocols.tcp-ip Subject: Re: supdup protocol
The first notion I know of to separate the front end of an editor and the back end was at least 1963 (the one I know was at BTL back then). (Note the term AT LEAST) Dave
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Sun, 1-Nov-87 11:49:43 EST From: hedrick@ATHOS.RUTGERS.EDU (Charles Hedrick) To: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge
Now that source routing is becoming accepted, IP gateways are no longer guaranteed to provide security. A host can pretend to be a host on a different subnet, but use source-routing in such a way that the other guy is told to route the packet back thru the bad guy's real address. The bad guy of course does not forward the packet. IP gateways are normally used because they provide isolation. This issue has been discussed so many times that I am reluctant to do it once more. In general, a LANbridge is more reasonable the fewer Ethernets you have (making provisions for future growth), the fewer different kinds of systems you have, and the better central control you have over the systems on your network. We have had disasters that made every VMS system on a network connected by level 2 routing unusable. The problem should not get thru an IP gateway. We have had several disasters that were confined to a single Ethernet only because of the use of IP gateways. However if you have good network monitoring and system management, a stable network/software environment, or a small network, a level 2 system can be made to work.
-----------[000002][next][prev][last][first]----------------------------------------------------
Date: Sun, 1-Nov-87 12:07:57 EST
From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To: comp.protocols.tcp-ip
Subject: Re: Ethernet Bridge, "equivalence"We emphasize the security issues involved in "equivalent" hosts in our manuals (it appears at least 3 different places). We advise anyone with security concerns just to "say no" to rsh and rcp, and use ftp or an rexec client we provide instead. However, there are still a lot of people distributing and using Unices derived from 4.2 which require that any host requesting printer services be "equivalent", and our package includes an lpr client... 4.3 fixes this. Are the guilty parties listening? James B. VanBokkelen FTP Software Inc.
-----------[000003][next][prev][last][first]----------------------------------------------------
Date: Sun, 1-Nov-87 12:38:21 EST
From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To: comp.protocols.tcp-ip
Subject: Re: Ethernet BridgeIf you mean Bridge Communications' IP routing products, there is at least one flavor and vintage of them out there which fragments all IP packets longer than 540 bytes. 4bsd and relatives send TCP segments of 512 (552 bytes IP length) bytes by default, and TFTP packets are just large enough to get caught, too. I don't know about the big-machine people, but it has a fairly horrendous effect on the older PC Ethernet cards, which aren't nearly fast enough to catch both fragments reliably. It is even worse when attempting to use one of the public domain software packages that doesn't support IP reassembly. jbvb
-----------[000004][next][prev][last][first]----------------------------------------------------
Date: Sun, 1-Nov-87 17:40:37 EST
From: schoff@NIC.NYSER.NET ("Marty Schoffstall")
To: comp.protocols.tcp-ip
Subject: Re: Ethernet Bridge
Now that source routing is becoming accepted, IP gateways are no
longer guaranteed to provide security. A host can pretend to be
a host on a different subnet, but use source-routing in such a
way that the other guy is told to route the packet back thru the
bad guy's real address. The bad guy of course does not forward
the packet.
Chuck,
I don't need source routing to do that. I can do that right now.
Marty
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: Sun, 1-Nov-87 21:43:59 EST From: jis@BITSY.MIT.EDU (Jeffrey I. Schiller) To: comp.protocols.tcp-ip Subject: Separation of Layers
I should point out that at MIT we no longer use network addresses as a form of authenticity. We now use our encryption based "Kerberos" authentication service. The code you wrote to use the subnet as a means of determining authentication has long since been retired. -Jeff
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: Mon, 2-Nov-87 08:00:25 EST From: snorthc@NSWC-OAS.ARPA To: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge
OK, I'll bite. We have been looking at NFS as a UNIX/VMS server solution for PCs. From the begining of the investigation we were looking for things like the 'huge security holes'. Somehow I must have missed it. I certainly have heard Netters alluding to such a thing. Would you be willing to spell out the problem, perhaps even complete with recommended solutions or workarounds? I may just be a hopeless case. I had never considered using an IP gateway for security purposes either. When I read you message a tiny light went on in my head for just a second... then I started thinking about name/domain serving, additional levels of indirection, and so forth and the light went out. Do you encrypt your secure side? Stephen Northcutt (snorthc@nswc-g.arpa) (703) 663-7796 office, (703) 663-7191 lab
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: Mon, 2-Nov-87 08:38:38 EST From: snorthc@NSWC-OAS.ARPA To: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge
James, You have my complete attention. We have a growing investment in Bridge Communications' IP routing products. We also have a sizable, but static investment in older PC ethernet cards (3C500/1, NI5010 ). One such Bridge box that has served us well in the past is the GS-3. A box that may have a place in our future is the IB-1. You can probably guess which PCIP we are using. Most of our hosts are 4bsd. Are we in danger, I suspect we are running either the latest, or next to latest rev. of software for all products? We certainly haven't noticed a problem. The cable is monitered for problems with a lanalyser from time to time. Perhaps this fragmentation problem is limited to an older rev of Bridge s/w, at least I hope so. In the two years I have been here there has been a steady parade of s/w & ROM upgrades from Bridge. The only time we have ever noticed a problem was with a DEC DEMPER of all things. It got connected to the cable with an improperly-labeled- but-suspected-ver1-xceiver. The 3c500s connected by thin net started losing about every other packet. The 3c505s were fine. Changing the xceiver fixed things. In any case whose routing box do you recommend? Stephen Northcutt (snorthc@nswc-g.arpa) Disclaimer: I haven't had my coffee yet! Only relationship I have with companies explicitly/implicitly mentioned is as a happy customer. Bridge is asked to forgive me for mangling their part #'s (GS/3).
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: Mon, 2-Nov-87 09:51:18 EST From: naftoli@aecom.YU.EDU (Robert N. Berlinger) To: comp.protocols.tcp-ip Subject: Subnetting: I'm not sure I understand
I'm not sure I understand subnetting fully. Assuming you have a class C
address -- will subnetting allow you to have more than 255 hosts on the
network?
--
Robert N. Berlinger naftoli@aecom.yu.edu
Supervisor of Systems Support
Albert Einstein College of Medicine Compuserve: 73047,741
UUCP: ...{philabs,cucard,pegasus,rocky2}!aecom!naftoli GEnie: R.Berlinger
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Mon, 2-Nov-87 10:38:59 EST From: craig@NNSC.NSF.NET (Craig Partridge) To: comp.protocols.tcp-ip Subject: pmdf over tcp-ip
Ed,
The answer is yes -- at least, recent versions of VMS PMDF can run
SMTP over TCP.
Craig
PS: For those of you who don't know what PMDF is... There are several
versions of PMDF (which in turn are based on MMDF). VMS PMDF is Ned
Freed's version of PMDF which is loosely based on the original Unix PMDF
by Ira Winston, which in turn is based on early versions of MMDF (by
Dave Crocker). The 'P' stands for Pascal -- it was originally a simple
mail system designed for use with CSNET's PhoneNet. The VMS version
has grown to rival MMDF in size and complexity.
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: Mon, 2-Nov-87 11:15:12 EST From: geoffb@ALE.TRW.COM (G. Geoffrey Baehr) To: comp.protocols.tcp-ip Subject: Re: Ethernet bridge
Concerning Charles Hedrick's note about level 2 bridges, it is precisely the quality of bridge management software that allows one to depend on a level 2 solution. What information does exist from these bridges currently seems to be non-uniform and of questionable value. Is there some bridge out there which does have a specified reporting mechanism,or one which may be queried in some manner. I have in mind the RBMS (Remote Bridge Management Software) from DEC, but alas, this spec is not released by DEC to we common folk. Without a diagnostic/reporting mechanism, level 2 bridges appear to offer more potential for net-wide disaster. Geoffrey Baehr I would be interested in knowing whether any vendor intends to implement portions of the HEMS work in their current or future products.
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: Mon, 2-Nov-87 11:15:34 EST From: braden@VENERA.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: ..."layering violations"
Yes, I know they're *supposed* to. I meant to say that I've seen many gateways use the destination IP address of the original datagram as the source address for the IP datagram containing the ICMP message, and this makes it impossible to discern where the problem is. One implementation around here returns every broadcast it sees with a "port unreachable" ICMP message and puts the IP broadcast address in the IP source field! Phil Phil, I wish you would name names. Being coy about whose box is screwing up isn't doing anyone a favor. Since there is no Internet Conformance testing service, we have to collaborate as a group to "encourage" conformance from the vendors. Bob Braden
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Mon, 2-Nov-87 11:35:16 EST From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: On broadcasts, congestion and gong
Mike, Thanks very much for thie information. I (and Bob Braden, I'm sure) will be looking forward to your definitive statements on how 4.3+ conforms, as well as any comments you have on what should be changed for the next draft of the document. Dave
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: Mon, 2-Nov-87 12:27:00 EST From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) To: comp.protocols.tcp-ip Subject: Re: ..."layering violations"
Phil-- A sidelight on keeping connections open "forever" seems appropriate, just in case anybody doesn't attach enough strength to the quotation marks you rightly used: In the early days of the Multics "NCP" [sic], we discovered that we were sending "RST"s (the old Host-Host Protocol Reset command, which was sent whenever an NCP came back up, to "everybody" --well, you could do that sort of thing when there weren't four dozen Hosts in the world) without end to a particular Host. It turned out the problem was that we were getting "Incomplete Transmission" from our IMP, so we tried again, since that code was supposed to mean that a temporary problem had prevented successful transmission; however, the Host in question had somehow jumpered their IMP interface in such a fashion as to convince their IMP that they really were up when they weren't and so we got the code in a circumstance where we really shouldn't have. Naturally, we put a limit on the retransmisions after an Incomplete Transmission was encountered after that (and we probably should have had one in the first place). The moral does seem worth pointing out, though: keep connections open for appropriately small values of forever. (For example, if you happen to get a Host Down, you might as well close even if you're only a daemon, since the other side should come up again out of Sequence Number synch--shouldn't it?) cheers, map -------
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Mon, 2-Nov-87 12:32:52 EST From: jas@MONK.PROTEON.COM (John A. Shriver) To: comp.protocols.tcp-ip Subject: TCP and teaching bridges and routers about routes
> Interestingly enough, this is an area where the source routing > scheme of IBM/ 802.5 is superior to the "proxy-ARP" routers (and maybe to > the TransLan ether bridge schemes). With the latter approaches, if a > bridge/router which is not within "local broadcast" range fails, then there > is no way for the local TCP to request that the path be redetermined. > In the source route (802.5 variety) scheme, the local TCP merely causes a > new route to be determined via a new "all rings broadcast" XID. It is correct that the TCP cannot ask a DEC LANbridge (or other equivalenly implemented learnig bridges) to try again on the route. That is because the management protocols they use will detect the failure before the TCP does, activate a new (previously backup) bridge, and dynamically rethread the route. The whole point of a LEARNING bridge is that you don't have to TEACH it. You do have to TEACH an IBM Token-Ring bridge. Of course, IP routers running dynamic routing protocols offer exactly the same advantages. They too will reconfigure faster than TCP can notice when one intermediate path fails. The host does not need to ask for any help, at most it will get an ICMP redirect. The only case where this advantage of routers will fail is in the ARP proxy subnet hack. This is why ARP proxy subnetting REQUIRES ARP cache aging, which pure ARP, used for its intended purpose, does not. That's why ARP proxy subnetting is a workaround, and not a standard. Oh yes, you lose all the advantages of the frame-copied and address-recognized bits in 802.5 when you use IBM bridges. All that frame copied means to the sender is that the first bridge copied it. A later bridge may have to drop it (congestion), or be dead. You don't lose these advantages with routers, because they try again if they don't get frame-copied. This is why a ring makes a good router backbone. So far as I can see, IBM Token-Ring source routing combines the bad aspects of routing and bridging into a big layering violation. It will persist, however, due to SNA's reliance on it. (These are my opinions, and have not been certified or blessed by Proteon.)
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Mon, 2-Nov-87 14:34:27 EST From: mcdermot@merlin.unm.edu (John McDermott) To: comp.protocols.tcp-ip Subject: TCP/DECnet interchange router for VMesS
Organization:Applied Technology Asociates I have a problem which I hope someone has already solved: I have a TCP/IP net and a large DECnet net both served by a common VAX (vms). Some hosts on the decnet network also run tcp/ip. All tcp is CMU/TEK for vms. Now the question: are there drivers to encapsulate ip packets, send them over the DECnet and then make them available for retransmission at the other end? I need this because my VAX with Decnet is connected to the rest of the DECnet network by a 56kb line and that line cannot be used for both decnet and tcp/ip (for political reasons at least). Any help would be really appreciated. Try afwl-vax.arpa!atavax.decnet!mcdermott or maybe there is enough interest here you should just post any results. Thanks. --john John McDermott ARPA: mcdermott%atavax.decnet@afwl-vax.arpa Applied Technology Assoc W (505) 247-8371 1900 Randolph SE Albuquerque, NM 87106 H (505) 255-7796
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: Mon, 2-Nov-87 16:42:51 EST From: wire@iwarpj.intel.com (Wire Moore) To: comp.protocols.tcp-ip Subject: TCP/IP Slang Glossary
The reading getting a might thick for me, and others I suspect, who are green to this group. Would someone post a glossary of the slang this group favors? Thanks. [fuzzball? bogon? gong?]
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: Mon, 2-Nov-87 16:49:14 EST From: david@E.MS.UKY.EDU (David Herron E-Mail Hack) To: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge
Well ... the only hole which I know by heart is the following
situation. You have someone with a workstation and he has the root
password for his workstation. He also has some local disk storage. He
makes a setuid shell on his local disk. Then he goes over to another
system and executes his shell, thus giving him root on that system. In
our case we use equiv hosts to simplify a lot of things, but don't use
fully transitive equivalancies in a lot of cases. The reason this is a
hole has to do with Unix using a simple integer to encode the user id
... If there were some sort of indication of the host that the user id
pertained to ...
Oh, in the particular situation, the user MUST have root access to his
own workstation so that he can properly do his research. Fortunately
he's a nice guy ... :-)
For a good time read section 2.2.2. of Suns NFS Protocol Specification.
It talks about the above bug and others.
As for using an IP gateway for security ... Well, consider me something
of a beginner in TCP/IP issues. But I still have to manage the local
end of our net, and give advice to the people around me. I understand
enough that the idea of a gateway knowing that a certain class of IP
numbers can only come from one side of the gateway makes sense. But
this source routing stuff which someone mentioned is unfamiliar
territory to me. I've been reading the discussion about source routing
and know that it apparently only applies to token ring. However, it
seems that if there is to be support for source routing in the kernal,
then you could use it from any sort of network hardware. Is the idea
with source routing to encapsulate an IP packet inside another one
which is addressed to a gateway machine, and the encapsulating packet
says where to send the encapsulated packet?
The use of IP gateways to wall off sections of the net to contain IP storms
makes sense ... We may set things up that way ... does anyone have any
recommendations on a good IP gateway?
--
<---- David Herron, Local E-Mail Hack, david@ms.uky.edu, david@ms.uky.csnet
<---- {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET
<---- "The market doesn't drop hundreds of points on a normal day..." --
<---- Fidelity Investments Co73D
X473D
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: Mon, 2 Nov 87 16:49:14 EST From: David Herron E-Mail Hack <david@ms.uky.edu> To: snorthc@NSWC-OAS.ARPA Cc: tcp-ip@SRI-NIC.ARPA, david@a.ms.uky.edu Subject: Re: Ethernet Bridge
Well ... the only hole which I know by heart is the following
situation. You have someone with a workstation and he has the root
password for his workstation. He also has some local disk storage. He
makes a setuid shell on his local disk. Then he goes over to another
system and executes his shell, thus giving him root on that system. In
our case we use equiv hosts to simplify a lot of things, but don't use
fully transitive equivalancies in a lot of cases. The reason this is a
hole has to do with Unix using a simple integer to encode the user id
... If there were some sort of indication of the host that the user id
pertained to ...
Oh, in the particular situation, the user MUST have root access to his
own workstation so that he can properly do his research. Fortunately
he's a nice guy ... :-)
For a good time read section 2.2.2. of Suns NFS Protocol Specification.
It talks about the above bug and others.
As for using an IP gateway for security ... Well, consider me something
of a beginner in TCP/IP issues. But I still have to manage the local
end of our net, and give advice to the people around me. I understand
enough that the idea of a gateway knowing that a certain class of IP
numbers can only come from one side of the gateway makes sense. But
this source routing stuff which someone mentioned is unfamiliar
territory to me. I've been reading the discussion about source routing
and know that it apparently only applies to token ring. However, it
seems that if there is to be support for source routing in the kernal,
then you could use it from any sort of network hardware. Is the idea
with source routing to encapsulate an IP packet inside another one
which is addressed to a gateway machine, and the encapsulating packet
says where to send the encapsulated packet?
The use of IP gateways to wall off sections of the net to contain IP storms
makes sense ... We may set things up that way ... does anyone have any
recommendations on a good IP gateway?
--
<---- David Herron, Local E-Mail Hack, david@ms.uky.edu, david@ms.uky.csnet
<---- {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET
<---- "The market doesn't drop hundreds of points on a normal day..." --
<---- Fidelity Investments Corporation
-----------[000019][next][prev][last][first]----------------------------------------------------
Date: Mon, 2-Nov-87 16:55:01 EST
From: RAF@NIHCU.BITNET ("Roger Fajman")
To: comp.protocols.tcp-ip
Subject: Multiple subnets on one physical netMAIL FROM RAF SATURDAY 10/31/87 8:21:02 P.M. I guess that this may have been discussed before, but due to a problem with our mailer here I wasn't getting much mail from this list at the time. Anyway, we recently acquired a class B network number for our planned campus network and the issue arises about how to divide the 16-bit address space between subnet numbers and host numbers. If we make the subnet field small, we probably won't have enough subnet numbers (a 5 bit subnet field gives 30 networks of 2046 hosts each) and a lot of address space is wasted on small subnets. If we make the subnet field large, we won't have enough host numbers for our largest subnet (an 8 bit subnet field gives 254 networks of 254 nodes each). This naturally leads to the question: can multiple subnet numbers be assigned to the same physical network? Since we plan to use Proteon p4200 Gateways for at least some things, I called Proteon and asked them. They told me that there is no problem, as each network interface can be assigned up to 16 IP addresses, thus allowing it to respond to an IP address for each of up to 16 subnets that reside on the same physical network. I was told that this was desirable because many hosts require that any gateway that they use be on their own subnet. Now I was recently shown a copy of a message from last July that said that in such a situation, a Unix system would receive Ethernet broadcast packets containing IP broadcast packets for other subnet numbers, not realize that they were broadcast packets for another subnet, and try to process (forward or redirect) them in some way. More recently, I received a message on this list that said that a Unix system would not try to perform gateway functions unless it had more than one network interface, regardless of how its parameters were set. Anyway, what is the truth? Can we assign multiple subnet numbers to the same physical network or not? What have others done about this problem? Roger Fajman RAF@NIHCU.BITNET National Institutes of Health
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: Mon, 02 Nov 87 16:55:01 EST From: "Roger Fajman" <RAF%NIHCU.BITNET@wiscvm.wisc.edu> To: TCP-IP@SRI-NIC.ARPA Subject: Multiple subnets on one physical net
MAIL FROM RAF SATURDAY 10/31/87 8:21:02 P.M. I guess that this may have been discussed before, but due to a problem with our mailer here I wasn't getting much mail from this list at the time. Anyway, we recently acquired a class B network number for our planned campus network and the issue arises about how to divide the 16-bit address space between subnet numbers and host numbers. If we make the subnet field small, we probably won't have enough subnet numbers (a 5 bit subnet field gives 30 networks of 2046 hosts each) and a lot of address space is wasted on small subnets. If we make the subnet field large, we won't have enough host numbers for our largest subnet (an 8 bit subnet field gives 254 networks of 254 nodes each). This naturally leads to the question: can multiple subnet numbers be assigned to the same physical network? Since we plan to use Proteon p4200 Gateways for at least some things, I called Proteon and asked them. They told me that there is no problem, as each network interface can be assigned up to 16 IP addresses, thus allowing it to respond to an IP address for each of up to 16 subnets that reside on the same physical network. I was told that this was desirable because many hosts require that any gateway that they use be on their own subnet. Now I was recently shown a copy of a message from last July that said that in such a situation, a Unix system would receive Ethernet broadcast packets containing IP broadcast packets for other subnet numbers, not realize that they were broadcast packets for another subnet, and try to process (forward or redirect) them in some way. More recently, I received a message on this list that said that a Unix system would not try to perform gateway functions unless it had more than one network interface, regardless of how its parameters were set. Anyway, what is the truth? Can we assign multiple subnet numbers to the same physical network or not? What have others done about this problem? Roger Fajman RAF@NIHCU.BITNET National Institutes of Health
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: Mon, 2-Nov-87 16:55:58 EST From: rfox@amelia (Richard Fox) To: comp.protocols.tcp-ip Subject: Re: my subscription
Please add me to the distribution list please.
rfox@ames-amelia
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: Mon, 2-Nov-87 17:30:25 EST From: lekash@ORVILLE.NAS.NASA.GOV To: comp.protocols.tcp-ip Subject: Re: Ethernet - Hyperchannel Gateway
>From our experience, the actual sustained rate is 600/sec, assuming no associated data and no contention on a dedicated trunk. [Measured between two Crays on a one meter coax trunk.] Measured between two crays running what? We measured 5mbits/second effective data from silicon graphics workstations running unix to a cray2 running unix. Using a 4096 associated data, and a little arithmetic, this is 1220 packets/second. The cray2 has an A130, the workstation an A400 hyperchannel adapter. 17 mbit/sec was measured memory to memory on TCP on the same cray2, going out one adapter, and in another. I will admit that this is thus a somewhat suspect number, but we don't have a second cray2, yet.
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Mon, 2-Nov-87 18:11:16 EST From: karn@faline.bellcore.com (Phil R. Karn) To: comp.protocols.tcp-ip Subject: Re: ..."layering violations"
In article <8711010759.AA08856@okeeffe.Berkeley.EDU>, karels@OKEEFFE.BERKELEY.EDU (Mike Karels) writes: > Two comments on your recent message. First, about TCP behavior > when ICMP unreachables are received: I definitely agree that TCP > ought not to quit when it receives an unreachable. However, in Unix > and probably most other systems, it's hard to report "soft" errors > to a network client. In 4.3, I chose to return a single error > on the next send or receive, but the TCP connection remains open. > Unfortunately, most network applications carefully check for errors > on each send/receive, and they give up on the first error. > (4.2 aborted the connection when ICMP errors were received, > and thus the application had no chance to keep trying.) TCP doesn't return an error to the application when it retransmits, so why should it do so when it receives a sporadic ICMP unreachable message? I think a better approach would be for TCP to ignore these messages, except to keep the last one or two around in case the application specifically wanted to see them (e.g., by doing a special ioctl on the socket). > I also agree that you're right to distinguish between interactive > network users and automatic daemons. However, it's precisely for > the daemons that are willing to wait patiently forever that "keep alive" > messages are needed. Although the telnet client will give up and close > the connection manually, there needs to be a way to prevent systems > from accumulating useless, disconnected telnet servers and other such > trash. Most application-level programs don't have their own keep-alive > or are-you-there to detect network failure. For those reasons, we use > TCP-level keepalives (which are also not well provided-for at this level) > only on network servers that don't have their own time-out scheme. I strongly disagree that this should be done at the TCP level. I took keepalives out of most of our systems some time ago. It's really nice not to have to recreate a half dozen rlogin windows on my Sun each time my SLIP link drops and has to be redialed. It's also nice not to have a steady stream of useless traffic on my amateur packet radio channel when somebody logs in but remains idle for long periods. The only way you accumulate useless, disconnected telnet servers is when the client machines crash. If you *really* want to get rid of them, just have a shell script do a write to anybody idle for more than X days -- the data will trigger a TCP Reset which will close the connection for you. On the other hand, while they are aesthetically unpleasing, idle sessions really don't hurt anything -- main memory is cheap and paging memory even cheaper. A year or two ago I thought as you do on keepalives, but a discussion with Jon Postel turned me around. :-) Phil
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Mon, 2-Nov-87 18:54:31 EST From: karn@faline.bellcore.com (Phil R. Karn) To: comp.protocols.tcp-ip Subject: details on misbehaving IP implementations
I've been asked to be less coy about mentioning misbehaving host implementations by name. Fine. Herewith is a brief summary of what I see on our own network after about 5 minutes of monitoring with a "bogon trap" of my own design: 1. A bunch of Excelan hosts emitting rwho/UDP broadcasts with 128.96.0.0 (our local broadcast address) in *both* the IP source and destination fields. 2. A Vax running 4.3BSD (or at least that's what the login banner says) that returns an ICMP Unreachable Port to the sender of each RIP packet it sees. 3. A Vax running MicroVMS V4.6 that's doing the same thing. 4. A big group of Symbolics LISP machines that return ICMP Unreachable Protocol messages in response to IP broadcasts with a locally-defined protocol field (255). None of these machines are under my administrative control so I cannot verify actual software version numbers, etc. Phil
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: Mon, 2-Nov-87 19:28:22 EST From: AI.CLIVE@MCC.COM (Clive Dawson) To: comp.protocols.tcp-ip Subject: Re: Security and Access Restrictions
If you have a serious interest in security then simply checking the IP addresses is not adequate because it is very easy to spoof IP addresses. Is it really THAT easy to spoof IP addresses? I agree that it's easy for me to put a bogus IP address on an outbound packet. But how do I get the remote host to send packets back to me instead of to the host I'm spoofing? Perhaps an improvement to the described security mechanism would be to match the various addresses appearing in the packet (IP header, TCP or UDP header, etc.) to see if there are disagreements. Clive -------
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Tue, 3-Nov-87 08:25:56 EST From: martillo@ATHENA.MIT.EDU To: comp.protocols.tcp-ip Subject: Security and Access Restrictions
I am interested in learning about Visa.
-----------[000027][next][prev][last][first]----------------------------------------------------
Date: Tue, 3-Nov-87 11:46:22 EST
From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To: comp.protocols.tcp-ip
Subject: Re: Ethernet BridgeI checked, and the specific model which does the fragmentation is the Bridge GS/3. The guy who has this problem told me that his gateway gurus had done all they could to try to get this fixed, but that it hadn't been, at least the last time he checked (~60 days ago). He says they tell him the GS/7 fixes these problems, and his site is apparently converting. If your network monitoring doesn't reveal any fragmentation of 552-byte IP length datagrams (512 byte TCP segment + headers), then you must have gotten a fix, or else your configuration is enough different that it doesn't happen. Our code did not handle IP reassembly before version 1.16. James B. VanBokkelen FTP Software Inc.
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: Tue, 3-Nov-87 13:54:22 EST From: RTB@SEED.AMS.COM (Robert Baynes) To: comp.protocols.tcp-ip Subject: TRANSLAN III Questions
AMS is an organization with two geographically separate offices, one in Providence, RI and one in Ann Arbor, MI. We are in the process of upgrading the modems on the leased line between the two offices from 9.6 Kbaud to 19.2 Kbaud. We are also considering installing at both sites a product from Vitalink called Translan III. This would eliminate a multiplexor setup on both ends. At the Ann Arbor end, the Translan would be connected to an Ethernet on which Interlan NTS100 XNS terminal servers are primary hardware for connecting terminals. At the Providence end, the Translan would be connected to an Ethernet on which NTS100s are wired to DECserver 100 and 200 LAT terminal servers. This would permit Ann Arbor users to connect to systems in the Providence office which support only LAT. With this configuration, only XNS terminal server traffic and occasional TCP/IP file transfer traffic would be transferred over the leased line between Providence and Ann Arbor (i.e., no LAT traffic would need to be transferred). I would like to hear from anyone who is using a Translan III in a similar configuration. I would especially like to hear from people who are using the product to pass terminal server traffic between Ethernets using a leased line. Thanks for any information. Bob Baynes American Mathematical Society Internet: RTB@SEED.AMS.COM (RTB@[192.16.180.3]) -------
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Tue, 3-Nov-87 15:56:04 EST From: snorthc@NSWC-OAS.ARPA To: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge
James, Thank you for the follow up on the Bridge GS/3. It does seem that the GS/3 might be one of the weaker links in Bridge's Product suite. If FTP software did not support reassembly of packets before 1.16 that helps to explain why we could not discern any difference between its performance* and PCIPs (assuming any packets ever got fragmented). I do seem to remember FTP v. 1.11 or 1.12's SMTP used to make the GS/3s complain, 1.14 fixed that. While GS/3s on the whole (and at a time there were far less alternatives available) seemed to work quite well, I do have one war story. We had a T1 link connecting two remote geographic sites with a GS/3 at each end. Whenever the T1 link went down (often in the boonies) the GS/3s would go off into space and someone would have to press a black button on the front of each GS/3. However Bridge has long since delivered a s/w upgrade and the morning ritual of resetting the GS-3 has been retired. I wonder who makes the best gateway-in-a-box (this week). Stephen Northcutt (snorthc@nswc-g.arpa) * we have never benchmarked TFTP and rarely use it, another reason we may not have suffered too much. Disclaimer: Only relationship between Bridge, FTP s/w and me is I try to buy what they try to sell.
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: Tue, 3-Nov-87 17:02:30 EST From: jerry@oliveb.UUCP (Jerry Aguirre) To: comp.unix.wizards,comp.protocols.tcp-ip Subject: Can I print on a terminal server port
I would like to be able print from a 4.3BSD Unix system on a printer connected to a TCP/IP terminal server. With the increasing use of terminal servers, some hosts being configured with no serial ports, this seems like a common enough problem that someone might have already done it. Please send me mail if you have tried this. I will summarize responses to the net. Jerry Aguirre Systems Administration Olivetti ATC
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: Tue, 3-Nov-87 20:39:26 EST From: ejnorman@uwmacc.UUCP (Eric Norman) To: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge
In article <7603@g.ms.uky.edu> david@ms.uky.edu (David Herron) asks:
>
> What do people think about the security issues? Right now, the
> concern is someone creating a situation where one of our equiv
> hosts is down, the bad-guy boots a machine that says he is
> the now-down machine and creates an suid shell on another of
Well let's see. Suppose I have hosts Bossie and Elsie here that
trust each other and Bossie goes down and you're going to try to
make Elsie think you're Bossie from the other side of a LAN-100.
Now, what I'm gonna do is put a permanent entry in Elsie's ARP
cache with Bossie's IP number and ethernet address. Well, I
reckon you can get a packet to Elsie that she'll think came from
Bossie, but I'd like to know how you're going to see the packets
coming from Elsie destined for Bossie.
Eric Norman
Internet: ejnorman@unix2.macc.wisc.edu
UUCP: ...{allegra,ihnp4,seismo}!uwvax!ejnorman
Life: Detroit!Alexandria!Omaha!Indianapolis!Madison!Hyde
"Tis far easier for a peacock to show his true colors
than it is for a lion to swallow his pride."
-- Arte Johnson
--
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: Wed, 4-Nov-87 01:11:04 EST From: kermit@BRL.ARPA (Chuck Kennedy) To: comp.protocols.tcp-ip Subject: Wretched MIL/ARPA Gateway performance
This evening, network performance was somewhat less that "optimal". The results are shown in the table below and represent the results of running ping for at least 2 minutes to check out round-trip packet delay and packet loss to various selected hosts. All tests were run from the host brl-vmb.arpa. The first interesting finding is that performance on the Milnet is quite good. Even a cross-country connection from brl-vmb.arpa on the East coast to nprdc.arpa on the West coast had 0% packet loss, an average round-trip time of 348 ms and a maximum round-trip time of 1418 ms. By comparison, a cross-country connection to ucbvax.berkeley.edu exhibited a 61% packet loss, an average round-trip time of 9064 ms and a maximum round-trip time of 22514 ms. Why the large discrepancy between responses from these two hosts? One possibility that looms is the Arpa-Milnet gateway. Running simultaneous pings to both sides of dcec-milnet-gw.arpa (BRL's default Arpa-Milnet gateway) reveal large packet losses. Admittedly, the simultaneous pinging can influence the packet loss level. However, even non-simultaneous pings to the different addresses of the gateway indicated large packet losses. One other revealing test is a simultaneous ping to the Arpa side of the gateway and to ucbvax. Packet loss just to the gateway was 40%, increasing to just 44% for packet loss to ucbvax. Average round-trip time to the gateway was 5743 ms while round-trip time to ucbvax was 7448 ms, almost 2 seconds longer. This would seem to indicate that much of the problem is in the gateway. There is probably an additional problem between the gateway and ucbvax since average round-trip time cross-country via Milnet is only 348 ms. Sample time: 2315-2340 on November 3, 1987 Ping was run for at least 2 minutes to gather the results below: Internet # hostname min/avg/max loss ---------- --------------------- ------------- ---- 26.2.0.29 aberdeen-mil-tac.arpa 33/348/6566 1% 26.0.0.45 ardec-mil-tac.arpa 99/208/3614 0% 26.0.0.50 amc-hq.arpa 114/148/748 0% Non-simultaneous 26.0.0.104 dcec-milnet-gw.arpa 6651/19174/32842 76% 10.7.0.20 dcec-milnet-gw.arpa 518/4452/13966 30% 26.0.0.104 dcec-milnet-gw.arpa 433/3408/14547 41% Simultaneous 26.0.0.104 dcec-milnet-gw.arpa 433/4020/15399 36% 10.7.0.20 dcec-milnet-gw.arpa 599/4724/21784 50% 26.3.0.3 nprdc.arpa 333/442/1418 0% 10.2.0.78 ucbvax.berkeley.edu 1948/9064/22514 61% Simultaneous 10.7.0.20 dcec-milnet-gw.arpa 548/5743/24565 40% 10.2.0.78 ucbvax.berkeley.edu 933/7448/22865 44%
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: Wed, 4-Nov-87 10:23:53 EST From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) To: comp.protocols.tcp-ip Subject: Private/Public Ownership of Software
Early this summer, a comment was made in this forum concerning the ownership
of software. As I recall the issue was raised concerning software developed
by Mitre for a governmental agency. The gist of the statement was that the
software in question was not in the public domain as it had not been develop-
ed at the specific request of the agency but was developed to satisfy require-
ments established by the agency. Can the author or anyone else provide me
a copy of the comment? (I foolishly deleted the message after reading it
the first time not realizing that it might have more importance than the
disk space it was occupying.)
Merton Campbell Crockett mcc@etn-wlv.eaton.com
AN/GYQ-21(V) Program
EATON Information Management Systems
31717 La Tienda Drive, Box 5009
Westlake Village, CA 91359
PS: After scrolling through two (2) months of messages that accumulated
while I was in Germany, I see we have yet to decide what the behav-
ior of terminal should be. Instead of TELNET appearing on the sub-
ject line, we have SUPDUP or RTCE (?) appearing on the subject line.
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: Wed, 4-Nov-87 12:30:23 EST From: espo@bpa.BELL-ATL.COM (Bob Esposito) To: comp.protocols.tcp-ip Subject: SGMP
Does anyone know where I can get info concerning SGMP (Simple Gateway Mgmt. Protocol)? Anything would be helpful. Thanks in Advance, -- ===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-=== Bob Esposito, Bell of Pennsylvania - espo@bpa.bell-atl.com - (215) 466-6831 ===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: Wed, 4-Nov-87 12:45:49 EST From: minshall@OPAL.BERKELEY.EDU To: comp.protocols.tcp-ip Subject: Re: Separation of Layers
Well, I've never been great on understanding which level is which. However, a TCP address is the two-ple <IP address, TCP port number>. This is the TCP address. That is the way it is. The nice thing here is that the TCP address contains sufficient information to determine the IP address (and, the bad thing here is that...). Next, a TCP connection is defined by the two-ple <local TCP address, remote TCP address>. A TCP connection *cannot* be defined by the two-ple <local TCP port, remote TCP port> - port numbers only have significance when concatenated with an IP address (imagine telnet clients on two machines trying to connect to the telnet server, port 23 or whatever, on one server machine). If I understand the world of ISO correctly, *everything* has an address (or is it a name?) which is (maybe) globally unique. In that case what you are saying would make sense - ISO TCP shouldn't care about the ISO IP source address some packet of data came from. However, DARPA TCP/IP is not built that way. (It would, it is true, be nice if every host had exactly one "name"; then a TCP address could be <host "name", port number>.) Greg Minshall
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: Wed, 4-Nov-87 15:10:23 EST From: steve@BRILLIG.UMD.EDU (Steve D. Miller) To: comp.protocols.tcp-ip Subject: Fetching host tables from the NIC
For a few days now, I've had problems in reaching the NIC. When I try to fetch HOSTS.TXT, do a whois lookup, or just to telnet in, I sometimes get TCP resets, and sometimes just get timeouts. When I last telnetted to the SMTP port on the NIC, though, it worked fine. If it was just timeouts, I wouldn't be so surprised, but it seems strange to me that the NIC would tell me to go away when I try to reach certain well-known ports and not others. Is something funny going on out there? I'd sure like to update my host tables, for those last few machines who need to use it... -Steve
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: Wed, 4-Nov-87 17:07:28 EST From: NIC@SRI-NIC.ARPA (DDN Reference) To: comp.protocols.tcp-ip Subject: ARPANET PSN 7.0 BETA TEST SCHEDULE
ARPANET PSN 7.0 BETA TEST SCHEDULE
The following is the current schedule for the new End-to-End cutover for
all ARPANET nodes. This schedule has been approved by DCA and DARPA.
It is requested that host administrators be aware of this test, but
not take action to reduce traffic load during testing.
All ARPANET nodes will be running PSN 7.0 on the following dates and
times:
Date Time
7 NOV 87 8:00-5:00 (EST)
14 NOV **thru** 15 NOV 8:00-5:00 (EST)
18 NOV 1:00-4:00 (EST)
Hosts experiencing problems are asked to call the ARPANET Monitoring
Center at (617) 873-3571/3070 or (800) 492-4992. Only by your
notification can we know that you are encountering problems. Please
call.
There will be a follow-up meeting to discuss the status of the ARPANET
beta testing of the new End-to-End protocols on November 20, 10:30 am
at the Washington Building, Room 201, 7600 Old Springhouse Road,
McLean, VA.
-------
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Wed, 4-Nov-87 19:31:27 EST From: martillo@ATHENA.MIT.EDU To: comp.protocols.tcp-ip Subject: Separation of Layers
Yes, it sounds like my interpretation won't work. I really was not trying to get TCP/IP to fit into the ISO model which I consider malformed at best. I have some Basic Rate and Primary Rate Interface cards for various machines, and I want to run TCP/IP over them. But I want the option of establishing point to point serial links between machines or X.31 connections to PSPDNs rather than just packet calls to my PBX or local switch which seem to have either miserable or non-existent packet handlers. In this environment I want to dynamically assign IP addresses to channels or groups of channels and I want to tear down links over which there is no traffic because I want to avoid phone bills which could be large in the case of point-to-point rather than packet billing. In such an environment I could anticipate the physical link for an rlogin session going away and then suddenly when there was activity over the TCP VC a new physical link on perhaps a different interface might be established which might end up with a new IP address. Alternatively if possible I would probably like to move calls off the ISDN medium onto the ethernet medium if a dead network suddenly became alive. But given that IP and TCP are apparently really only one layer it can't be done. In any case the problem probably isn't too important since ISDN is too slow to be useful for real networking. Of course for multihomed hosts the reliability issue might be important, but I guess it just can't be done.
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: Wed, 4-Nov-87 22:43:08 EST From: phil@amdcad.AMD.COM (Phil Ngai) To: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge
In article <8711040945.AA17936@ucbvax.Berkeley.EDU> snorthc@NSWC-OAS.ARPA writes:
>We have a growing investment in
>Bridge Communications' IP routing products.
>One such Bridge box that has served us well in the past is the GS-3.
Now that Bridge Communications has been purchased by 3Com, I look
forward to the day when we can refer to BCI's GS/3 IP routers as 3Com
boxes instead of "bridge boxes".
--
I speak for myself, not the company.
Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or amdcad!phil@decwrl.dec.com
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Wed, 4-Nov-87 23:27:32 EST From: karn@faline.bellcore.com (Phil R. Karn) To: comp.protocols.tcp-ip Subject: Internet routing problems
Our gateway between bellcore-net and the ARPANET is ipswitch.bellcore.com, a Sun 3/160 running Sun Unix 3.4 and Sun Link DDN 5.0. We're running Kirton's EGP as distributed by Sun. Lately I've noticed some rather persistent routing connectivity problems in the Internet. Many destinations fail to respond to packets sent from hosts on bellcore-net (128.96) but are shown to be up when I initiate connections from ipswitch. A given host can be unresponsive for days. I know that ipswitch is sending the proper connectivity information to the core because I can see bellcore-net in another ARPANET machine's routing table. I suspect the problem is related to the inability of many gateways to handle ever-larger EGP updates. I noticed problems on ipswitch in that entries for outside sites would appear in the routing table shortly after booting, but after several minutes they would disappear leaving only the entry for network 10. Some sleuthing revealed that every incoming EGP update had a checksum error. I increased the size of MAXPACKETSIZE in defs.h from 1006 to 2048 and recompiled. The problem has not recurred. I suspect that there are many other gateways out there with the same problem; what can we do to get them fixed? Phil
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: Thu, 5-Nov-87 09:58:00 EST From: CLYNN@G.BBN.COM.UUCP To: comp.protocols.tcp-ip Subject: Re: details on misbehaving IP implementations
Phil, I think that 2 and 3 (returning port unreachable) are not bugs but are actually doing what the spec says they should. 4 (returning protocol unreachable in response to broadcasts) is probably not a good idea, but the specs were written before broadcast were widely used. Charlie
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: 5 Nov 1987 09:58-EST From: CLYNN@G.BBN.COM To: faline!karn@BELLCORE.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: details on misbehaving IP implementations
Phil, I think that 2 and 3 (returning port unreachable) are not bugs but are actually doing what the spec says they should. 4 (returning protocol unreachable in response to broadcasts) is probably not a good idea, but the specs were written before broadcast were widely used. Charlie
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: Thu, 05 Nov 87 14:34:46 -0500 From: M C Srivas <srivas@UDEL.EDU> To: system@UDEL.EDU, acm@UDEL.EDU, f-troup@UDEL.EDU, arpanet-bboards@mc.lcs.mit.edu, big-lan@suvm.acs.syr.edu, ibm-nets%bitnic.BITNET@wiscvm.wisc.edu, info-nets@think.com, protocols@rutgers.edu, tcp-ip@sri-nic.arpa, telecom@xx.lcs.mit.edu Subject: Robert Lucky
Does anyone know where I could access papers published by Rob Lucky? His papers will most probably deal with limitations, etc. of the various optical networking technologies. Thanks. Srivas. ______________________________________________________________________________ Network: ARPA: srivas@udel.edu BITNET: srivas@udel.edu CSNET: srivas%udel.edu@relay.cs.net UUCP: ...!ihnp4!berkeley -\ ...!allegra!berkeley -->!srivas@udel.edu ...!harvard -/ ______________________________________________________________________________
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: Thu, 5-Nov-87 12:08:20 EST From: heker@JVNCA.CSC.ORG.UUCP To: comp.protocols.tcp-ip Subject: routing changes
We are experiencing a large number of routing changes in the kernel of one of our VAX8600 "gateways". The number of changes has increased dramatically due to some route instabilities (that are not the topic of this message). The question is how the number of changes can affect the performance of our system?. We see about 1000 route changes in the kernel in periods of 10 minutes. This is as you can see *extremely* high. But does this degrade the system performance at all?. I also want to point out that this route changes are then propagated to other systems (VAX750s). And all dance at the same rithm. Any comments about this will be greately appreciated. -- Sergio ----------------------------------------------------------------------------- Sergio Heker tel: (609) 520-2000 Internet: "heker@jvnca.csc.org" Bitnet: "heker@jvnc" JOHN VON NEUMANN NATIONAL SUPERCOMPUTER CENTER, JVNCnet Network Manager -----------------------------------------------------------------------------
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 5 Nov 87 07:37:27 GMT From: jbs@eddie.mit.edu (Jeff Siegal) To: tcp-ip@sri-nic.arpa Subject: ARPANET<->MILNET problems
I've been trying to ftp some files from ECLA.USC.EDU (on MILNET) to MIT (on ARPANET) and have had no success for the past week. The Unix ping program reports round-trip-times of 20-40 seconds and packet loss rates varying between 70 and 100 percent. Is there some current problem that is likely to be corrected, or should we give up and resort to Federal Express and magtape? Jeff Siegal
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: Thu, 5-Nov-87 12:38:57 EST From: minshall@OPAL.BERKELEY.EDU To: comp.protocols.tcp-ip Subject: Re: Separation of Layers
>... > Alternatively if possible I would probably like to move calls off the > ISDN medium onto the ethernet medium if a dead network suddenly became > alive. > > But given that IP and TCP are apparently really only one layer it > can't be done. > > In any case the problem probably isn't too important since ISDN is too > slow to be useful for real networking. Of course for multihomed hosts > the reliability issue might be important, but I guess it just can't be > done. No, TCP and IP are not one layer. Back in the days of experimental ethernets, there were only 8 bits of addressing in the ethernet packets. The way of mapping an IP address to an ethernet address was to use the lower order 8 bits of the IP address as the ethernet address (though actually what really happened was that the ethernet address was assigned to the lower order 8 bits of the IP address). You wouldn't argue that the ethernet and IP were really one layer; however, the mapping between IP address and ethernet address was merely that of extracting - a projection. On current ethernet, a projection from the 32-bit IP address space won't work, since the map needs to be onto, and the ethernet address space is 48 bits. So, we have ARP. A TCP address is composed of two parts: a 32-bit IP address, and an 8-bit port identifier. To convert a TCP address into an IP address is, again, a projection. That this is so does not somehow merge the two layers into one. They are two layers. (By the way, a machine is certainly free to send a packet on an interface with address 128.32.13.4, and give it an IP source address of 10.0.3.4; this is even justified if that machine has an interface with "address" 10.0.3.4 and that interface is down and there is an already existing connection to a local port of 10.0.3.4. However, you are correct in assuming that in this situation, the connection partner will probably not survive the fact that the 10.0.3.4 interface has gone down - unless the sender uses IP source routing and the partner remembers the last source route received on the connection.)
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: Thu, 5-Nov-87 14:22:12 EST From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: routing changes
Sergio, I'm not sure what you mean by "routing changes." There certainly are vast quantities of changes involving relatively small changes in delay and even uncomfortable quantites involving significant (factor of two) changes. Not many of these involve changes in route, however. While the situation is serious and must be fixed, I don't think the routing overhead itself is a significant factor in performance. Hellograms are rate-limited to no more than one every 400 ms in even the worst case. Let's hear it for all those gated's honking strange distances to the fuzzies. Can someone answer the questions I put out about their behavior? Dave
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: Thu, 5-Nov-87 16:07:00 EST From: Petty@MIT-MULTICS.ARPA To: comp.protocols.tcp-ip Subject: ARP over FDDI
Hello I am new to the network. If this topic has already been addressed, I aplologize in advance. I am curious if anyone has thought about using ARP over an FDDI network? It seems like a match made in UCBerkeley. The problem as I see it, is that FDDI can have either 16 or 48 bit addresses. If the gurus of FDDI who hand out the numbers would ensure that the first 32 bits of a 48 bit hardware address were non-zero, then life would be good. Thanks in advance. Jim Petty Spartacus Inc.
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: Thu, 5-Nov-87 17:06:28 EST From: BILLW@MATHOM.CISCO.COM (William Westfield) To: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge
Now, what I'm gonna do is put a permanent entry in Elsie's
ARP cache with Bossie's IP number and ethernet address.
Well, first of all, the idea of loading up your host with
permanent ARP entries is pretty gross, and defeats the the
purpose of ARP anyway.
Second, and more important is that hardware ethernet addresses
aren't any more imutable that IP addresses anyway - I can easilly
change my hardware adrress to anything I want. DECNet does this
sort of thing as a matter of course - setting the decnet host
numbers into the hardware address. Thus having a permanant
ARP entry doesn't buy you much additional security anyway.
Bill Westfield
cisco Systems.
-------
-----------[000050][next][prev][last][first]----------------------------------------------------
Date: Thu, 5-Nov-87 18:50:29 EST
From: RAF@NIHCU.BITNET ("Roger Fajman")
To: comp.protocols.tcp-ip
Subject: Multiple subnets on one physical networkI guess that this may have been discussed before, but due to a problem with our mailer here I wasn't getting much mail from this list at the time. Anyway, we recently acquired a class B network number for our planned campus network and the issue arises about how to divide the 16-bit address space between subnet numbers and host numbers. If we make the subnet field small, we probably won't have enough subnet numbers (a 5 bit subnet field gives 30 networks of 2046 hosts each) and a lot of address space is wasted on small subnets. If we make the subnet field large, we won't have enough host numbers for our largest subnet (an 8 bit subnet field gives 254 networks of 254 nodes each). This naturally leads to the question: can multiple subnet numbers be assigned to the same physical network? Since we plan to use Proteon p4200 Gateways for at least some things, I called Proteon and asked them. They told me that there is no problem, as each network interface can be assigned up to 16 IP addresses, thus allowing it to respond to an IP address for each of up to 16 subnets that reside on the same physical network. I was told that this was desirable because many hosts require that any gateway that they use be on their own subnet. Now I was recently shown a copy of a message from last July that said that in such a situation, a Unix system would receive Ethernet broadcast packets containing IP broadcast packets for other subnet numbers, not realize that they were broadcast packets for another subnet, and try to process (forward or redirect) them in some way. More recently, I received a message on this list that said that a Unix system would not try to perform gateway functions unless it had more than one network interface, regardless of how its parameters were set. Anyway, what is the truth? Can we assign multiple subnet numbers to the same physical network or not? What have others done about this problem? Roger Fajman RAF@NIHCU.BITNET National Institutes of Health
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: Thu, 05 Nov 87 18:50:29 EST From: "Roger Fajman" <RAF%NIHCU.BITNET@wiscvm.wisc.edu> To: TCP-IP@SRI-NIC.ARPA Subject: Multiple subnets on one physical network
I guess that this may have been discussed before, but due to a problem with our mailer here I wasn't getting much mail from this list at the time. Anyway, we recently acquired a class B network number for our planned campus network and the issue arises about how to divide the 16-bit address space between subnet numbers and host numbers. If we make the subnet field small, we probably won't have enough subnet numbers (a 5 bit subnet field gives 30 networks of 2046 hosts each) and a lot of address space is wasted on small subnets. If we make the subnet field large, we won't have enough host numbers for our largest subnet (an 8 bit subnet field gives 254 networks of 254 nodes each). This naturally leads to the question: can multiple subnet numbers be assigned to the same physical network? Since we plan to use Proteon p4200 Gateways for at least some things, I called Proteon and asked them. They told me that there is no problem, as each network interface can be assigned up to 16 IP addresses, thus allowing it to respond to an IP address for each of up to 16 subnets that reside on the same physical network. I was told that this was desirable because many hosts require that any gateway that they use be on their own subnet. Now I was recently shown a copy of a message from last July that said that in such a situation, a Unix system would receive Ethernet broadcast packets containing IP broadcast packets for other subnet numbers, not realize that they were broadcast packets for another subnet, and try to process (forward or redirect) them in some way. More recently, I received a message on this list that said that a Unix system would not try to perform gateway functions unless it had more than one network interface, regardless of how its parameters were set. Anyway, what is the truth? Can we assign multiple subnet numbers to the same physical network or not? What have others done about this problem? Roger Fajman RAF@NIHCU.BITNET National Institutes of Health
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: Thu, 5-Nov-87 19:17:50 EST From: BILLW@MATHOM.CISCO.COM (William Westfield) To: comp.protocols.tcp-ip Subject: Telephone Access Controllers (TACs) and SLIP...
Is there any interest in a TAC like device capable of running SLIP (Serial Line IP) on its terminal interfaces ? As I currently envision this, each serial line could be a logical host when acting as an IP device, and just a normal port when acting as a terminal. This might provide some performance improvement over things like kermit for downloading/uploading files.... Bill Westfield cisco Systems. -------
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: Thu, 5-Nov-87 19:26:59 EST From: satish@ACC-SB-UNIX.ARPA (Satish B. Joshi) To: comp.protocols.tcp-ip Subject: Ethernet/IP Testing/Monitoring Tools
Does anyone know of any tools for monitoring and/or testing networks in Ethernet, Unix-4.3BSD(VAX), and TCP/IP environment? I believe that some tools similar to SUN's "etherfind", and software to generate bogus IP datagrams were discussed here. I will appreciate any information about software to test protocols, specific interface boards or gateways, and to monitor Ethernets. Thanks. Satish <satish@acc-sb-unix.arpa> ------
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: Thu, 5 Nov 87 22:10:12 EST From: fedor@nic.nyser.net (Mark Fedor) To: Mills@udel.edu, heker@jvnca.csc.org Cc: boyle@jvnca.csc.org, nsfnet@sh.cs.net, tcp-ip@sri-nic.arpa Subject: Re: routing changes
> >Date: Thu, 5 Nov 87 15:40:15 est >From: Sergio Heker <heker@jvnca.csc.org> > >Dave, > >What I mean by routing changes, are actual routing changes in the kernel >as per "gated". The following list is only a sample for one particular >network and over 10 minutes. It illustrates metric changes and not >route changes, but at some points, these metric changes, as observed from >our bunker translate into counting to infinity from neighboring gateways >(as we have observed for certain networks). The problem is two fold, >one is to determine how much this affects our systems, and second is to >determine the cause for this unstable information. > >-------- > >CHANGE dst 192.31.83.0, router 128.121.50.20, metric 11102, proto HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 2701 fromproto HELLO >CHANGE dst 192.31.83.0, router 128.121.50.20, metric 11778, proto HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 2701 fromproto HELLO >CHANGE dst 192.31.83.0, router 128.121.50.20, metric 12446, proto HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 2701 fromproto HELLO >CHANGE dst 192.31.83.0, router 128.121.50.20, metric 1647, proto HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 2701 fromproto HELLO >CHANGE dst 192.31.83.0, router 128.121.50.20, metric 1405, proto HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 1647 fromproto HELLO >CHANGE dst 192.31.83.0, router 128.121.50.20, metric 3615, proto HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 1402 fromproto HELLO >CHANGE dst 192.31.83.0, router 128.121.50.20, metric 2464, proto HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 1402 fromproto HELLO >CHANGE dst 192.31.83.0, router 128.121.50.20, metric 4242, proto HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 1402 fromproto HELLO >CHANGE dst 192.31.83.0, router 128.121.50.20, metric 7120, proto HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 1402 fromproto HELLO >CHANGE dst 192.31.83.0, router 128.121.50.20, metric 3512, proto HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 1402 fromproto HELLO >CHANGE dst 192.31.83.0, router 128.121.50.20, metric 1647, proto HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 1402 fromproto HELLO >CHANGE dst 192.31.83.0, router 128.121.50.20, metric 1406, proto HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 1402 fromproto HELLO > >------- > > -- Sergio > > >----------------------------------------------------------------------------- >Sergio Heker tel: (609) 520-2000 >Internet: "heker@jvnca.csc.org" Bitnet: "heker@jvnc" >JOHN VON NEUMANN NATIONAL SUPERCOMPUTER CENTER, JVNCnet Network Manager >----------------------------------------------------------------------------- > >>> Sergio, The excerpt from the log file shows no kernel route changes at all! The unix kernel only keeps info about the destination and gateway of a route (among other things), but not the metric. Notice that the gateway never changed so there was never a kernel change during the log above. Gated keeps the metric and the metric change was made by gated. Now that this is out of the way, when this metric changing occurs, it of course takes up more system time cause gated is working harder. When the gateway changes like mad is when you get kernel route table thrashing. Mark P.S. I don't know off hand why this is happening, although it is a midnet....
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: Thu, 5-Nov-87 22:31:54 EST From: ORCHARD/BRUC@SCARECROW.WAISMAN.WISC.EDU (Bruce Orchard) To: comp.protocols.tcp-ip Subject: TCP maximum segment size determination
Consider a TCP connection passing through 3 networks: An Ethernet, the ARPANET, and another Ethernet. There are gateways between each Ethernet and the ARPANET. At connection time, each host must choose a maximum segment size for the TCP segments it transmits. The selection algorithm is generally to take the minimum of the maximum size allowed by the receiver (given in the TCP maximum segment size option), the maximum size allowed by the network the host is connected to (in this case, an Ethernet), and the maximum the transmitting host can handle. Allowing integral multiples of the local network maximum would be reasonable too. All this has to allow enough space for headers. Now the maximum size allowed by an Ethernet is 1500 bytes, but the maximum allowed by the ARPANET is 1007 bytes. If a maximum segment size greater than 1007 is picked by the transmitting end, the gateway going into the ARPANET will fragment the message. A segment of 1500 bytes would get split into one of about 1000 bytes and another of about 500 bytes. One particularly poor choice I have seen used is a maximum segment size of 1024 bytes. Since the 1024 bytes excludes headers, this results in one fragment of 1007 bytes and another 77 bytes. The real problem is that the transmitting end has no knowledge of the limits of networks it is not connected to. Therefore, I propose adding a new option to the IP header. This option would give the minimum of the maximum transmission units of any network that handled the packet. The originating end would set it to a large value. Each node that transmitted the packet would compare the value given in the option to the maximum transmission unit of the outgoing network. If the network value were less, the value in the option would be reduced to the network value. This IP header option would be used by TCP on the packet that includes the TCP maximum segment size option. The receiving TCP would consider both the maximum allowed by its peer TCP (in the TCP option) and the maximum allowed by any network along the way. It would probably take the lessor of the two. One limitation of this proposal is that all packets of a TCP connection do not necessarily pass through the same networks. Actually, given the way the networks are connected, all packets usually go through the same networks. Also, if one packet takes a different route from an earlier packet, the second route could be on the same kind of network (for example, two parallel Ethernets). Regardless, the consequence of a poor choice is reduced throughput, not failure. Bruce Orchard University of Wisconsin-Madison P.S. Is the MTU of SATNET really 256 bytes, as given in IEN 192?
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: Thu, 5-Nov-87 22:32:05 EST From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: routing changes
Sergio, Ah yes, the infamous 192.31.x nets. These dudes have been bouncing all over t the map for some time now. The distance values for these nets are not provided by the fuzzballs, but by gated at some site or other. WHen they count to infinity they have in fact become unreachable. This is a classic example of what unstable metrics can do to a distributed Bellman-Ford algorithm. I have been working feversihly to harden the algorithm so that even these wild swings won't destabilize the algorithm, but when distances change from one sample to the next by over fifty percent, what can any algorithm do? I repeat my statement made at least a dozen times: where is the source of those violent delay excursions and what gated is generating them? Having said that, note that even these severe transients should not adversely affect the system throughput, at least for the nets not rocking to and fro, since the hello messages are rate-limited. On the other hand, traffic for nets counting to infinity can clearly gobble up dangerous levels of traffic. That's why I have been spending so much time trying to avoid the counting problem. THe only way to do that is to latch sudden increases in delay and prevent further decreases until the hold-down timer expires, which is what the present system does. I have had to experiment somewhat in order to gauge the sensitivity of the latch, which is presently set at a factor of two. The latch regularily snares at least some of the surges, but not all, as you can see from your data. I can't make the latch more sensitive without snaring a lot of benign wobbles, such as occasional retransmissions on UIUC - NCAR lines, for example. Nevertheless, I have tuned the algorithm a lot in the past month and, at least in the testing swamps, it seems to be working well. It has been suggested that JVNC has more trouble than most because that is the only spot running gated on two machines on the same Ether. I thought Maryland was doing that as well. While they seem to be having trouble of their own, destabilized routes do not seem to be a serious problem there. There are two things I would recommend (again): first, identify all those gated configurations where only a single path is available to the networks being squawked and set the squawked delay to zero, just plain zero. Second, where multiple paths to a net exist, pray to the metric-translation god and really, truly and verily conform to the rules I suggested in my earlier memo. In any case, the clock-offset fields associated with each net in the hello message should be set to zero and the date in the header should be marked invalid. This seems like a pretty simple thing to check. Dave
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: Thu, 5-Nov-87 22:35:13 EST From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: routing changes
Folks, My apologies to the tcp-ip list for my recent reply to Sergio's message, which must have seemed rather esoteric to most of you. I overlooked the "tcp-ip" addressee in the return address list of the message. On the other hand, if someone wants to start that game, I would be happy to play. Dave
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: Thu, 5-Nov-87 22:40:31 EST From: fedor@NIC.NYSER.NET (Mark Fedor) To: comp.protocols.tcp-ip Subject: Re: routing changes
>Date: Thu, 5 Nov 87 14:22:12 EST >From: Mills@udel.edu >Subject: Re: routing changes > [ DELETED TEXT - MF ] >Let's hear it for all those gated's honking strange distances to the >fuzzies. Can someone answer the questions I put out about their behavior? > >Dave > Dave, I must admit due to some traveling and moving, I have not read my mail too carefully. As soon as I catch up and find the questions you put out, I will be glad to answer them. Or you can send me a summary of your questions and I'll see what I can do..... Mark NYSERNet Inc. (this is the last time I specify this! Y'all should know I work there by now.) :^) P.S. can you elaborate "strange distances"?
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: Thu, 5-Nov-87 23:38:35 EST From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: routing changes
Mark, Yeah, I know who you work for now, but if I admitted that you might have an excuse to wiggle off the hook. The hook seems to have already impaled me, as you may have noticed. Strange distances mean anything from 100 ms to somewhere in the middle of Channel 4. Sergio's is a typical example. As for rounding up all the messages I sent on the topic, gimme a break. There must be a hundred of them last month alone. From reports by returning scouts to the INENG meeting, the likely cause may be (a) incompatible gated versions and/or configurations, (b) unstable ripspeakers behind gated or (c) metric conversion violations when more than a single access path is available. Dave
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: Fri, 6-Nov-87 02:20:54 EST From: hedrick@ARAMIS.RUTGERS.EDU (Charles Hedrick) To: comp.protocols.tcp-ip Subject: new Arpanet end to end protocol
I have just heard from a reliable source a fairly interesting fact about the new end to end protocol implemented in PSN 7.0. (Note that my terminology is probably slightly off in this message. I don't know anything about the imp to host protocol, so I am almost certainly introducing some distortion in passing on this information.) Apparently one of the efficiency improvements in the new end to end protocol is that the IMP's will no longer attempt to return a RFNM for each packet. You will be expected to look at the ID number included in the RFNM's. Any outstanding RFNM's with ID numbers lower than the current one are also to be considered as acknowledged. Many implementations apparently simply count RFNM's. They assume that one acknowledgement is received per packet. This will no longer be true with the new end to end protocol, and so these implementations will break. I have some reason to think that most existing implementations fall into this category. Tests of the new end to end protocol are scheduled for Nov 7, 14-15, and 18. Implementors should be alert to misbehaviors during these test periods.
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: 6 Nov 87 05:18:57 GMT From: ihnp4!homxb!mtuxo!mtune!codas!ufcsv!beach!esj@ucbvax.Berkeley.EDU (Eric S. Johnson) To: tcp-ip@sri-nic.arpa Subject: Re: ARPANET<->MILNET problems
In article <7353@eddie.MIT.EDU> jbs@eddie.MIT.EDU (Jeff Siegal) writes:
>I've been trying to ftp some files from ECLA.USC.EDU (on MILNET) to
>MIT (on ARPANET) and have had no success for the past week. The Unix
>ping program reports round-trip-times of 20-40 seconds and packet
>loss rates varying between 70 and 100 percent.
>
>Is there some current problem that is likely to be corrected, or
>should we give up and resort to Federal Express and magtape?
>
>Jeff Siegal
I have had a very similer problem making contact to a host inside
of the berkeley network. Same horrible round trip times and
loss rates. It puzzles me because our contact with ucbarpa and
ucbvax (both arpa sites) is fine, but the contact with the site
inside the berk-net is rotten.
I had a clear steady connection on Friday (10-30) in the mid morning.
But instead of making a large transfer then, I thought I would be a
nice guy and wait till late that night. Sometime that day something
snaped and I haven't been able to make a decent connection since.
Perhaps related: I also have not been able to make contact with
univ. of Wisc hosts, yet have easy contact with cs.wisc.edu.
(again directly on the arpanet)
As I understand it, some modifications are being made to the core
Arpa/Milnet routers (and maybe NSF). Does someone know if this is
the cause of my problems, and when/if things will clear up again?
--
In Real Life: UUCP: ...{ihnp4,rutgers}!codas!ufcsv!ufcsg!esj
Eric S. Johnson II Internet: esj@beach.cis.ufl.edu
University of Florida Ignore headers, reply only to above!
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: Fri, 6-Nov-87 10:31:44 EST From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) To: comp.protocols.tcp-ip Subject: Re: ..."layering violations"
Although you probably make a valuable distinction (given confirmation that X.25 actually does have a "Host Down" return--I remember something like Virtual Circuit Failure, or the like, myself), I was not, of course, talking about X.25 explicitly. (Nor was I talking about daemons explicitly.) Always delighted to learn of still another X.25 faux pas, though. (I'd confirm the Host Down question myself, but I don't have an X.25 spec handy, even though I acknowdlege that it's a seminal fascicle.) Just so the principle doesn't get lost in the worrying over the example, let me rephrase: Just as there's no need to close connections before their time, there's no need to keep them open beyond their time. Good judgment is expected to be applied to the issue of what time it is in the life of given connections in given contexts. OK? cheers, map P.S. Maybe it's a quibble, but wouldn't X.25 call it DTE Down, anyway? (Or is it DCE? Well, DxE, at least.) -------
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: Fri, 6-Nov-87 12:27:19 EST From: jbvb@ftp.UUCP (James Van Bokkelen) To: comp.protocols.tcp-ip Subject: ARCnet
Is there any standard for ARCnet encapsulation of IP? Has anyone even done it? Given things I have heard from ARCnet manufacturers, example hardware drivers are available. The process looks like: 1. Locate or develop a standard for IP encapsulation and address resolution. I have been told that ARCnet has a 1-byte hardware address. This would seem to point at a convention like ProNET (map low byte of the hardware address to the low byte of the IP address), instead of a permutation of ARP. 2. Obtain an example hardware driver and some hardware. Starting with MIT's P1300 driver, I would imagine that one could get on-line in a month or less. I would probably have already done this if I had time, or felt sufficiently wizardly to promulgate an encapsulation scheme. James B. VanBokkelen FTP Software Inc.
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: Fri, 6-Nov-87 14:45:07 EST From: SATZ@MATHOM.CISCO.COM.UUCP To: comp.protocols.tcp-ip Subject: EGP instability
Is anyone else having trouble maintaining their peer relationships with the core? We are seeing excessive problems with high packet loss and eventually being dropped. -------
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: Fri, 6-Nov-87 15:02:51 EST From: jim@ektools.UUCP (James Hugh Moore) To: comp.protocols.tcp-ip Subject: TCP-IP in the Public Domain?
------------------------------------------------------------------------------ What part of tcp-ip is in the public domain? I understand that DARPA or some related government agency specified what tcp-ip is. Does anyone have the reference to the government document, or an english version of it? Is there source code for tcp-ip on anything (especially an implementation for arcnet would be nice) that is public domain? Does anyone know of an existing implementation under arcnet or qnx? If these questions seem kind rudimentary, I am a mathematician, and I am posting for a friend, and he needs the answers. I want to thank you in advance for all of your time and effort!!! May God Bless You, in Jesus Name Jim Moore - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - James H. Moore, Software Tools Group Product Software Engineering Lab Eastman Kodak Co. Email: allegra!rochester!kodak!ektools!jim USMail: Dept 47, EP 5-2, Eastman Kodak Co., Rochester, NY 14650 Disclaimer: Opinions expressed are my own, and DO NOT represent the opinions or policies etc of Eastman Kodak Co. as a whole. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: 6 Nov 87 11:43:58 GMT From: steinmetz!vdsvax!barnett@uunet.uu.net (Bruce G Barnett) To: tcp-ip@sri-nic.arpa Subject: Is there an EGP that is available?
If we wanted to run EGP (External Gateway Protocol) on an Internet/mail gateway for the purposes of dynamically finding routes to other machines, where do we get this program? Is the source available? I know that Sun sells it with their DDN SunLink product. What about Ultrix/4.3bsd? What are the other protocols available - and what do people recommend? Thanks, -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: Fri, 6 Nov 87 16:56:57 EST From: MORAN <moran@vax1.acs.udel.edu> To: acm@UDEL.EDU, arpanet-bboards@mc.lcs.mit.edu, big-lan@suvm.acs.syr.edu, f-troup@UDEL.EDU, ibm-nets%bitnic.BITNET@wiscvm.wisc.edu, info-nets@think.com, protocols@rutgers.edu, srivas@UDEL.EDU, system@UDEL.EDU, tcp-ip@sri-nic.arpa, telecom@xx.lcs.mit.edu Subject: Re: Robert Lucky
No.
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: Fri, 6-Nov-87 18:28:30 EST From: eugen@clan.UUCP (Eugen Bacic) To: comp.protocols.tcp-ip Subject: Re: Wanted: TCP/IP source
I am also looking for the source for a complete PD TCP/IP implemention. I would appreciate any information anyone regarding their experiences with Phil Karns implentation. Eugen Bacic @ ..!utzoo!dciem!nrcaer!clan!eugen
-----------[000069][next][prev][last][first]----------------------------------------------------
Date: Sat, 7-Nov-87 03:17:23 EST
From: schoff@NIC.NYSER.NET ("Marty Schoffstall")
To: comp.protocols.tcp-ip
Subject: Re: Separation of Layers
I should point out that at MIT we no longer use network
addresses as a form of authenticity. We now use our encryption based
"Kerberos" authentication service. The code you wrote to use the
subnet as a means of determining authentication has long since been
retired.
Is there going to be an RFC on the authentication service???
Marty
-----------[000070][next][prev][last][first]----------------------------------------------------
Date: Sat, 7-Nov-87 12:06:17 EST
From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To: comp.protocols.tcp-ip
Subject: TCP/IP Slang GlossaryA fuzzball is a gateway, or IP router, (running on PDP11s, I think) which Dave Mills authored. They are common, because the software is in the public domain, and they seem to have many desirable characteristics, particularly for tinkerers. A bogon is a particle (alias packet) that transmits bogosity. I guess it is also a happy accident that it rhymes with Vogon, because the bogus info is frequently offensive and/or destructive. Gong? I dunno. jbvb
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: Sat, 7-Nov-87 12:15:37 EST From: wesommer@athena.mit.edu (William Sommerfeld) To: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge (really: NFS "security")
In article <8711062349.AA04106@ucbvax.Berkeley.EDU> snorthc@NSWC-OAS.ARPA writes:
>OK, I'll bite. We have been looking at NFS as a UNIX/VMS server solution
>for PCs. From the begining of the investigation we were looking for
>things like the 'huge security holes'.
Huge security holes is correct. [I won't even talk about vulnerability
to malformed packets]
At least in the implementations that I have seen (the "portable NFS
release"), the NFS server daemon does not look at the client's IP address at
all; thus, it will permit access to anyone who can send you UDP
packets on port 2049.
There is a minor complication, which is that to do anything
meaningful, you need to know a "file handle" for a directory on one
filesystem. Once you have the file handle, you can do anything you
want to the file system, because you can claim an arbitrary user-id in
the packet, and the server will trust you.
The idea that you have to be "root" on the client to do this is
incorrect. It is possible to write a user-level program, using the
Sun RPC library, which talks directly to the NFS server of your choice
(I know.. it took me about a day to do this, working from the NFS
protocol spec).
Anyway, back to the weak spot. You can get a file handle from the
mount daemon (/usr/etc/rpc.mountd). It reads /etc/exports to find out
which hosts it can give out file handles to. Unfortunately, in some
versions, it trusts the client to name itself (there is a hostname in
the request packet, filled in by the client).
In addition, it is possible to make up a valid file handle from whole
cloth. In the current implementations, the file handle is the tuple
of {device_id, inode_number, generation_number}. The device_id is the
UNIX major and minor device number of the device the partition is on.
The inode number is just a simple index into the inode table of the
filesystem (inode number 2 is the root of the partition, for
historical reasons), and the generation number is there to ensure that
if an inode is reused for a new file, the new file doesn't get
confused with the old. These are initialized to all zero by the
standard (non-NFS) newfs.
There is a program, called "fsirand", which randomizes the generation
numbers of all the inodes on a partition. It is important to run this
for _all_ partitions mounted on the server, not just the ones which
you want exported, because otherwise someone will be able to use the
{device_id, 2, 0} file handle, and get at the root of one of your
other filesystems.
Thus, the generation numbers become almost as critical as the root
password to the server. Is any effort exerted to keep them secret?
No. They fly around on the ethernet in the clear. They can also be
extracted if you have access to read kernel memory (/dev/kmem or
/dev/mem) on the server (typically allowed on pre-4.3 BSD unix
systems).
There is light at the end of this tunnel, fortunately.
Here at Athena, we implemented a very small patch to NFS which gets
around this chain of security holes. We modified the NFS server to
maintain a hash table which maps {client IP address, user_id} to
{local uid, group set}. Map entries are controlled by a modified
rpc.mountd which uses the Kerberos authentication system to verify the
authenticity of the client. Rather than trusting the client machine
to give the user id and group set of the user, the server instead
looks for a mapping in the hash table. If no mapping is found, the
request is either remapped to uid -2, or rejected immediately,
depending on how the server is configured. This has been in use for
about five or six months (and in heavy use since September), with very
few problems.
This is not as secure as Sun's experimental secure NFS system, which
includes an authenticator on each request, but our approach involves a
minimal performance overhead (when you use VAX 11/750's as servers,
you need all the help you can get...), and requires no modifications
to the client kernel, and also doesn't require any protocol changes to
NFS itself.
Bill Sommerfeld
wesommer@athena.mit.edu
-----------[000072][next][prev][last][first]----------------------------------------------------
Date: Sat, 7-Nov-87 12:15:57 EST
From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To: comp.protocols.tcp-ip
Subject: Re: Subnetting: I'm not sure I understandSubnetting is explained best in RFC950. Most of what it is good for is allowing you to divide one of the larger types of network (Class A or Class B - 24 or 16 bits worth of host number) up into smaller administrative or cable-oriented networks. You are assumed to have IP routers (gateways) between them to handle internal forwarding, but to the rest of the world, you look monolithic (i.e. they send to net 128.127, and don't care that it has 254 subnets, each of the form 128.127.xxx, because your gateways hide that from the world). You can use it on class C addresses, but with only 254 hosts, there is less to divide. Almost all subnetting implementations allow you to do your division on bit boundaries, but there have been a few which could only do it by bytes. jbvb
-----------[000073][next][prev][last][first]----------------------------------------------------
Date: Sat, 7-Nov-87 12:33:35 EST
From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To: comp.protocols.tcp-ip
Subject: Re: Multiple subnets on one physical netAs usual, everyone was right, in the context. Mike Karels described the behaviour of his Unix, 4.3, which ought to work right in this situation. Other people have described *their* Unices, and other O/Ss, like Phil's LISPMs, which are going to give trouble. There are several problems you'll run into: The first is that some 4.2- derived systems believe in broadcast addresses of Net.0, and other systems believe in Net.255. The second is that some manufacturers leave their Unices believing that they are IP routers, even when they have only one network interface. The third is that some manufacturers don't include code to implement the law "don't reply to broadcast packets unless you're *really* *sure* you ought to". The fourth is that some manufacturers don't understand about subnets. The end result of this is that on one net I know, an Old-Broadcastian sends an rwho packet, and 29 (or more - my monitor was only an XT) Sun and Vax New-Broadcastians immediately attempt to either forward the packet (they think they're gateways), or send an ICMP Net Unreachable (gateway-ism partly disabled). Great fun. Also available between systems that do and don't grok subnets, and the two together are greater than the sum or the parts. Phil Karn cited some misbehavers. There are others. All can be fixed if you have source, most can be fixed through patience and vigilance on the part of a network administrator (watching and making people correct mis-configured systems). jbvb
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: Sat, 07 Nov 87 17:43:29 -0500 From: Mike Brescia <brescia@PARK-STREET.BBN.COM> To: Greg Satz <SATZ@MATHOM.CISCO.COM> Cc: tcp-ip@SRI-NIC.ARPA, brescia@PARK-STREET.BBN.COM Subject: Re: EGP instability
Is anyone else having trouble maintaining their peer relationships
with the core? We are seeing excessive problems with high packet
loss and eventually being dropped.
Greg, There is an arpanet/internet 'event' happening which shows up as long
queues in both directions between the PSNs and the core gateways. Also, the
psn-gateway connection is broken frequently which causes all the queued
packets to be discarded. Does your gateway on the arpanet get clogged also?
One change that may have affected the system is the introduction of fragmented
NR messages (EGP updates), which now take 2 arpanet messages each longer than
128 bytes; the fragments are about 1000 bytes and 200 bytes, and growing.
Some facets of the problem that are being explored are the differences between
the arpanet PSN software release 7 and the old release 6, speeding up the
processors in the core systems (upgrade lsi-11/23 to /73), and checking the
timing on the EGP implementations.
Mike
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: Sat, 7-Nov-87 17:13:32 EST From: hedrick@ARAMIS.RUTGERS.EDU (Charles Hedrick) To: comp.protocols.tcp-ip Subject: Re: TCP/IP Slang Glossary
fuzzball - the name of a kind of IP router. It is based on an LSI-11, and is used on the NSFnet backbone and various other critical places. The code is maintained by Dave Mills, and is often referred to by him as "fuzzware". swamp - a collection of networks. The implication is that they overall architecture is somewhat dubious (e.g. connected by a mixture of level 2 and level 3 things, with several networks numbers on a single cable). bogon - a bogus packet, often a packet that has escaped the net it is supposed to be on, e.g. a packet on the Arpanet addressed to 127.0.0.1 (the Unix loopback interface address), however it is also used to refer to packets with other kinds of errors. Martian - properly speaking, a packet addressed to net 126.0.0.0, which is reserved for the Central University of Mars. By extension, any packet addressed to an unallocated or reserved IP address, or to a broadcast address. (These packets could also be called bogons, of course.) A "Martian filter" is a pieces of code designed to discard Martians.
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: Sat, 7-Nov-87 17:46:28 EST From: jones@NGP.UTEXAS.EDU (William L. Jones) To: comp.protocols.tcp-ip Subject: Re: Ethernet - Hyperchannel Gateway
How much cray2 cpu was required to run the memory to memory TCP
test at 17 mbit/sec?
William L. Jones
University of Texas System CHPC
-----------[000077][next][prev][last][first]----------------------------------------------------
Date: Sat, 7-Nov-87 21:09:15 EST
From: PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To: comp.protocols.tcp-ip
Subject: Re: TCP/DECnet interchange router for VMesS
Date: 2 Nov 87 19:34:27 GMT
From: unmvax!merlin!mcdermot@ucbvax.Berkeley.EDU (John McDermott)
I have a problem which I hope someone has already solved: I have a
TCP/IP net and a large DECnet net both served by a common VAX (vms).
Some hosts on the decnet network also run tcp/ip. All tcp is CMU/TEK for vms.
Now the question: are there drivers to encapsulate ip packets, send them
over the DECnet and then make them available for retransmission at the other
end? I need this because my VAX with Decnet is connected to the rest of
the DECnet network by a 56kb line and that line cannot be used for both
decnet and tcp/ip (for political reasons at least). Any help would be really
appreciated.
Well, you did say `any'. Mike Parker at McGill University (address
musocs!mcgill-vision!mouse@eddie.mit.edu) wrote an IP over DECnet
device driver for UNIX 4.3BSD. If you have any 4.3 hosts on your
subnet, you could make it the IP gateway to the other side of that
phone line. I believe that is what they do at McGill and it seems
to work fairly well. I heard about someone doing the same for VMS,
but I don't remember who (was it Lou Salkind at NYU?)
Hope this helps,
-Philip
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: Sat, 7-Nov-87 21:23:00 EST From: slevy@UMN-REI-UC.ARPA.UUCP To: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge
On IP & Ethernet address spoofing -- If there's no LAN bridge between you and the target, it's easy. If there is, you may still be able to fool the bridge into passing stuff onto your side. If you want to look like host X (of IP address X.IP and MAC-level address X.MAC), it may suffice to send out some packets with MAC source address X.MAC. When the bridge sees those, it may well get confused about where X.MAC really is, and start routing X.MAC-destined packets onto your part of the wire. Presumably this depends on the bridge's design, and I've never actually tried it, but it does sound plausible. Another trick, not dependent on the bridge behavior, would be to send an ICMP host redirect to the target, telling it to route traffic to X via your own IP address (or some bogus one which you were willing to ARP for). That should work even when X is up. We're considering making our own hosts ignore ICMP redirects for this reason, despite the loss of functionality. We're also considering fixing our gateways in an unorthodox way -- to look at the IP -source- address of arriving packets. If a packet arrives from host Y, on an interface to which that gateway would never route packets to Y, the gateway discards the packet. If all the gateways in a system[*] act this way, a spoofer can pretend to be someone else on the same net, but not someone on another net. So IP gateways can be made to be firewalls in a way that MAC-layer bridges can't (unless the bridges get their routing tables from the net administrator rather than learning by listening). In this case the gateways, too, need to be careful about what ICMP redirects they believe... perhaps by having an administrator-supplied list of GW's, where redirects are believed only if they point to (not just come from!) a legitimate GW. [*]Well... the above sort of works. I think it only really is reliable if the structure of the "system" is a special one -- where all the gateways and all the paths between them are trustworthy, and all the untrusted nets are one GW away from the trusted backbone. Redundancy is still possible, and the backbone can have any structure, but rigid separation of trusted from untrusted hosts & wires still is a pretty severe restriction. Maybe this amounts to an argument for higher-level, end-to-end authentication. While I'm at this, how about NFS security. I think the fake setuid hole can be plugged: SUN's NFS at least has a "nosuid" mount option, and you can just arrange to mount all non-system file systems with it. Then only the server of system files needs to be secure. However, a local superuser can get access to any non-root user's files simply by setting his uid to the right thing. So can any Joe with a PC who goes to the trouble to write an NFS client, which can claim to be any IP address, Ethernet address, and uid it wishes. And as far as I know, NFS (unlike TCP) won't even turn a hair if multiple clients on a net claim to be the same machine -- each ignores responses to the others' requests. SUN's RPC authentication scheme, which derives keys from user passwords, distributes them with a public-key scheme, and uses DES to authenticate transactions after the keys are established, seems promising in this regard. (It was written up in a paper in Summer '86 Usenix, and was supposed to be released with Sun 4.0 the last I heard, along with an NFS that optionally uses it.) One thing I worry about, though. It appears secure enough that people might be willing to allow root access across NFS. But, if anyone finds a hole allowing them to be root -without rebooting the machine- they'll easily gain root access to everything sharing filesystems with them -- a hole bigger than the present one. Stuart Levy, Minn. Supercomputer Center slevy@uf.msc.umn.edu, 612-626-0211
-----------[000079][next][prev][last][first]---------------------------------------------------- Date: Sat, 7-Nov-87 21:46:12 EST From: g-tasman@GUMBY.WISC.EDU To: comp.protocols.tcp-ip Subject: Re: ..."layering violations"
You suggest that if a "host down" indication is received, a daemon
should immediately close the associated TCP connection.
With an 1822 Distant Host connection to DDN, this may be a fairly
reasonable approach. However, a typical DDN connection of late has been
X.25 or HDH. Here, "host down" may have a more transitory meaning: simply
that there was noise on the host access line. The remote host may well
reappear with all TCP connections intact.
Consider in particular the case of a Telnet server. If connections
are cleared prematurely/incorrectly, extremely annoyed users will result.
On the other hand, I understand all too well the importance of eventually
detecting and closing "half-open" connections which result from an actual
crash (since these will eventually inhibit new remote terminal sessions).
The issue of distinguishing between a dead host and an "unhealthy"
host access line is likely to become increasingly serious over time, as more
DDN hosts switch to synchronous access protocols. For a network client,
remote host status can simply be reported to the (human) user. For a server,
however, I don't see a straightforward solution.
Mitchell Tasman
-----------[000080][next][prev][last][first]---------------------------------------------------- Date: Sat, 7-Nov-87 23:58:39 EST From: Mills@UDEL.EDU.UUCP To: comp.protocols.tcp-ip Subject: INARC Workshop announcement
Folks, This is a repeat of last month's announcement on a planned meeting of the Internet Architecture Task Force. Please note the meeting dates have been changed from the original 17-18 November to 17-18 December. The meeting place is unchanged. Please note also the revised and clarified wording in the announcement itself. The Internet Architecture Task Force (INARC) studies technical issues in the evolution of the Internet from its present architectural model to new models appropriate for very large, very fast internets of the future. It is organized as a recurring workshop where researchers, designers and implementors can discuss novel ideas and experiences without limitation to the architecture and engineering of the present Internet. The output of this effort represents advance planning for a next-generation internet, as well as fresh insights into the problems of the current one. The INARC is planning a two-day retreat/workshop for 17-18 December at BBN to discuss a fresh start on advanced internet concepts and issues. The agenda for this meeting will be to explore architecture and engineering issues in the design of a next-generation internet system. The format will consist of invited presentations on selected topics followed by a general discussion on related issues. Written contributions of suitable format and content will be submitted for publication in the ACM Computer Communication Review. In order to have the most stimulating discussion possible, the INARC is expanding the list of invitees to include any researchers with agenda to plow, axe to grind, sword to wield or any other useful instrument for that matter. While not a precondition for admission, participants are encouraged to contribute concise presentations, either written or oral (fifteen to thirty minutes), in electronic form to mills@udel.edu or in hardcopy form to Dr. David L. Mills Electrical Engineering Department University of Delaware Newark, DE 19716 (302) 451-6534 or 737-9211 Speakers will be selected on the basis of quality, relevance and interest. Every effort will be made to accomodate all participants that wish to attend; however, participants are asked to contact the chairman by electronic mail or telephone at least a week in advance to confirm their intention to attend. Following is a list of possible areas and issues of interest to the community. Readers are invited to submit additions, deletions and amendments. 1. How should the next-generation internet be structured, as a network of internets, an internet of internets or both or neither? Do we need a hierarchy of internets? Can/must the present Internet become a component of this hierarchy? 2. What routing paradigms will be appropriate for the new internet? Will the use of thinly populated routing agents be preferred over pervasive routing data distribution? Can innovative object-oriented source routing mechanisms help in reducing the impact of huge, rapidly changing data bases? 3.