Date: Wed, 23 Jun 93 04:30:17 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 #162
To: tcp-group-digest
TCP-Group Digest Wed, 23 Jun 93 Volume 93 : Issue 162
Today's Topics:
ampr hosts file
Help!!!
my slip link problems
NOS and Serial Ports
NOS POP3 and POP2 servers
Paclen > 256
password in IP timestamp option ?
Password security (5 msgs)
Print services in ka9q NOS
Slip Link ideas
TCP-Group Digest V93 #155
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: Wed, 23 Jun 1993 06:11:02 +000
From: karn@qualcomm.com (Phil Karn)
Subject: ampr hosts file
To: <n4yyh@wa2hee.ampr.org>, A.D.S.Benham@bnr.co.uk
At 10:23 PM 6/14/93 EDT, Ross Patterson wrote:
>that says you have to be part of net 44, although it is next to impossible
>to get a Class A (i.e. X.*.*.*) or Class B (X.Y.*.*) network address these
>days.
Nothing says you can't just use an address on whatever local network you
happen to be connected. Check out the entries under "ka9q.ampr.org" - you'll
see that most are not network 44.
>>I'm told it can't be done. I'm told "ampr.org" is flat. But I'm not told why.
>
>Gee, that's the easiest question you've asked so far. Brian Kantor, the
>registered "owner" of AMPR.ORG, wants it that way. Several folks have
>offered to set up authoritative servers for sub-domains, and each has been
>rebuffed. From what I hear, Brian feels responsible for the domain, and
>wants to keep it under his control so he can fix it if it gets broken. And
>as far as the Network Information Center (NIC) is concerned, he IS
>responsible, so I guess that makes it his decision.
You make it sound like Brian is being arbitrary - he's not. He's just right.
If you're having trouble keeping a domain database updated in a distributed
fashion, then fix that problem - don't kick it back to the users by forcing
them to add some physical identifer to your domain name, which they probably
won't be able to remember anyway. I've already moved "unix.ka9q.ampr.org"
from New Jersey to California, and it was really nice to not have to tell
everyone to change their addresses for me. All that changed was my IP
address, and the DNS keeps that invisible to the users, just as it should be.
Phil
------------------------------
Date: Tue, 22 Jun 93 17:41:26 EST
From: cheeky@cast.edu.jm (Andrew "6Y5KW" Wilkins)
Subject: Help!!!
To: tcp-group@ucsd.edu
Hi guys,
I would like some information. I would like to help out the
local College and Univerity with there internet links here in
6y5 land, the cost of the telephone bills is 2 much so i was
wondering if it is leagal for them to use our ax.25 network for
limited traffic with no gateways. I am also experimenting with
Tcp/IP and would use this medium for the transport of such traffic.
This would also act as a gateway for us Ham operators locally
to get onto the internet. Most of them dont even know a thing
about internet..
your reply would be appreciated....
Tnx de 6y5kw
------------------------------
Date: Tue, 22 Jun 93 06:00:35 CST
From: kf5mg@dfwgate.ampr.org
Subject: my slip link problems
To: tcp-Group@ucsd.edu
Dave,
I really recommend that you go to your local sidewalk sale and pick up
some used Ethernet cards. I picked up everything needed to hook up 4 PCs
for under $50. The cards were $5 each and the cables, bnc T connectors and
terminatin resistors were $7 each. For 4 machines, I needed 3 sets of cables
and Ts and 4 boards. So it was $41 total. That even gave me spare Ts and
terminating resistors.
I really thought that it would be difficult, but it wasn't. Yon need to
have an ethernet board and BNC T connector for each PC. Then you need a
piece of RG-58 A/U coax between each station. Each end station needs a
terminating resistor. You can make one or get them premade. All you need is
a 50 ohm resistor that connects the center pin of a BNC connector to the
outside. It was easier to use a RCA phone plug and a RCA to BNC adapter.
You also need to ground one of the terminating resistors to the PC's case.
I ran a wire out the back of the RCA connector for that. This may only be
needed for really long cable runs.
Anyway... that's the route to go. Quick and painless.
73's de Jack - kf5mg
AMPRnet - kf5mg@kf5mg.ampr.org - 44.28.0.14
AX25net - kf5mg@kf5mg.#dfw.tx.usa.na - work (817) 962-4409
Internet - kf5mg@vnet.ibm.com - home (817) 488-4386
-------------------------------------------------------------------
| "I am Homer, of Borg...prepare to be assim -- ooo, donuts." |
-------------------------------------------------------------------
------------------------------
Date: Tue, 22 Jun 93 13:23:50 -0400
From: Terry Stader - KA8SCP <p00489@psilink.com>
Subject: NOS and Serial Ports
To: Mr. Sampson <ssampson@sabea-oc.af.mil>
Steve... (and others) I have been running NET/Mac on my Mac and my PC using
38.4K on a slip link with NO problems what so ever. The version I am using is
the 386/486 optimized version by N1BEE. I like the front end of NOS over NET
on the Mac and therefore the PC is the machine that talks to the TNC.
I have configured it as a vc and it works like a charm.
Terry - KA8SCP
America Online Ham Radio Club Host
tstader@aol.com
p00489@psilink.com
------------------------------
Date: Wed, 23 Jun 1993 05:34:53 +000
From: karn@qualcomm.com (Phil Karn)
Subject: NOS POP3 and POP2 servers
To: <ashok@biochemistry.BIOC.CWRU.Edu>, erik@marge.phys.washington.edu
>>However, the bugfix follows Phil Karn's advice, "Accept liberally, send
>>conservatively".
To give credit where credit is due, I think Jon Postel originated that
phrase, not me. The original was something like "The Internet Implementer's
Creed: Be liberal in what you accept, conservative in what you send". I even
have it emblazoned on a IETF coffee mug.
Phil
------------------------------
Date: Tue, 22 Jun 1993 13:12:06 -0500 (CDT)
From: Mr. Sampson <ssampson@sabea-oc.af.mil>
Subject: Paclen > 256
To: TCP-Group@UCSD.Edu
Jon Jagger <J.R.Jagger@sheffield-hallam.ac.uk> says:
> 1. I've been looking into using a paclen value > 256.
> Some docs I read state that some versions of ax25 can't
> handle this...
Actually the AX.25 specs say 256 is the limit. If you use more than 256
bytes you are not using AX.25 anymore (sort of like the NTSB who says that
if an engine falls off a DC-10, that you are now riding an experimental
aircraft, not a DC-10). Of course the rules get more strict (unspecified
code). I don't know UK rules, but US rules say 256 bytes are the max in
connected mode (paclen only applies in connected mode).
You can use unconnected mode (UI) with any size packet, and is much more
preferable this way. You probably have a machine you want to connect to that
is only reachable via connected mode, but I haven't seen many nodes (Net/Rom or
Rose) that can pass 128 byte packets without choking up, so 256 bytes is
really too much, and more is worse.
---
Steve, N5OWK
"The bad thing about all the food we're dropping in Bosnia is that it has
a lot of saltpeter in it. After all, it was made for US troops" - UN
------------------------------
Date: Wed, 23 Jun 1993 06:02:19 +000
From: karn@qualcomm.com (Phil Karn)
Subject: password in IP timestamp option ?
To: J.R.Jagger@sheffield-hallam.ac.uk, tcp-group@ucsd.edu
At 05:02 PM 6/14/93 GMT, Jon Jagger wrote:
>Hi,
>I've been reading RFCs in my search to find a way to insert
>a password into an IP packet header. I think I may have found a way.
>Firstly I note that no NOS code I have yet looked at implements
>the timestamp ip header option, but all honour the ip.optlen
>setting.
Once again, I *strongly* urge anyone interested in experimenting with
IP-level security to do so by creating a pseudo-protocol that sits above
IP (and below TCP or UDP), rather than by adding IP header options. It's
much cleaner layering, easier to implement, less likely to get into
compatibility problems with other implementations, and you have as much
room as you need, too.
Phil
------------------------------
Date: Tue, 22 Jun 93 14:54:17 PST
From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
Subject: Password security
To: tcp-group@ucsd.edu
I have the MD5 algorithm .ASM code linkable to Turbo Pascal ready -
for TP only, it is in MD5P.ZIP, for TP and C (all memory models) in
MD5M.ZIP (both in guest directory on zfja-gate, 148.81.6.100). 73's
------------------------------
Date: Wed, 23 Jun 1993 00:28:30 +000
From: karn@qualcomm.com (Phil Karn)
Subject: Password security
To: jt@fuw.edu.pl, samisen!djc@sol.UVic.CA, tcp-group@ucsd.edu
At 05:32 PM 6/14/93 +0200, jt@fuw.edu.pl wrote:
>I have rewritten some of MD5 code (MD5Transform function) in assembly
>- speed increased over 3 times on every machine, now MD5Transform times
>are: < 8 ms on slow 4.77MHz XT, < 1 ms on 12MHz AT, < 700 us on 16MHz
>386, < 170 us on 16MHz 386 with use of 32-bit registers.
>(I will make the assembly code available when I finish it).
FYI, the version of md5.c in my current version of NOS (on ucsd.edu)
includes assembler code for the 386/486. It's configurable (you fall
back to the original C code for the 286) and it's about as tight as I
could possibly make it.
Phil
------------------------------
Date: Tue, 22 Jun 93 22:53:32 PDT
From: enge@almaden.ibm.com
Subject: Password security
To: TCP-GROUP@UCSD.EDU
I have joined the MD5 bandwagon and am going to use that in my
authentication scheme.
Roy, AA4RE
------------------------------
Date: Tue, 22 Jun 93 22:50:23 -0700
From: karn@qualcomm.com (Phil Karn)
Subject: Password security
To: MIKEBW@ids.net, 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.
If MD-5 is as its designer claims it to be, there is no practical way
to determine the required MD5 input that produces a given output,
other than by trying all possible inputs. Knowing that the input is a
fixed 128-bit block doesn't help much, since 2^128 is still a *very*
large number, and on average you'd have to try half of them (2^127).
> 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.
I don't think this is a problem. The stated properties of a strong
message hash like MD-5 are: 1) it is computationally infeasable to
find two messages that hash to the same value, and 2) it is
computationally infeasable to find a message that hashes to some
particular value.
BTW, property #1 is why MD-5 produces such a large hash value (128
bits); "birthday attacks" could be used to find two messages that hash
to the same value even though a 64-bit hash value would be sufficient
for property #2.
Once again, I implemented this exact scheme several years ago at
Bellcore, only I used MD4 instead of MD5, and each iteration folds the
MD-4 output down to only 64 bits to keep the key size manageable.
Bellcore has since trademarked it as "S/KEY" and is using it on
several of their machines as an alternative to the overpriced and
inflexible (literally!) SecureID card. S/KEY has a few user-friendly
features, such as the option of typing in your one-time password as
six 3- or 4-letter English words from a built-in dictionary instead of
as 16 hexadecimal digits.
Phil
------------------------------
Date: Wed, 23 Jun 93 11:40:07 PST
From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
Subject: Password security
To: karn@qualcomm.com (Phil Karn)
> Message-Id: <9306230026.AA21459@qualcomm.com>
> Date: Wed, 23 Jun 1993 00:28:30 +000
> FYI, the version of md5.c in my current version of NOS (on ucsd.edu)
> includes assembler code for the 386/486. It's configurable (you fall
> back to the original C code for the 286) and it's about as tight as I
> could possibly make it.
I tried the code right now and found some optimizations can be made.
Wrote them and tried to compile - first your original source code:
1. Without specifying -DCPU386 I was unable to compile it!!!
Tried: TC 1.5, TC 2.0, TCPP 1.01, BC 3.0, MS C 6.0
Errors: macro expansion too long in every, GP fault in BC 3.0
2. Specifying -DCPU386 and using BC 3.0 or TCPP 1.01 (other compilers
didn't accept it), I compiled it and found the digest values doesn't
match test suite from RFC 1321. And it is compiler-dependent!!!
I tried to compile code with my modifications - seems result are as
specified in RFC 1321, using TC 2.0, TCPP 1.01, BC 3.0 to compile it
(for TC 1.5 I got same results when I copied TASM.EXE to MASM.EXE -
it attempts to use MASM and .ASM code is not MASM-compatible).
After some attempts to isolate the change which caused code to become
correct, I found your assembly code always accesses the 64-byte data
as far, regardless what memory model is used. Probably the compilers
I used have default small-data memory model (small or medium).
The version MD5.C I tried was revision 1.5 (from RCSDSRC.ZIP).
I put diffs in file MD5DIFF.ZIP and RCS file in MD5RCS.ZIP on
zfja-gate (148.81.6.100) in guest login directory.
A question: is the 'tight' intended to mean 'small' ? The MD5 code
is optimized for speed rather than for size, suppose can save many
kilobytes of code size even in pure C. Try make it smaller ?
73's, Jerzy
------------------------------
Date: Tue, 22 Jun 1993 09:58:52 -0600 (CST)
From: "Erik Olson" <erik@marge.phys.washington.edu>
Subject: Print services in ka9q NOS
To: TCP-Group@UCSD.Edu
> I work with PA0GRI's NOS version (2.0m) and I wish to use the
> print services built in source code. Naturally I compiled the executable
> with the client and server LPD and I think all is right .
> But I do not know how to operate with LPD.
> I can imagine the I have to attach the asyncronous com port with "raw" mode,
> but can I use the parallel port ? if yes , How?
To use the parallel port, you just need to specify it in the /etc/printcap
entry. I beleive it's a matter of including the specification "lp=LPT1".
> And then how can initialize the print server lpd apart to give nos the
> command "start lpd"?
> The PA0GRI documentation is lack about that , so I wonder if someone has
> experience on it.
The original code is available, with documentation, from the ftp site
tacky.cs.olemiss.edu. I might also take the moment to plug the NEW RELEASE,
which I've been told is due out any day now (says Dave, the author)...
Having ironed out a few of the bugs in it, I'll advertise: it doesn't tie
up NOS while printing anymore, the tabs work right, it knows how to recover
when a job is removed, etc etc, and it's now based on ka9q 9305xx!!
- Erik
---
Erik Olson (in lab) erik@marge.phys.washington.edu
University of Washington olson@phys.washington.edu
Cosmic Ray Lab, Phys. 405
------------------------------
Date: Tue, 22 Jun 93 07:28:53 MDT
From: "Karl Larsen" <klarsen@centaur.arl.army.mil>
Subject: Slip Link ideas
To: tcp-group@ucsd.edu
I am using a pair of Twincomm V.32bis modums to connect my 2
jnos 1.08b systems. The attach slip was simple but getting the
modum initallised properly was not. You must have &C1 &D2 for a
start and E1 so the modem sends english to your computer and X4 so
it sends the long set.
I have clocked the link at 26,000 bit/second on plain text.
The v.42 hardware archive seems to work well. The computers have
plain com port cards. One is a combination com, printer, IDE hard
drives and floppy controller that cost $14.95 from a mail order
place in CA. Nothing special...I also use a program that allows
transferring data between computers at 115,000 bit/second and it
works fine too.
The thing that slows down telephone slip connections is
almost always the modum, or it's setup. There ARE good and bad
Modems. I am a node of the Fido Net and we have experts on modums.
I refuse to include my setup because it works for my modem, but
almost for sure it won't work on yours.
73, de karl
_________________________________________
| Internet klarsen@centaur.arl.army.mil |
| Fido 1:381/401 |
| k5di@k5di.nm.usa.na |
| Ham IP 44.30.2.5 |
| (505) 678-3145 weekdays 524-3303 home |
|________________________________________|
------------------------------
Date: Wed, 23 Jun 1993 06:59:11 +000
From: karn@qualcomm.com (Phil Karn)
Subject: TCP-Group Digest V93 #155
To: "Brian Ellsworth, Otis Service Center; 203-286-1606" <ELLSWORTH%BRAVO@utrcgw.utc.com>,
At 09:57 AM 6/16/93, Brian Ellsworth, Otis Service Center; 203-286-1606 wrote:
>Gee, i thought this was something we 'NOS users' (as opposed to
>developers, i guess) just had to live with ! I've been running a
>minimized version of PA0GRI's 2.0m for months, just using the asy
>driver to a 9600 baud TNC and it ROUTINELY gets crashed by over
>zealous pingers testing the 9600 baud repeater system. Generally,
>it appears that NOS sucks up all the available memory, then dies.
>Seems like there is more than the pktdrvr at fault here.
Well, yeah. I confess that NOS is not very graceful when it runs out of
memory. But there are some things you can do to reduce the probability of
that happening.
Recent versions of my base code (within the last year or so) have a
"random quench" feature. If you set the "qlimit" parameter on an interface,
you enable this feature. Whenever there are already "qlimit" packets on
an output queue and another one is queued, the system will pick a packet
already on the queue at random and send the originator an ICMP source
quench message. The original packet is left on the queue. The idea is to
slow down the senders who are congesting your queues without actually
dropping their packets.
Of course, this assumes that the sender obeys ICMP source quenches. This
is true for my own TCP, but ping and UDP do not. I agree that it shouldn't
be possible to crash NOS no matter what you type, but if the problem appears
only when generating artificial traffic with ping, then the old joke comes
to mind:
Patient: "It hurts when I do this!"
Doctor: "Well, don't do that then!"
--Phil
------------------------------
End of TCP-Group Digest V93 #162
******************************
******************************