Date: Sat, 22 May 93 04:30:11 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 #132
To: tcp-group-digest
TCP-Group Digest Sat, 22 May 93 Volume 93 : Issue 132
Today's Topics:
ENCAP packets not recognized properly? (2 msgs)
KA9Q Flavor Supporting CD-ROMs??
NET/ROM standardization
NOS Questions
radio logins
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, 21 May 1993 14:17:33 -0600
From: ke9yq@ke9yq.ampr.org (Bob Van Valzah, ke9yq)
Subject: ENCAP packets not recognized properly?
To: TCP-Group@UCSD.Edu, wkt@cs.adfa.oz.au
>I just captured some stuff with Etherfind. The IP protocol type I believe
>you are using for the pings is 94 (IP within IP), not 7 (UDP).
Right. The IP in IP RFC (sorry, don't know the number off the top of my
head) requires type 94. UDP isn't involved at all.
I had to call cisco to learn that this line had to be added to my config file:
! permit IP other than ICMP, UDP, & TCP (e.g. ham radio gateway)
access-list 100 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
It seems a little strange, but if you don't explicitly permit IP, many
things like TCP and UDP can pass just fine, but other IP services get
blocked.
Warren, This has bitten at least three encap sites now--perhaps it'd be a
good tip to add to your gateways paper?
73, Bob, ke9yq
------------------------------
Date: Fri, 21 May 1993 14:35:31 -0700
From: Paul Traina <pst@cisco.com>
Subject: ENCAP packets not recognized properly?
To: ke9yq@ke9yq.ampr.org (Bob Van Valzah, ke9yq)
gag... who told you this? you want to add:
access-list 100 permit 94 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
or something more restrictive. Send me a copy of your config (remove the
passwords) and I will check it over for you.
Paul Traina
cisco Systems
KC6TCN
From: ke9yq@ke9yq.ampr.org (Bob Van Valzah, ke9yq)
Subject: Re: ENCAP packets not recognized properly?
>I just captured some stuff with Etherfind. The IP protocol type I believe
>you are using for the pings is 94 (IP within IP), not 7 (UDP).
Right. The IP in IP RFC (sorry, don't know the number off the top of my
head) requires type 94. UDP isn't involved at all.
I had to call cisco to learn that this line had to be added to my config file
>>:
! permit IP other than ICMP, UDP, & TCP (e.g. ham radio gateway)
access-list 100 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
It seems a little strange, but if you don't explicitly permit IP, many
things like TCP and UDP can pass just fine, but other IP services get
blocked.
Warren, This has bitten at least three encap sites now--perhaps it'd be a
good tip to add to your gateways paper?
73, Bob, ke9yq
------------------------------
Date: Fri, 21 May 93 16:51:27 EDT
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: KA9Q Flavor Supporting CD-ROMs??
To: jt@zfja-gate.fuw.edu.pl
I implemented the "per drive" directory structure in WG7J NOS many
versions back. A seperate (from DOS) structure storage area is kept
for each of (up to) 26 drives. Once a directory is entered for a
particuliar drive just 'CDing" to the drive letter puts you in
the current logged drive for that letter. This is in effect NOW
in WG7J. This is for FTP client and at the NOS prompt.
Doug
------------------------------
Date: Fri, 21 May 93 12:55:38 GMT
From: jbloom@arrl.org (Jon Bloom KE3Z)
Subject: NET/ROM standardization
To: tcp-group@ucsd.edu, MIKEBW@ids.net
>All right... assuming that we were to take on the job of writing a
>netrom standards document, who should be explicitly consulted? I
>suppose WA8DED and G8BPQ are obvious choices, but who after that?
>And are they mailable on the Internet?
I'd suggest that the most important players are those who are
actively developing code. It would be lovely to have Ron Raikes
involved, but my impression is that he's no longer actively
working on this stuff. I'm not as aware of who's who in NET/ROM
development as I ought to be, so I can't suggest who all the
players are, but 'BPQ, the NORD><LINK folks, and whoever is working
on NOS NETROM stuff would seem to be the core group. The point is
to begin to get the various implementations to converge, and in order
to do that you need to get all of the principal implementors engaged.
>By the way, what would we call the protocol? "NET/ROM" is supposed
>to be a trademark, regardless of its history, and I don't like the
>idea of writing a public standard for a proprietary protocol. (Note
>that Software 2000, as far as I know, never attempted to claim that
>the protocol itself was proprietary, as distinct from their EPROM
>code implementation.)
Well, I take "NET/ROM" to be the name of the product, not the
protocols. Lacking any other name, we've always called the protocols
NET/ROM, but there's no need to continue doing so. Hey, maybe we can
call this (A)V.23 or something! (I'm kidding.)
>Another big problem is the level at which the standard would apply.
>It seesm pretty obvious that any meaningful standard would have to
>specify frame structures and the like, but what about implementation
>details which have network wide significance? Netrom is notorious
>for these things. G8BPQ, for example, defines lots of dangerous
>extensions to the protocol, such as QUALADJUST, which operate wholly
>within the software but which affect the whole neighborhood. Would
>the standard address issues such as this?
>
>Would we take on the user interface in the standards document? Why
>does "I" get you a paragraph of [I]nformation from G8BPQ, yet mean
>[I]dentify to a real NET/ROM node? Why does "S" mean [S]ystem to
>G8BPQ and [S]ysop to TheNet? And, of course, my personal favorite,
>"C <port> <callsign>" for G8BPQ and nothing else.
Interoperability of systems using the protocol stack is the goal.
My FTP implementation must send "TYPE I" to select image-mode
transfer, but the machine doesn't care whether I select that by
typing "type i" or "binary" or "8bit" or whatever. That would
seem a logical approach to take here, too. (If you *do* want a
user-interface standard, I suggest it be a separate effort.)
>Another winner is the serial async ("back end") port on NET/ROM and
>TheNet TNCs. The latest fashion up here, using a scheme adopted by
>the Notheast Digital Association (NEDA), is to define the relative
>quality across the diode matrix as 203. In other words, one port of
>a wireline connected system would know about each other port of the
>same wireline connected system at less than perfect quality. This
>obviously has no basis in reality, and is used as a kludge method to
>limit the propagation of nodes. However, G8BPQ has no way to do this,
>since G8BPQ has a weird notion that you never lose packets when moving
>them from one port to another on the same machine. Is the lack of
>this rather odd (if not foolish) capability to be counted against
>G8BPQ when determining its compliance?
I think this and other like questions are best address by whatever
group sits down to generate the standard. A logical place to start
in any such effort is to address the question of scope.
------
Jon Bloom, KE3Z | jbloom@arrl.org
American Radio Relay League |
225 Main St., Newington CT 06111 |
------------------------------
Date: Fri, 21 May 1993 21:01:17 -0700
From: mitchell@sosc1.sosc.osshe.edu
Subject: NOS Questions
To: tcp-group@ucsd.edu
I have two questions:
1) I'm running a Novell 3.11 network and we're planning to attach our
network to internet. I'd like to run either JNOS or NOS on a workstation
to act as a mail server and nntp server. I have LAN Workplace for Dos,
WinQVT/net, JNOS and WNOS. Since I'd like the work stations on the network
to be able to use IPX and IP, I'm wondering how to set up the workstations.
I have the ODI drivers and all of the Clarkson packet drivers. Any ideas?
Ideally, it would be nice to be able to run windows and open a ftp or telnet
session whenever the user wants without having to reboot the computer to
load a different set of drivers.
2) Is there a way to provide users who use JNOS, WNOS or one of the other
NOS's to run a DOS program? I'd like to be able to set up a server for
the local packet radio folks to access an orbit prediction program for
satellites.
I hope this is the right place to ask the question. I'm kind of new
to Internet.... Thanks
Stu, WD4ECK
------------------------------
Date: 21 May 93 11:54:10 GMT
From: Jon Jagger <J.R.Jagger@sheffield-hallam.ac.uk>
Subject: radio logins
To: tcp-group@ucsd.edu
Hi everyone.
I was/am thinking about setting up a gateway here at work to give
staff members (who are also radio amateurs) radio access to the
internet from home. If it takes off the idea is that staff might
be trained inhouse and sit the novice exam.
A big problem is one of security. Our JANET regulations mean such
a gateway must be secure. I.e., not just any radio amateur can get
through it. I have looked at ka9q's code on ucsd for rlogin. This is
basically a dynamic system. At login the gateway gives a string, and
you have to send back the string des encrypted using a des key that
you and the gateway have agreed. This is fine as it goes, but I was
hoping for a completely transparent gateway. I think I may have
thought of a way to do it.
If every packet has a date:time stamp des encrypted in its header,
and you ensure every packet has a different stamp (i.e., your system
clock is has sufficiently fine granularity) then every 'password'
is valid only once! The gateway simply records for each user their
des key, and the last date:time stamp received from them.
A packet gets through the gateway if
a) it decrypts to a date:time
b) if that date:time is strictly greater than the last one.
Under this system as I see it, eavesdroppers might get to send
1 packet through the gateway but only under these circumstances....
a) your packet is lost and never gets to the gateway.
b) the eavesdropper hears this packet and resends it
(possibly altering the contents of the packet)
c) the gateway hears this packet BEFORE it receives another
packet from you with a later date:time stamp.
The MAJOR limitation of this as I see it is that you can't digipeat
TO the gateway. You must reach it one hop. This would seem to be
a fundamental limitation of th situation. I can't see that any
login procedure could be secure and overcome this.
Does this sound reasonable/feasible ?
I would be interested in peoples responses, on how others
have looked at and tackled this problem.
Thanks
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!
------------------------------
End of TCP-Group Digest V93 #132
******************************
******************************