Date: Sat, 12 Jun 93 04:30:07 PDT
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #151
To: tcp-group-digest
TCP-Group Digest Sat, 12 Jun 93 Volume 93 : Issue 151
Today's Topics:
ampr hosts file UCSD.EDU
help
Network Unreachable Proposal (4 msgs)
NOS gotchas
NOS POP3 and POP2 servers
Password security
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Fri, 11 Jun 93 23:43:09 CET
From: BARRY TITMARSH <BTITMARS%ESOC.BITNET@vm.gmd.de>
Subject: ampr hosts file UCSD.EDU
To: TCP-GROUP <TCP-GROUP@ucsd.edu>,
Hi just looked again at the amprhosts file on ucsd.edu, last look 6 months ago,
seems that its vastly out of date.. since im interested in Uk and German
IP's, I have a vested interest, When and how often do the IP coordinators
mail copies of the IP hosts of their domain to the World domain list
namely UCSD.EDU, I think Brian at that address ?
The German IP hosts is about 6 months out of date.. the UK IP hosts is
Years behind !! My own IP is not even in the list and i have had this ip
number for 2.5 years now.
Come On Lads!! can we keep the amprhosts up to date with WW coord!
Can one trust it?? If your on a Internet worm hole and DNS dont have the Info
Then WHAT,? hmmmm
Thanks. Barry.
------------------------------
Date: Fri, 11 Jun 1993 15:14:10 EDT
From: blusseau@UNIV-TOURS.FR
Subject: help
To: Tcp-Group@ucsd.edu
help
------------------------------
Date: Fri, 11 Jun 1993 11:51:49 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: Network Unreachable Proposal
To: rhorer@medics.jsc.nasa.gov, tcp-group@ucsd.edu
In the case of a host with a defined route that has become unreachable,
there really isn't any way to know that within the present scheme of
things. If we used a working dynamic routing protocol, then we could
tell the difference, but it would be of limited value.
Try pinging an down host on the commercial Internet. You don't get back
ICMP messages (except possibly some indirect indication like Source Quench).
You get back nothing at all.
-- Mike Bilow, <mikebw@ids.net> (Internet)
N1BEE @ WA1PHY.#EMA.MA.USA.NA (AX.25)
------------------------------
Date: Fri, 11 Jun 1993 12:09:30 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: Network Unreachable Proposal
To: ke9yq@ke9yq.ampr.org, tcp-group@ucsd.edu
You raise several different issues.
First, you are obviously right in that default routes may actually be far
more inclusive than they really need to be; this is why they are called
"default" routes. However, every IP frame must eventually reach a host
that knows how to route it along a non-default route, or that knows the
frame cannot be routed. It is this router which should orginate the
ICMP Host Unreachable message if necessary. If this situation is not
the case, then several routers on the network must have default routes
that are reflective, such that an IP frame for which there is no route
would actually be looped endlessly among the routers until the IP TTL
is extinguished.
My Newport router example was an extremely limited subset. In fact, we
try to avoid having default routes on routers here. Right now, we do
have a New England-wide policy of sending 44.0.0.0/8 frames toward the
Tolland, CT switch so that we can reach NY and NJ. This depends upon
the NY and NJ switches not doing the reverse to us, or loops would
result. When the MIT gateway becomes available for general use, we will
have to make some changes, and we know that.
Second, we have legal concerns about allowing IP connectivity between
Amprnet and Internet hosts. There is an active working group trying to
hash this out in New England. There is general agreement that allowing
AXIP wormholes for Amprnet LAN-to-Amprnet LAN connectivity is clearly
legal, and that a wide-open gateway is illegal. There is a gray area
in the middle of some scope, encompassing preapproved or robotic actions
such as domain name service, and issues of allowing Amprnet hosts to
initiate activity on the Internet but not the reverse. We almost
certainly are not going to define a default route for the Internet into
the MIT gateway and let it be.
-- Mike Bilow, <mikebw@ids.net> (Internet)
N1BEE @ WA1PHY.#EMA.MA.USA.NA (AX.25)
------------------------------
Date: Fri, 11 Jun 1993 16:32:07 -0400
From: "Louis A. Mamakos" <louie@NI.umd.edu>
Subject: Network Unreachable Proposal
To: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>), tcp-group@ucsd.edu
> Try pinging an down host on the commercial Internet. You don't get back
> ICMP messages (except possibly some indirect indication like Source Quench).
> You get back nothing at all.
This isn't any more or less correct than returning a host destination
unreachable message. The reason that you don't get anything back is
because the router's communications-subnet (the ethernet) doesn't
provide an advisory about down hosts. If you were on the old ARPANET,
for instance, the PSNs would return a link-level "host dead" which
could be used to generate an ICMP advisory.
Personally, I'd rather get a host unreachable ICMP message, but most
folk's ARP code don't bother.
louie
wa3ymh
------------------------------
Date: Sat, 12 Jun 1993 3:41:59 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow)
Subject: Network Unreachable Proposal
To: louie@NI.umd.edu, tcp-group@ucsd.edu
I think that there has to be a rule of practicality applied here. On an
Ethernet, ARP is going to be nearly perfectly reliable. If you can't get
a response, the target is likely not on-line. On Amprnet, with its high
rate of lost frames, failure to get a respond with ARP usually tells you
more about the state of the channel than it does about whether the target
is going to be reachable in 10 seconds. I don't know what response would
be appropriate when ARP goes unanswered, but I would not use ICMP Host
Unreachable for that purpose.
-- Mike Bilow, <mikebw@ids.net> (Internet)
N1BEE @ WA1PHY.#EMA.MA.USA.NA (AX.25)
------------------------------
Date: 11 Jun 93 13:46:55 GMT
From: Jon Jagger <J.R.Jagger@sheffield-hallam.ac.uk>
Subject: NOS gotchas
To: tcp-group@ucsd.edu
Hi,
I'm planning to write a small security module as an internal-add on to
DOS-NOS. I'd appreciate three bits of advice.
1. A stable release version with source code.
I have jnos 1.08d but I rather use something less beta
so I debug my new errors, and not old ones already present.
2. Since DOS-NOS has its own kernel which shedules processes
are there any re-entrancy gotchas I might look out for.
I'm thinking in particular of ANSI-C functions in Borland C
that are no go areas, (eg I/O and hidden static variables)
and care with global vars.
3. Debugging NOS itself. Since there are timers attached to various
packets, how do you avoid the obvious problem of everything
timing out when you have to single step ?
Also is debugging itself a problem because of NOS's scheduler?
All replies gratefully received.
Thanks
JJ
:: Jon Jagger , Sheffield Hallam University, S1 1WB, UK
:: Work J.R.Jagger@shu.ac.uk Home 2E1BSD (44.131.2.111)
:: Tel 0742 533802/432889 (work/home) Fax 0743 533840
:: Newspaper ad: Men wanted for expanding contracting company!
------------------------------
Date: Sat, 12 Jun 1993 01:28:26 -0400
From: ashok@biochemistry.BIOC.CWRU.Edu (Ashok Aiyar)
Subject: NOS POP3 and POP2 servers
To: tcp-group@ucsd.edu
I have recently (today) come across a couple POP3 clients that seem to use
lower case commands (eg. "user" instead of "USER" etc.), and therefore not
work with the Erik Olson's POP3 server for NOS.
I put a small hack that accepts UPPER, lower and MiXed case commands, by
converting them all to UPPER case.
I am putting it below for all those interested. The identical modifications
can be added to the POP2 server as well....
--
static void
popserv(s,unused,p)
int s;
void *unused;
void *p;
{
struct pop_scb *scb;
char *cp; /* <== for lower & MiXeD case commands - Ashok */
sockowner(s,Curproc); /* We own it now */
log(s,"open POP3");
--
--
rip(scb->buf);
if (strlen(scb->buf) == 0) /* Ignore blank cmd lines */
goto loop;
/* Convert lower, and mixed case commands to UPPER case - Ashok */
for(cp = scb->buf;*cp != ' ' && *cp != '\0';cp++)
*cp = toupper(*cp);
pop_sm(scb);
if (scb->state == DONE)
goto quit;
--
Later,
Ashok
--
Ashok Aiyar Mail: ashok@biochemistry.cwru.edu
Department of Biochemistry Tel: (216) 368-3300
CWRU School of Medicine, Cleveland, Ohio Fax: (216) 368-4544
------------------------------
Date: Fri, 11 Jun 1993 12:38:46 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: Password security
To: samisen!djc@sol.UVic.CA, tcp-group@ucsd.edu
Your recursive password scheme is very interesting, but I think it has
a potential vulnerability. All passwords S(i) where i > 0 are known to
be a result of running MD5 on S(i-1). This places some severe constraints
on the search space when trying to deduce S(i-1) from S(i), the kind of
attack which MD5 is normally intended to defend against. For example,
the simple fact that MD5 outputs a 128-bit results, such that all S(i)
where i > 0 are known to be exactly 128 bits, makes an attack easier by
orders of magnitude. Still worse, it may turn out that MD5 under some
special conditions (such as 128-bit inputs) does not exhaust its range
space, such that a slightly modified brute force attach would be feasible
in a reasonable amount of time. The unspoken assumption underlying MD5
is that it is a "message digest" of some sufficiently long string of bits.
If MD5 is used to process very short messages, it may not turn out to be
secure at all.
-- Mike Bilow, <mikebw@ids.net> (Internet)
N1BEE @ WA1PHY.#EMA.MA.USA.NA (AX.25)
------------------------------
End of TCP-Group Digest V93 #151
******************************
******************************