Date: Sat, 5 Jun 93 04:30:09 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 #145
To: tcp-group-digest
TCP-Group Digest Sat, 5 Jun 93 Volume 93 : Issue 145
Today's Topics:
Amateur Wire Operators
Compiling NOS
Hints for Getting & Compiling NOS base code
rcpip as TSRs
RFC 791, IP options (2 msgs)
tcpip as TSRs
Windows NT + TCP/IP Packet
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, 4 Jun 1993 13:47:47 -0500 (CDT)
From: S. R. Sampson <ssampson@sabea-oc.af.mil>
Subject: Amateur Wire Operators
To: TCP-Group@UCSD.Edu
Jon Jagger <J.R.Jagger@sheffield-hallam.ac.uk> writes:
> I am planning to set up a gateway here at work....
> My problem is that JANET conditions of use do not allow radio amateurs
> to use JANET get to the Internet...
> However if a member of staff is also a radio amateur...
> Right, my problem is secure access. Ordinary passwords are useless...
The simple answer to your question is to use a G3RUH modem using different
taps then 6 and 13 on the scrambler/unscrambler. Or how about adding a tone
decoder to sync a new pseudo-random number into a 17 bit register each packet.
That way no one can monitor, and other Hams won't use your private frequency.
The answer of course is not acceptable.
This is a whole lot of missplaced energy. Go out and buy these people a
modem and tell them the phone number to dial. Then they don't have to
worry about using the Ham bands for private use. Direct your energy into
making a service to all Hams (information, files, etc) rather than a secure
internet port for a selected few with no benefit to the community. I don't
see how this will serve the hobby.
I see the wire transport usage as a failure of Packet Radio. RF is too
hard, so let's use wire... Would that make them Amateur Wire Operators :-)
---
Steve, N5OWK
------------------------------
Date: Sat, 5 Jun 1993 18:55:30 +1000 (EST)
From: Adam Robertson - Network Officer DIT <aroberts@csunb.mit.csu.edu.au>
Subject: Compiling NOS
To: tcp-group@ucsd.edu
Hi, I have access to Borland C++ ver 3.0 and have ftp'd a copy of the
source for nos.(wg7j)
I have never used C before (Although I have done some programming in other
areas) and would like to know how to make exe files from the source.
I know you run the "MAKE" program and that will do all the work because of
the MAKEFILE, but what modifications do i do to the make file for the exe
file to be used on different machines, and how to inclusd and exclude
various parts of the code for "custom compiles" ie, for the gateway, use
as a bbs, and also end users etc.
Any help would be great.
de vk2xra
Regards ---------------------------------------------------------------------
| Adam Robertson - Network Officer - Div. of Information Technology |
| Charles Sturt University - Mitchell Campus |
| Location - Bldg S1, Panorama Drive, Bathurst, NSW. AUST. 2795 |
| Charles Sturt University - Mitchell |
---------------------------------------------------------------------
| E-mail : aroberts@csu.edu.au Phone : +61 63 332-782 |
| AMPRnet: vk2xra@gw.vk2xra.ampr.org Fax : +61 63 332-181 |
---------------------------------------------------------------------
------------------------------
Date: Fri, 4 Jun 93 14:13:45 +0200
From: jt@fuw.edu.pl
Subject: Hints for Getting & Compiling NOS base code
To: tcp-group@ucsd.edu
Notes on RCS problems:
"-x%v" option for rcs commands causes RCS files to have names with the
"%v" appended. Using "-xs1/s2" causes both s1 and s2 to be recognized as
valid suffixes for RCS file names; if any of them is empty, directory
"RCS" (uppercased) is tried (e.g. "-x%v/" causes rcs commands first try
name "filename.ext%v", when it fails they try name "RCS/filename.ext",
finally they try "filename.ext" as RCS file name, on command args both
file names "filename.ext%v" and "RCS/filename.ext" are recognized as RCS
file names rather than work file names. Note the "RCS" must be written
uppercased or it will not be recognized by RCS commands.
The "for %a in (RCS\*.*) do co %a" is OK unless used in batch file, in
this case need double these %-s: "for %%a in (RCS\*.*) do co %%a".
Place for executables from rcs56b.zip: it must be specified in PATH
environment variable and MUST MAKE SURE no other directory containing
program of same name is in the PATH before the directory. Many RCS
programs use GNU DIFF (specifying name DIFF and searching directories
specified by PATH for it), they will not work if they find other, non-
-compatible DIFF (they specify args: -an file1 file2). However, if use
of RCS is limited to "co" only, this is not important.
Other hints:
Before UNZIPping rcsdsrc.zip: use program like SpeedDisk (from Norton
Utilities package) to make free space on your disk continuous, then
load a disk caching program (like SMARTDRV). Also, a good idea is to
create large number of empty files in directory, erase them, then
UNZIP - this causes directory to be contiguous. RCS directory requires
number of files in rcsdsrc.zip + probably 1, working directory about
2 times more. Without both (disk caching and contiguous directory) all
goes extremely sloooooooowly (DOS without disk cache cannot handle
quickly directories > 1 cluster, especially when non-contiguous).
Because "co" is to be invoked hundreds times, put it on RAM drive or
use disk cache large enough. Will increase speed significantly, too.
After extracting sources from RCS you can erase RCS files to reduce
amount of disk space needed (unless you have several megabytes free).
Instead "make" type "make >>make.log", whis will save all compilation
warnings on file and you will be able to look at them later if need.
You can create work directory and put CONFIG.H and MAKEFILE in it,
making also changes necessary to customize them to your needs, put
RCS programs in proper place, create 2 files shown below:
MKDUMFIL.C:
#include <stdio.h>
char fnb[4]="xyz";
main(ac,av)
int ac; char **av;
{ int i,n=0;
sscanf(av[1],"%d",&n);
for(i=0; i<n; i++) {
sprintf(fnb,"%03d",i);
fclose(fopen(fnb,"wb"));
}
}
MAKENOS.BAT:
bcc mkdumfil.c
c:\util\norton\sd
; Norton's SD.EXE (SpeedDisk)
c:\windows\smartdrv
; MicroSoft's SMARTDRV.EXE, from MS-WINDOWS package
; can also use SMARTDRV.SYS, distributed with DOS >= 4.0
mkdir RCS
cd RCS
..\mkdumfil 270
del ???.
pkunzip \rcsdsrc
cd ..
mkdumfil 500
del ???.
for %%i in (RCS\*.*) do co %%i
echo y | del RCS
make > make.log
type MAKENOS, wait until SpeedDisk ends (unfortunately, it needs some
manual navigating; select making free space continuous, it is quick),
then go out for coffee or lunch... 73's, JT
------------------------------
Date: Fri, 4 Jun 93 06:45:18 -0700
From: "Dana H. Myers" <dana@fafnir.la.locus.com>
Subject: rcpip as TSRs
To: tcp-group@ucsd.edu
Milton Miller (KB5TKF, miltonm@austin.ibm.com) wrote:
>
> No work that I am aware of to make TSR's, for a couple of reasons, including
> issues of library function reuse (you end up with each tsr having its own
> malloc and printf, etc).
>
Library reuses shouldn't be a problem. One of the modules making up
a TSR-NOS would provide necessary library services. malloc() and printf(),
etc., in the other modules would need to be written such that they invoke
the library services module. This is similar in principle to the
implementation of shared libraries.
------------------------------
Date: 4 Jun 93 10:43:37 GMT
From: Jon Jagger <J.R.Jagger@sheffield-hallam.ac.uk>
Subject: RFC 791, IP options
To: tcp-group@ucsd.edu
Hi there,
first thanks to all who replied to my query on whether
a IP address such as 2e1bsd.ampr.org was 'right and proper'.
The answer is that it is. RFC 1123, section 2.1
This is good because UK Radio Amateur Novice License holders
get a call sign which start with a digit, and some regional
IP address co-ordinators are apprarantly not giving Novices
IP addresses on the grounds that their callsign starts with a
digit. I shall pass this on.
Anyway on to todays question :)
I am planning to set up a gateway here at work. One port into
our Ethernet (and hence into JANET and then Internet), one port
to a TNC+Transeiver+ANT. I already have a member of staff with
a GB7 callsign and a NOV willing to administer it, and he assures
me that the DTI have okayed it.
My problem is that JANET conditions of use do not allow radio amateurs
to use JANET get to the Internet. It seems some IP addresses are
more equal than others.
However if a member of staff is also a radio amateur with a 44.131.X.X
callsign, then they will have a work IP address that will allow
them to use JANET.
Still with me? :)
Right, my problem is secure access. Ordinary passwords are useless,
since anyone can eavesdrop on them.
So my first question is
Has anyone written any add-on code to NOS that will implmement
secure rlogin type access? (apart from ka9q's code on ucsd which
I know about)
If not I have a scheme that may work.
Each member of staff has a tinkered version of NOS at home, that, on
start up asks them for their DES key. Every packet sent to the gateway
contains the current date:time stamp DES encrypted.
The gateway has a database of (IP address,Deskey) tuplets, and when
a packet comes in that is to go *through* the gateway, it decrypts
the date-time stamp using the des key of the original sender.
A packet get through the gateway if
a) It decrypts to a valid date:time stamp.
AND
b) that date:time stamp is strictly LATER than the previous
packets date stamp (received from that IP address).
So question number 2....
Can I put the ENCRYPTED date:time stamp into the option field
of an IP packet? There's plenty of space 40 chars max, and
I think 16 would be fine, (multiples of 8 are best for the
DES code). I know that I can technically, but I don't want to
break any IP specs.
If I can't use an option then I'll just have
to prepend it to the packet data. No difference in packet
size really, it just looks like it would be slightly more messy
that way.
This DES setup would mean that every packet has a 'one-shot' password.
(You must also ensure that the senders system clock has sufficiently
fine granularity, so that no two date:time stamps are the same. This
is easy to ensure via software).
As I see it the only problem with this is you are at the
mercy of a digipeating station, if you can't reach the gateway
in one hop, since that station can collect your passwords,
not digipeat, and then pretend to be you. Tricky I know, but never
underestimate a radio amateur.
So question number 3...
Can anyone see a secure way around this hop problem?
(Other than using source specified routing)
Lastly I am just working my way through the NOS source code,
so see where I can insert the necsessary DES filters.
I'd like to only affect IP packets, so putting it
inside ip_send(), and ip_recv() seems the best place, yes ????
That way it won't affect non TCP/IP packets over ax.25.
Thanks for reading this far.
JJ
:: Jon Jagger J.R.Jagger@shu.ac.uk
:: Sheffield Hallam University, Pond Street, SHEFFIELD S1 1WB
:: Tel 0742 533802/432889 (work/home) Fax 0743 533840
:: Newspaper ad: Men wanted for expanding contracting company!
------------------------------
Date: Fri, 4 Jun 93 17:33:14 +0200
From: jt@fuw.edu.pl
Subject: RFC 791, IP options
To: tcp-group@ucsd.edu
1. Full security isn't possible when data trasmitted is available to
everyone. Most secure system has "plain" passwords stored on server
and uses double encryption: first using time-dependent key (sent by
server when password verification is requested), second irreversible
- server must do same with the password it has and compare results;
disadvantages: "plain" passwords are on server machine, cannot change
password from remote station or even use network to send information
specifying new password because it would break security, to change
password user must physically go to the server and do it manually.
(of course, the "plain" password can be even irreversibly encripted,
but in fact it will still be "plain", can use it without decription).
2. Must use some commonly supported option for the encoded information
or intermediate station can reject packet containing unsupported one.
3. Sending encrypted information via Amateur Radio is inhibited by law
or Amateur Radio rules in many countries, or even entire world.
Unless a log is kept for some time (many months) to allow verifying
what was sent. This was a problem when tried to compress information.
4. What is result if some hacker sends a packet which contains encoded
timestamp for many days ahead? Seems valid user will have no access.
5. Packets may arrive destination (or the internet/janet gateway) in
order different from sent - the idea you presented would mean the
delayed packets are to be rejected. Unless you use "window 1" - next
packet isn't send before receipt acknowledge of previous.
However, the "window 1" has advantage of protecting you against
station attempting to use your "passwords" - when you see you don't
have proper answer you can break connection and the hacker can send
few packets only, not enough to do anything...
------------------------------
Date: Fri, 4 Jun 1993 07:34:31 -0500
From: miltonm@inetnode.austin.ibm.com (Milton Miller)
Subject: tcpip as TSRs
To: beacker@tomahawk.asd.sgi.com
No work that I am aware of to make TSR's, for a couple of reasons, including
issues of library function reuse (you end up with each tsr having its own
malloc and printf, etc).
However, there has been some thought actions (no coding done yet) by myself
and some others about making various servers as overlays, and writing an
overlay manager to integrate with the multitasker to help aleviate the memory
usage problem. It is well agreed that the standard overlay managers such
as VROOM will be useless with NOS's multitasking.
milton
--
Milton Miller KB5TKF miltonm@inetnode.austin.ibm.com miltonm@austin.ibm.com
These are my opinions and are independent of any IBM may have.
------------------------------
Date: Thu, 03 Jun 93 20:13:00 CST
From: jimh%kd4ldo.ampr.org@skeggi.vware.mn.org (Jim Henderson)
Subject: Windows NT + TCP/IP Packet
To: tcp-group@ucsd.edu
Hi all:
I just received my Windows NT DDK in the mail today, and was wondering if
there's anyone out there who is working on any kind of TCP/IP -> AX.25
encapsulation driver for NT.
I intend to write my own driver if the work hasn't already been done. I'd
also appreciate any pointers on NT device driver development that anyone has;
I've only got a single machine to work with, so debugging is going to be
very difficult (if not impossible) to do. Hopefully, the driver development
will just be a modification of the stock serial driver, with some hooks into
the TCP/IP network driver.
----
Jim Henderson, KD4LDO/W0 jimh@kd4ldo.ampr.org [44.94.249.38] on 144.99 MHz
Crystal, MN Internet: jimh%kd4ldo@skeggi.vware.mn.org
CIS: 71321,1461 Alt. Internet: hendersj@alpha.db.erau.edu
"Don't ask me how it works or I'll start to whimper!" - Arthur Dent
------------------------------
End of TCP-Group Digest V93 #145
******************************
******************************