The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: TCP-IP Distribution List - Archives (1983)
DOCUMENT: TCP-IP Distribution List for March 1983 (14 messages, 6964 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1983/03.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 1983 1451-PST
From:      Craig Milo Rogers  <ROGERS@USC-ISIB>
To:        don.provan@CMU-CS-A, KLH@SRI-NIC
Cc:        lloyd@EDN-UNIX, dedwards@USC-ISI, tcp-ip@SRI-NIC
Subject:   Re: Talking to TOPS-20
	From RFC 793, Transmission Control Protocol, September 1981, p 43:

	Note that acknowlegements should not be delayed or unnecessary
	retransmissions will result. One strategy would be to send an
	acknowlegement when a small segment arrives (with out updating the
	window information), and then to send another acknowlegment with
	new window information when the window is larger.

	Also, on p. 42:

	Thw window sent in each segment indicates tha range of sequence
	numbers the sender of the window (the data receiver) is currently
	prepared to accept.

	The implication is that, if your window opens, then you should
send a new segment to reflect that fact.  Page 43 also mentions that you
may wish to defer small updates to the window, and send a larger update
a little later.  The zero-window probe is designed only to recover from
the case that a zero-window update is lost or damaged.

	There is a more complete discussion of window algorithms in RFC 813,
Window and Acknowlegment Strategy in TCP, July 1982.

	Retransmitting a probe every second for every TAC connection could
lead to, shall we say, degraded ARPANET performance.  Of course, if every
TAC connection were doing that much printing, than perhaps performance
would already have degraded.

					Craig Milo Rogers
-------
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 March 1983 2031-EST (Tuesday)
From:      don
To:        Craig Milo Rogers <ROGERS at USC-ISIB>
Cc:        KLH at SRI-NIC, lloyd at EDN-UNIX, dedwards at USC-ISI, tcp-ip at SRI-NIC
Subject:   Re: Talking to TOPS-20
you don't have to convince ME that sending a window update on a zero window
is a good idea.  all you have to convince me of is that i can claim an
implementation is not legal if it doesn't send such an update.  quotes of
possible strategies and tenuous implications do not convince me.  is the
offical view that such an update must be sent?  if so, why was i not getting
a window update from a TAC?
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 1983 1822-PST
From:      POSTEL at USC-ISIF
To:        tcp-ip at NIC
Subject:   Zero Windows - Probes & Updates


There has been some discussion of the window flow control in TCP and the
proper actions to take when the window becomes zero and moves away from zero.

When the data sender is faced with a zero window it must probe the receiver
periodically at a low rate (e.g., once every two minutes) to see if the
window has opened (become positive).

When the data receiver that has advertized a zero window makes the window
positive it must provide that information to the data sender in an segment
transmitted to the other TCP.  If no other data is ready to be sent an
ACK+Window "update" segment must be sent.  Since such a segment does not carry
data it's reliable recption cannot be ensured by the TCP mechanisms.

However, it is expected that update segment will be the normal way of promptly
resuming the data flow when the window opens.  The low frequency probes of the
window by the data sender are the backup mechanism.  There has been some 
mention of using a much lower rate probe (e.g., once per second).  This is
counter productive.  The probe should be at a low rate, no more frequent than
once per 30 seconds, probably best at once per two minutes.

--jon.
-------
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1983 at 1557-PST
From:      dan at SRI-TSC
To:        unix-wizards at SRI-CSL, tcp-ip at NIC
Subject:   Looking for a VDH interface for UNIX
Is anybody out there running TCP/IP on UNIX, through a VDH interface?
I would appreicate hearing about it for any version of UNIX TCP/IP.
Thanks!

	-Dan Chernikoff (dan@sri-tsc)
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Monday, 14 Mar 1983 18:21-PST
From:      mike at rand-unix
To:        local-nets at MIT-MC, tcp-ip at SRI-NIC
Cc:        mike at rand-unix
Subject:   XNS and Network Research Corporation
We are considering using NRC (Network Research) to build a local
network for us as they are the only company we can find that
supports both RT11 and UNIX.  They use XNS which is Xerox's
new network protocol.  They claim that XNS is fast becoming
"the" network protocol for commercial users, far outstripping 
IP/TCP.  They also claimed hhat the Berkeley implementation of
IP/TCP doesnt work.  This is the second time I have heard this 
latter claim, the first time from 3COM.

So the questions are:

a.  Is XNS becoming the commercial standard?

b.  Does the Berkeley 4.?+1 implementation of IPTCP work?

c.  Has anyone had any experience with NRC?

Thanks very much,
Michael Wahrman
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 1983 0822-PST
From:      POSTEL at USC-ISIF
To:        mike at RAND-UNIX, local-nets at MIT-MC, tcp-ip at SRI-NIC
Cc:        POSTEL at USC-ISIF
Subject:   Re: XNS and Network Research Corporation
In response to the message sent  Monday, 14 Mar 1983 18:21-PST from mike@rand-unix



Mike:

There are a lot of sites running Berkeley Unix with IP/TCP.  It is not
always clear which sites are using the Berkeley verision of the IP/TCP
program or the BBN version of the IP/TCP program.  In any case the
situation is far different than portrayed by some salesman with his own
self interest in mind.

I am sure that people who have invested the time and effort in implementing
Xerox NS protocols would love it if they did become widely used, but liking
something and having it be true are two very different things.

I never heard of "Network Research (NRC)".  Who are the principals of the
company?

You can be sure that the ARPA and the DOD are using IP/TCP in the Internet.
It seems foolish to me to waste your time on implementing two sets of 
functionally equivalent protocols for the same machines.  If you think that
the machines in the local net won't need to talk to machines in the Internet
so they don't need compatible protocols - i think you are being very short
sighted.

--jon.
-------
-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 1983 0933-PST
From:      MILLS at USC-ISID
To:        mike at RAND-UNIX, local-nets at MIT-MC, tcp-ip at SRI-NIC
Cc:        MILLS at USC-ISID
Subject:   Re: XNS and Network Research Corporation
In response to the message sent  Monday, 14 Mar 1983 18:21-PST from mike@rand-unix

Mike,

Chris Kent would argue that 4.? does in fact work and so would I.
Fuzzballs emulate RT-11, support IP/TCP, TELNET, FTP and SMTP
and cause a lot of mischief, so I argue they work. 3-COM's implementation
as-is does not work. Toggle John Nagle at Ford Aerospace (jbnand he will tell you about Ford's mods to 3-COM that do work. And
so it goes.

Regards,
Dave
-------
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 1983 1116-EST
From:      Chris Ryland <CPR@MIT-XX>
To:        mike@RAND-UNIX, local-nets@MIT-MC, tcp-ip@SRI-NIC
Subject:   Re: XNS and Network Research Corporation
Mike:

Yes, it does appear that XNS is gaining the momentum needed to become
a true standard (vs. a paper standard).  I say this because there are a lot
of companies offering or about to offer XNS-based networks (Network Research,
ACC, 3Com, Bridge, are a few).

"Berkeley IP/TCP doesn't work" is the usual mindless slander.  4.2 IP/TCP
works well, though earlier DEBUGGING (i.e., pre-release) versions have had
problems.
-------
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Wednesday, 16 Mar 1983 10:57-PST
From:      guyton at rand-unix
To:        local-nets at MIT-MC, tcp-ip at SRI-NIC
Cc:        guyton at rand-unix
Subject:   XNS and NRC
The recent msg from Mike Wahrman has led several people
to believe that Rand is considering not using TCP/IP.

This is not the case.  Rand is currently running TCP/IP
and will continue to do so as long as we are on the
Arpanet Internet.  We are looking forward to a local
ethernet running TCP/IP in the very near future.

Mike is a consultant to Rand, and his query was in regard
to a seperate network being set up by his other employer.

-- Jim Guyton
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 1983 09:13:55-EST
From:      Christopher A Kent <cak@purdue>
To:        local-nets@MC, mike@rand-unix, tcp-ip@NIC
Subject:   Re: XNS and Network Research Corporation
Mike,

Berkeley's TCP works just fine. It's even been ported to split I/D 11s;
I believe that all the 11s on the Arpanet running V7 UNIX are using
that TCP.

It's true that the pre-releases had many problems, but I think most of
those have been resolved, at least within Berkeley (they may not have
made it to the outside world). Earlier versions also had functionality
that was a superset of the TCP standard (Out-Of-Band data signalling,
for example) but I believe that all those features will be removed
before final release.

XNS may well become a standard for Ethernet based networks; what
happens when you want to talk to someone else?

Cheers,
chris
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 83 12:13:03 EST (Sun)
From:      Mike Muuss (TCP-IP Digest) <tcp-ip@Brl-Bmd.ARPA>
To:        tcp-ip@Sri-Nic.ARPA, Large-List-Peple <LLP@Mit-Mc.ARPA>
Subject:   NIC list -vs- digest
Now that the NIC list <TCP-IP@SRI-NIC> is also being transmitted to
the TCP-IP@BRL list, I have an interesting policy question.

Should I assume that people who send messages to the NIC list know
that they are going to come out later in the Digest and publish
them, so that everybody on the Digest can see and participate in
this new "insiders" forum, or, should I individually enquire of every
author if I can publish their letter (administrative nightmare),
or what?

I certainly have no intention of publishing some of the short,
misunderstanding-based messages and replies that go to the NIC
list, but there is a great deal of information exchanged which
might be of value to others.

The same goes for the TENEX and TOPS-20 lists at the NIC, which also
now feed the digest.

For the time being, I will just hld messages from the NIC lists,
until some kind of consensus forms.
		Thanks,
		 -Mike

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 1983
From:      TCP-IP@Brl.ARPA
To:        TCP-IP@Brl.ARPA
Subject:   TCP-IP Digest, Vol 2 #2
TCP/IP Digest           Sunday, 20 March 1983      Volume 2 : Issue 2

Today's Topics:
               Administrivia:  Class "C" Transmission Host
                Administrivia:  NIC list -vs- the Digest
                           Security on TCP/IP?
               RFC 848 ("Little TCP Services") Misleading
                Looking for VDH driver for TCP/IP on UNIX
----------------------------------------------------------------------
                  TCP/IP Digest --- The InterNet Digest
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

Date:     20 Mar 83 12:28:32 EST (Sun)
From:     Mike Muuss (TCP-IP Digest)  <tcp-ip@BRL>
Subject:  Administrivia

This digest is intentionally a short one.  This will be the first digest
transmitted from a machine on a class "C" network, connected by gateway
to the InterNet.  As many hosts may not have up to date routing tables,
(or even host tables!), this will be an interesting test to see how far
along we really are.

Transmission is from host BRL-BMD, 192.5.21.1, via the
BRL-GATEWAY connecting 10.3.0.29 and 192.5.21.*

Mail which lingers in the queue for more than a few days I will note,
and manually forward through host BRL (10.0.0.29), so that everybody
should get a copy.  The famous maxim applies:  "If you don't see this
message, please let me know"!

		Cheers,
		 -Mike

------------------------------

Date:     20 Mar 83 12:13:03 EST (Sun)
From:     Mike Muuss (TCP-IP Digest)  <tcp-ip@BRL>
Subject:  NIC list -vs- digest

Now that the NIC list <TCP-IP@SRI-NIC> is also being transmitted to
the TCP-IP@BRL list, I have an interesting policy question.

Should I assume that people who send messages to the NIC list know
that they are going to come out later in the Digest and publish
them, so that everybody on the Digest can see and participate in
this new "insiders" forum, or, should I individually enquire of every
author if I can publish their letter (administrative nightmare),
or what?

For the time being, I will just hold messages from the NIC lists,
until some kind of consensus forms.
		Thanks,
		 -Mike

------------------------------

Date:      13 Feb 83 22:38:35 EST  (Sun)
From:      smb%mhb5b@brl-bmd
Full-Name: Steven M. Bellovin
Subject:   Security on TCP/IP

Mike:  has any work been done on security protocols for TCP/IP?  That
is, we're working on the first link of a Murray Hill Ethernet, which
will ultimately connect lots of machines up here.  Some of them are
mutually suspicious (we have sensitive data on our machines, for example),
and I'd like ways to authenticate requests.  Given that DOD is sponsoring
TCP/IP, I assume that *something* has been done, but I haven't seen any
papers, and I'd rather not re-invent the wheel.

		--Steve

------------------------------

Date:  17 March 1983 21:25 est
From:  Barry Margolin@Mit-Multics.ARPA
Subject:  RFC 848 misleading
To:  TCP-IP@Brl.ARPA

RFC 848, entitled "Who Provides the 'Little' TCP Services?", is a little
misleading.  There are a number of hosts listed as providing almost all
the services tested.  It seems that the lists were generated by
attempting to connect to the hosts, and noting whether the connection
was opened.  The software that is running in many of these hosts, which
all seem to be PDP-11's running RT-11, generally seems to open
connections on any port.  If it doesn't actually implement the service,
it then sends the ASCII string "HOSTNAME Unknown service port NN", where
HOSTNAME is replaced by its hostname (with the appropriate domain name)
and NN is the port.  There are some exceptions to this, in which cases
they return the string "HOSTNAME Not yet Postel, not yet"!
				Barry Margolin
				Margolin@MIT-Multics.ARPA

------------------------------

Date: 11 Mar 1983 at 1557-PST
Subject: Looking for a VDH interface for UNIX
From: dan at SRI-TSC

Is anybody out there running TCP/IP on UNIX, through a VDH interface?
I would appreicate hearing about it for any version of UNIX TCP/IP.
Thanks!

	-Dan Chernikoff (dan@sri-tsc)

------------------------------

END OF TCP-IP DIGEST
********************

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 1983 14:14:27 EST (Monday)
From:      Rob Gurwitz <gurwitz at BBN-UNIX>
To:        mike at rand-unix
Cc:        local-nets at MIT-MC, tcp-ip at SRI-NIC
Subject:   Re: XNS and Network Research Corporation
a. XNS is "a" commerical standard, but not "the" commercial standard.  Doubtless
other manufacturers and hangers on would try to sell their protocols as "the"
standard.

b. Both the BBN (4.1) TCP/IP and the Berkeley (4.1x, 4.2, 4.3) version which
decended from it appear to work (otherwise youwouldn't get this message).  The
BBN code is currently in use on over 90 machines at at least 40 sites.  The
Berkeley code exists so far in test versions only, but operates at some number
of sites and has been ported to the PDP-11 by SRI.

c. No.

Its interesting that both NRC and 3COM make such statements, viewing TCP/IP and
the VAX versions of implementations as "competitors".  Caveat emptor.

Rob Gurwitz

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      30 March 1983 13:09 est
From:      Ata.SysMaint at RADC-MULTICS
To:        Postel at USC-ISIF
Cc:        tcp-ip at SRI-NIC, Ata.SysMaint at RADC-MULTICS, JSLove at MIT-MULTICS
Subject:   Simultaneous opens
Jon,

	It is my understanding that the TCP spec supports the idea of
2 TCPs simultaneously opening a connection.  However, unless both sides
open the connection at exacltly the same time, it will fail.  Following
the spec, if a segment arrives to a port which does not exist, a RESET
is sent back.  A RESET, still following the spec, will  close the
connection and abort the attempted open.  Since the chances of 2 TCPs
ever being exact in their timing of opening the connections is slim,
then the notion or concept of a simultanous open as per spec is really
meaningless.  However, if a TCP bends the rules a little and retransmits
the SYN on a RESET until the timeout period expires, then the chances
for a connection to succeed are greatly enhanced.  I therefore, request
that a change be made to the spec to accomodate this situation, since
there are applications (NSW for example) which will make use of the
simultanous open feature of TCP, and which will fail if the TCPs follow
the spec the way it is now written.

		John Ata

END OF DOCUMENT