Date: Tue, 8 Jun 93 04:30:08 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 #148
To: tcp-group-digest
TCP-Group Digest Tue, 8 Jun 93 Volume 93 : Issue 148
Today's Topics:
Broken address
Compiling NOS
Linking with Janet
Network Unreachable Proposal (4 msgs)
Password security
Przyszlowsc INTERNETU
RFC 791, IP options (2 msgs)
wampes
Wampes Dk5sg-bbs .bbsrc file
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: Mon, 07 Jun 1993 20:35:53 PDT
From: "Jeffrey D. Angus" <jangus@skyld.tele.com>
Subject: Broken address
To: tcp-group@ucsd.edu
Recently while replying to Mike Bilow, I got this back from the host.
> From: bongo!netcomsv.netcom.com!ids.net!Postmaster
> Subject: Undeliverable Mail
> To: <netcomsv!bongo!skyld!skyld.tele.com!jangus>
> Comment: Bad address -- <ids.netMIKEBW!MIKEBW>
> Comment: %MAIL-E-USERSPEC, invalid user specification '!MIKEBW'
>
> Start of returned message
>
> From: "Jeffrey D. Angus" <jangus@skyld.tele.com>
> Message-Id: <2c13c9c2.skyld@skyld.tele.com>
> Organization: Grendel's Lair
> To: "Mike Bilow, <MIKEBW@ids.net>" <MIKEBW@ids.net>
The original message with various address lines was:
> From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
> Message-Id: <930527003925.2dca@ids.net>
> To: jangus@skyld.tele.com
>
> -- Mike Bilow, <mikebw@ids.net> (Internet)
> N1BEE @ WA1PHY.#EMA.MA.USA.NA (AX.25)
Does anyone out there have a "Reply-To:" address for Mike that works?
73 es GE from Jeff
--
J. Angus: jangus@skyld.tele.com -- "Als ik Kan", Gustav Stickley
US Mail: PO Box 4425 Carson, CA 90749-4425 1 (310) 324-6080
------------------------------
Date: Mon, 7 Jun 93 23:20:08 -0700
From: chuckb@babbage.ecs.csus.edu (Chuck Bland)
Subject: Compiling NOS
To: tcp-group@ucsd.edu
Well gang, as most of you probably already know, BCC 3.1
is the compiler to use.
The "Sage Advice" award goes to Mike C. (k3mc) for his
rule of thumb to use the same version the author uses.
AAAAAAAAAAAAAAAmen.
Thanks for your replies.
Now, any comments on my RAM disk question ?
Chuck
chuckb@babbage.ecs.csus.edu
------------------------------
Date: Mon Jun 7 13:18:12 1993
From: iiitac@pyr.swan.ac.uk
Subject: Linking with Janet
To: tcp-group@ucsd.edu
The first quick answer is to be careful.
Coming off the packet network onto JANET is not feasible. All that has
to happen is you connect from radio to JANET someone does a write request
at you (off JANET) and if they are not a licensed radio amateur you've probably
just broken the rules.
Going the other way is more viable (at least on-campus). It's still a thing
we are looking at doing here (once we get the Perq2 PSU fixed). All you need
is KA9Q and a password file so that you have to log into the campus/radio
link machine to go from one to the other.
The final stage is mail forwarding which is reasonably easy. Mail from radio
sites onto the internet to radio amateurs is fine, and mail the other way
can be checked by hand before sending.
The encryption problem you describe is not easily solved. A public key
encryption system would do it , but upset the RA.
Alan
------------------------------
Date: Mon, 7 Jun 1993 10:12:36 -0600
From: ke9yq@ke9yq.ampr.org (Bob Van Valzah, ke9yq)
Subject: Network Unreachable Proposal
To: tcp-group@ucsd.edu, gateways@mpg.phys.hawaii.edu
Wouldn't it be nice to get an ICMP network unreachable message back from a
router on net-44? I find it very frustrating when doing a traceroute (hop
check) to just see the echoes just stop at some point with no ICMP message
when I know it's not a failed link problem.
Here's a question/proposal for folks familiar with NOS iproute.c (or
whatever is the appropriate file). Is there any sort of existing routing
table entry I can create that'd cause a network unreachable to be sent
back? I could probably just create an infinite loop by sending packets
back to myself via loopback, but that'd be no fun.
What I'm thinking of would look something like this:
route add 44.a.b/24 encap host1 #\
route add 44.c.d/20 encap host2 #---All this exists already
route add 44.e/16 encap host3 #/
route add 44/8 unrch localhost # this is new
I can assert that I have routes to all reachable subnets of net-44 (as do
most gateways). If a packet made it down my route table to the "unrch"
pseudo interface, I'd like to return it wrapped in a network unreachable
message and returned to the sender.
This proposal probably violates all kinds of rules since it's not that
*all* of net-44 is unreachable (or does it?). It sounds to me like it'd be
literally just a few lines of code. So if it doesn't break too many rules
and isn't much harder than that, I'd love to see such a feature included in
some of the mainstream distributions of NOS.
Do commercial routers (e.g. cisco) have any mechanism for generating an
unreachable message when all known routes to subnets of a larger network
are exhausted? I've sent a few random probes into net-15 (MIT) and net-18
(HP) and gotten unreachables from MIT but not from HP. Maybe even the
non-existence of an HP network is a secret :-)
73, Bob, ke9yq
------------------------------
Date: Mon, 07 Jun 1993 08:46:38 -0700
From: Paul Traina <pst@cisco.com>
Subject: Network Unreachable Proposal
To: ke9yq@ke9yq.ampr.org (Bob Van Valzah, ke9yq)
Do commercial routers (e.g. cisco) have any mechanism for generating an
unreachable message when all known routes to subnets of a larger network
are exhausted?
Yes
I've sent a few random probes into net-15 (MIT) and net-18
(HP) and gotten unreachables from MIT but not from HP. Maybe even the
non-existence of an HP network is a secret :-)
ICMP unreachables can be disabled
73, Bob, ke9yq
------------------------------
Date: Mon, 07 Jun 1993 08:46:38 -0700
From: Paul Traina <pst@cisco.com>
Subject: Network Unreachable Proposal
To: ke9yq@ke9yq.ampr.org (Bob Van Valzah, ke9yq)
Do commercial routers (e.g. cisco) have any mechanism for generating an
unreachable message when all known routes to subnets of a larger network
are exhausted?
Yes
I've sent a few random probes into net-15 (MIT) and net-18
(HP) and gotten unreachables from MIT but not from HP. Maybe even the
non-existence of an HP network is a secret :-)
ICMP unreachables can be disabled
73, Bob, ke9yq
------------------------------
Date: Tue, 8 Jun 93 8:54:53 DST
From: Martin W Freiss <freiss.pad@sni.de>
Subject: Network Unreachable Proposal
To: ke9yq@ke9yq.ampr.org (Bob Van Valzah ke9yq)
Bob writes:
> Wouldn't it be nice to get an ICMP network unreachable message back from a
> router on net-44? I find it very frustrating when doing a traceroute (hop
> check) to just see the echoes just stop at some point with no ICMP message
> when I know it's not a failed link problem.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is exactly the problem - an ICMP network unreachable does not
really tell you what happens. Quoting RFC 1122 from memory: "Receiving
an ICMP network unreachable should be regarded as a hint, not as proof
that a network is unreachable".
Therefore, existing IP implementations tend to throw away the unreachables -
in real life, they are caused by transients more often than not.
(meaning that when you send unreachables for packets that you cannot route,
other people might ignore you :-)).
> Do commercial routers (e.g. cisco) have any mechanism for generating an
> unreachable message when all known routes to subnets of a larger network
> are exhausted?
Yes.
> I've sent a few random probes into net-15 (MIT) and net-18
> (HP) and gotten unreachables from MIT but not from HP. Maybe even the
> non-existence of an HP network is a secret :-)
No, but sending some ICMP messages can be completely disabled, and some ICMPs
often are routed with lower priority. When you send unreachables for
every packet that you can't route, you'll use up a _lot_ of the available
bandwidth just for ICMPs.
Just my .02 $ worth.
73, Martin
--
Martin Freiss | R&D computer center | freiss.pad@sni.de
Siemens Nixdorf Infosystems | Dept. MR STO SI 325 | NIC MF194
"This mind intentionally left blank"
------------------------------
Date: Mon, 7 Jun 93 12:05:53 PDT
From: djc@samisen.UVic.CA
Subject: Password security
To: tcp-group@ucsd.edu
Here's a note I sent to J.R.Jagger that sounds like it would be of
interest to some of the rest of the group. I believe that this code
essentially solves the problem of password security on a broadcast
medium like radio or ethernet. It does not solve the IP authentication
problem. I forgot to tell him that it can also be compiled with MD4,
which is another algorithm that is faster than MD5 and still quite secure,
though less so than MD5.
> From djc Fri Jun 04 13:01:14 1993
> Date: Fri, 4 Jun 93 13:01:14 PDT
> Reply-To: sol.uvic.ca!samisen!djc
> To: J.R.Jagger@sheffield-hallam.ac.uk
> Subject: Password security
>
> I wrote some code that does secure password security that you are welcome
> to. It's purpose was to secure radio logins to a Unix box and for that
> purpose did not require any mods to NOS. It is simple but slightly clunky
> to use in that mode but the mods to NOS to make it totally automatic
> would be trivial.
>
> It is based on the MD5 message digesting algorithm and works as follows:
>
> 1) choose a password, call it S0.
> 2) use MD5 to hash it securely getting S1.
> 3) repeat 2) until you have S100 and store it locally.
> 4) communicate S100 to the host you wish to log in to and store it there.
>
> Now to log in to the host you must present a string that produces S100
> when hashed by MD5. This is S99 - but knowing S100 does not help you
> find S99 because MD5 is a one-way hash. So it is secure from observers
> who saw S100.
>
> Here's how a login works:
> YOU: connect, ask for a login.
> HOST: asks for a password.
> YOU: start up a little program, type in S0, and the program will MD5 until
> it has the S100 stored previously. Then it has S99, whatever hashed
> to S100. The program stores this in the file and sends it to the host.
> HOST: hashes whatever it gets once and compares it with what is in its
> file. If it does not match you are an imposter and it kicks you out.
> If it does match it stores what you sent (S99) in its file and
> lets you in.
>
> When you log out you are all ready to start all over again with S98 instead
> of S99. You can continue this process until you get to S0; then you have
> to call up the sysadmin and get your account reset so you can start with
> a new S0.
>
> This sounds complex but it is really very simple to use: just type in
> your password and the programs on both ends take care of all the rest.
> The actual code I have extends the concept to allow S98,S97,or S96 to
> be used when it is expecting S99 - this allows for some screw-ups on either
> end, which are bound to occur. The string is nice and long, 12 chars or
> so, which makes brute-force impossible. The MD5 algorithm is very fast
> so 2 or 3 hundred iterations is no problem on any reasonable computer.
> I use it on a 12 MHz XT and it only takes a few seconds to calculate
> 200 MD5s even though the XT is a VERY slow machine.
>
> But best of all, nothing useful to an interloper is kept anywhere on
> either side! The one-way nature of MD5 makes it very difficult to
> calculate Sn-1 if you know Sn.
--
/\/\/\/\/\/
Doug Collinge, try: sol.uvic.ca!samisen!djc
or: samisen!djc@sol.uvic.ca
or: dcolling@ve7frg.ampr.org
VE7GNU PBBS: VE7GNU@VE7VBB.#ISLAND.BC.CAN.NOAM
------------------------------
Date: Mon, 7 Jun 1993 14:07:38 CET
From: JAN POLESZCZUK <POLAN%PLEARN.BITNET@plearn.edu.pl>
Subject: Przyszlowsc INTERNETU
To: Ryszard Korwin-Mikke <rmikke@MIMUW.EDU.PL>
OTRZYMALEM Z LISTY DYSKUSYJNEJ W USA KOMUNIKAT, KTORY Z PEWNOSCIA
ZAINTERESUJE CIUW-LISTOWCOW.
Most of you are probably aware of a plan to limit free use of
INTERNET to "scientists" transmitting huge files and to start
charging for e-mail. Apparently, this is the result of private
telecommunications interests putting pressure on the National
Science Foundation.
If this plan is realized, it will mean that the majority of the
approximately 15 million users of INTERNET will be cut off.
Sadly, this is occurring just when the potential of this network
was starting to be realized.
Something must be DONE. We can not let private interests deprive
us of access to INTERNET.
I suggest that all concerned users register their protest/concern
directly with Clinton and Gore via e-mail. Their e-mail address
have recently been posted and they are:
Clinton= PRESIDENT@WHITEHOUSE.GOV
Gore = VICE.PRESIDENT@WHITEHOUSE.GOV
In addition, I also suggest that we identify the office in the
NSF which is responsible for INTERNET and register electronic
protests with them.
Any help or suggestions would be appreciated, especially in
locating the e-mail address for the office in the NSF.
**********************************************************************
* Carl H.A. Dassbach BITNET: DASSBACH@MTUS5 *
* Dept. of Social Sciences INTERNET: DASSBACH@MTUS5.CTS.MTU.EDU *
* Michigan Technological Univ. PHONE: (906)487-2115 *
* Houghton, MI 49931 FAX: (906)487-2468 *
* U.S.A. *
**********************************************************************
------------------------------
Date: Mon, 7 Jun 93 15:43:47 PST
From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
Subject: RFC 791, IP options
To: J.R.Jagger@sheffield-hallam.ac.uk
1. I see a problem which occurs when packets are sent frequently enough
to have same time (at clock granularity). If consecutive numbers are
used to get different timestamps, it is easy to derive encoding method
having few packets only (I suppose 4-5 can be enough).
To avoid it, must use timestamp increments which are random numbers.
Or encode something different than just timestamp.
2. I just realized there is very simple way to make much more harder
stealing the one-shot passwords: use kind of checksum of packet data
for additional encoding of the timestamp, when hacker simply replaces
data and sends the packet, its password is invalid. A problem: method
of computing the checksum must be secret, e.g. it can be CRC which
polinom is known to valid user and the server only.
Eventually can use the CRC without timestamp, but with thing more
(since CRC polinom can be guessed after collecting sufficient amount
of packets): after computing the CRC add some randomly selected number
matching some criteria, receiver should compute difference between the
value sent in packet and CRC of data and check the criteria. In this
case the data must also contain some "global sequence number" (global
for all sessions) to avoid use of exact copy of a packet by a hacker.
This method without timestamp has also less chance to be forbidden
by Amateur Radio rules (I hope can put CRC of data in packet? :-).
------------------------------
Date: Mon, 7 Jun 93 18:59:59 PST
From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
Subject: RFC 791, IP options
To: J.R.Jagger@sheffield-hallam.ac.uk
> It might be easy to derive the coding method, but a hacker could
> not create any codes, since he does not know the DES key, and
> in cyclic mode every password is affected by the previous password.
I meant if you used just timestamp (with additional increment by 1 if
time was not changed between packets) and sent quickly 5-6 packets,
they would contain consecutive numbers encoded and probably the key
would be too easy to derive from encoded values (a hacker would be
able to detect the numbers are consecutive and derive key).
> I just put a header in the data that provides two things.
> 1. a time:stamp
> 2. a CRC check on the packet data.
Hope you put them as ONE NUMBER, and most of its bits depend on BOTH
timestamp and CRC? I know CRC polinom can be derived, even when very
long polinom is used - it requires only some patiency in collecting
and analysing data, need few thousands of packets of equal length
and method similar to Gauss elimination can be used...
> So a date:time stamp to the granularity of the of the system clock
> with the extra fine granularity part being based on the data contents
> of the packet sounds just about perfect.
Seems if you append 16 bit (or more) CRC to timestamp and make the
timestamps always different (ahead real clock when would be same as
previous) and encode the value, this will be enough.
Another way can be: use 32(or more)-bit number and add a random value
in range up to few thousands every time you send packet and encode
the value - using random numbers should protect against deriving key.
------------------------------
Date: Mon, 7 Jun 93 21:33:14 EDT
From: Antoon Milatz <antoonm@pa3bwe.fdc.iaf.nl>
Subject: wampes
To: tcp-group@ucsd.edu
Has anyone WAMPES running on a TEKTRONIX 6130 / UTek 3.0 ?
Regards, Antoon
--
-----------------------------------------------------------
Antoon Milatz | email : antoonm@pa3bwe.fdc.iaf.nl
de Bentlanden 2 | ----------- packet radio ------------
2731 HA Benthuizen | smtp : pa3bwe@pa0okc
The Netherlands | ax25 bbs : pa3bwe@pi8eae
------------------------------
Date: Mon, 7 Jun 93 6:07:10 MDT
From: Dieter Deyke <deyke@deyke2.fc.hp.com>
Subject: Wampes Dk5sg-bbs .bbsrc file
To: BTITMARS%ESOC.BITNET@vm.gmd.de, tcp-group@UCSD.EDU
> Does any users of wampes have a copy of the bbs config file .bbsrc that
> can be posted to this group for use as an example.. I have found that to get
> this file from existing German users of the Dk5sg bbs in the wampes pack is
> impossible Permission denyed when trying to read the file
> It lives in /tcp/bbs/.bbsrc as far as i know.
> Thanks. Barry. g8sau
Each user of the BBS may create their own, optional .bbsrc file in their
$HOME directory. This file may contain any valid BBS command. For
example, this is the file ~root/.bbsrc on DB0SAO:
PROMPT '***ROOT-bbs***> '
The .bbsrc file is read and executed by the BBS whenever the BBS is
started, and before any user input can be made.
Dieter
------------------------------
Date: Mon, 07 Jun 1993 16:52:14 +0100 (MET)
From: G8KBB%PI8VNW@pa2aga.UCSD.EDU
To: TCPAGA%pa2aga@pi8mac.UCSD.EDU
>From g8kbb@g8kbb.ampr.org Sun Jun 06 20:40:03 1993
Received: from gb7txm.ampr.org by gb7txm.ampr.org with SMTP
id AA20779 ; Sun, 06 Jun 93 20:40:01 GMT
Received: from g8kbb.ampr.org by gb7txm.ampr.org with SMTP
id AA20777 ; Sun, 06 Jun 93 20:38:06 GMT
Date: Sun, 06 Jun 93 19:34:54 GMT
Message-Id: <565@g8kbb.ampr.org>
From: g8kbb@g8kbb.ampr.org (Dave Roberts - Ipswich - JO02NA)
Reply-To: G8KBB@GB7MXM.#36.GBR.EU
To: tcpaga@pi8vnw.#zh2.ndl.eu
Subject:
Lines: 80
X-Mailer: PCelm 2.1
Hi I wonder if you can post this for me...
------
Hi,
I have seen one or two messages about a digi bug in TheNet X1H.
This was the subject of a patch a few months ago but it does
not seem to have propagated.
The bug causes ARP responses to have a garbage digipeat address list.
The patch fixes it.
TheNet X1J will be out soon - if anyone has any other problems please mail
me. Don't use Usenet and assume I get it - I get only a small fraction
of the mail feed.
73's
Dave G8KBB @ GB7MXM.#36.GBR.EU
========
Msg# 4890 Type: B Stat: $ Date: 06 Apr Time: 2157
To : THENET @ WWW
>From : G8KBB
Path : GB7MXM!
Subject : TheNet X-1H - patch info
>From : G8KBB @ GB7MXM.#36.GBR.EU
The documentation that accompanies TheNet X-1H describes a number
of patches that can be done to increase the MTU sizes for IP use.
In addition, here are two more patches. One is to cure the ARP
digipeat garbage bug, the other is to lower the minimum transport
retries to 1.
1. The Arp garbage bug.
Took ages to find this - in the event it was trivially silly.
The problem is that when an arp request is sent tothe node it
replies with a garbage filled digi list. The patch cures this.
In the file THENET2.X1H, patch the byte at offset 0x77cf from 0x2a to 0x21.
2. The transport retries.
In some networks, transport retries are not wanted, but the node does
not allow the retry counter to be set below 2. This patch allows it
to be set to 1.
In the file THENET2.X1H, patch the byte at offset 0x7933 from 0x02 to 0x01.
An easy way to patch the files is to use debug - but remember to add 0x100
to the addresses. Hence to perform the arp patch, type :
debug thenet2.x1h
e 78cf
21
w
q
Line 1 invokes debug on the file
Line 2 edits the byte at offset 77cf ( it is at address 78cf )
Line 3 changes it to 0x21 - note that it should read 0x2a !
Line 4 writes out the changed file
Line 5 exits from debug.
These patches only apply to thenet-x1h. If you are using x-1g you need
to upgrade first. In addition, if you are using x-1g you will also find
that ip frames sent out as UI frames will have garbage digi lists. This
was fixed in X-1H together with a couple of other bugs.
73's
Dave
G8KBB @ GB7MXM.#36.GBR.EU
<End of message 4890>
GB7MXM BBS >
bye
73s TroubleBrewing. Thank you for calling GB7MXM. Log off time 22:09
AX25 session 2 closed: Normal
PLEASE reply to the list, NOT to the From: address
because this mail is sent through a one-way gateway!
------------------------------
End of TCP-Group Digest V93 #148
******************************
******************************