Order Tray | Contact Us | Home | SIG Lists

[Ham-80211] Access control suggestions

Gerry Creager n5jxs gerry.creager at tamu.edu
Fri Nov 5 04:28:40 UTC 2004


Actually, in another forum, the comment below has been discussed to some 
excrutiating length.  And we can't find supporting documentation.

IF the intent of WEP is access control and system security, and not to 
obscure content, it could well be legal.  this of course with the "I am 
not a lawyer" disclaimer.

I expect the question to be answered definitively in short order, however.

Now on to the rest.  WEP is hardly encryption, and in a real sense, it's 
NOT security.  Too many folks believe it offers security, but the core 
flaws in counter incrementing cause it to be breakable within, say, 
1k-10k packets.  WEPA is slightly less broken.  Not much, though.

The question is, then, is it good enough to meet the intent of 
precluding operation by unlicensed operators?  My personal preference is 
to use ssl/ssh/tsl for all communications and document their use for the 
Commission based on the need to protect access to computers from 
unauthorized users.  the net effect is a couple of well-placed bridging 
firewalls within the network will stop all non-secure/tunnel traffic, 
and effect the access control result.

Overall, I prefer a challenge-response system incorporating key exchange.

gerry

Steven Phillips wrote:
> You can as long as it doesn't obscure the meaning of a
> message, the WEP codes have to be made public.  i.e.
> the WEP keys on the arrl hsmm page.  Using part 15, we
> can use any key we want and keep it private to protect
> personal/confidential information.  Atleast until it
> goes over the backbone.
> --- dubose at texas.net wrote:
> 
> 
>>Who says you can't use encryption during and
>>emergency?
>>
>>Walt/K5YFW
>>
>>
>>>I was just using the Red Cross as an example.  As
>>
>>for
>>
>>>the rest of it.  It was just a brain storm to
>>
>>explore
>>
>>>another possibility.  The reason for using Part 15
>>
>>for
>>
>>>the local networks is for security.  Since Part 15
>>>doesn't have the encryption restrictions part 97
>>
>>has,
>>
>>>it opens the doors to a wide variety of options
>>
>>for
>>
>>>securing the local network.  As for the backbone
>>>links, as stated, using a narrow angle parabolic,
>>
>>high
>>
>>>gain antenna would, in itself, help secure the
>>
>>network
>>
>>>link from unlisenced use.
>>>--- dubose at texas.net wrote:
>>>
>>>
>>>>>If we want this to work then here's a course
>>
>>of
>>
>>>>action
>>>>
>>>>>that I think would be a good starting point.
>>>>>
>>>>>1 - Forget about which of the regulations to
>>>>
>>>>operate
>>>>
>>>>>under.
>>>>>
>>>>>2 - Devlope a "backbone" to the system.  This
>>>>
>>>>would
>>>>
>>>>>consist of central servers located at central
>>>>
>>>>command
>>>>
>>>>>centers.  In the event of Red Cross
>>
>>activities, a
>>
>>>>good
>>>>
>>>>>location would be the local Red Cross HQ.
>>>>>
>>>>
>>>>Your assumption is that the Red Cross is the HQ
>>
>>of
>>
>>>>emergency communications and
>>>>disaster plans.  However, while this might have
>>
>>been
>>
>>>>true a number of years ago,
>>>>today the Red Cross is a user of ARES/ham
>>
>>emergency
>>
>>>>communications just as are
>>>>local governments and other disaster relief
>>>>organizations.  One should work with
>>>>the local emergency manager to see what
>>
>>emergency
>>
>>>>communications are needed.
>>>>
>>>>
>>>>>3 - Develop a small, portable and easily
>>>>
>>>>configurable
>>>>
>>>>>network infrastructure for field locations
>>
>>such as
>>
>>>>>shelters.  This network would consist of a
>>
>>small
>>
>>>>>server running a web server, mail server, ftp
>>>>
>>>>server,
>>>>
>>>>>and PHP applications to handle communications,
>>>>>bulletines, anything we can think of that
>>
>>pertains
>>
>>>>to
>>>>
>>>>>the local site.  Of course, all of this
>>>>
>>>>ifnformation
>>>>
>>>>>would have to be stored in a database.  The HQ
>>>>>permanent server would host this database.
>>>>
>>>>Are these the  "services"  your customer's need?
>>
>>>>That's the first question to ask.
>>>>
>>>>
>>>>>4 - Local field sites would operate under part
>>
>>15.
>>
>>>>>Network links between sites would operate
>>
>>under
>>
>>>>part
>>>>
>>>>>97.  This would allow local staff to
>>
>>communicate
>>
>>>>with
>>>>
>>>>>eachoter as needed.  Communication that needs
>>
>>to
>>
>>>>go to
>>>>
>>>>>ther sites would be relaed via the local
>>
>>server to
>>
>>>>the
>>>>
>>>>>local hams.  They would then foward the
>>>>
>>>>information
>>>>
>>>>>over the site link to the necessary site.  The
>>>>>receiving site would then relay the message
>>
>>over
>>
>>>>their
>>>>
>>>>>local network to the final destination.  
>>>>
>>>>Why not have a local site with 20-30 PCs in a
>>
>>local
>>
>>>>area operating under Part 97
>>>>and one or two hams be the control operator(s)?
>>>>
>>>>>5 - Utilizing technology such as openH323
>>
>>would
>>
>>>>allow
>>>>
>>>>>for voice and video communications.  Persons
>>
>>with
>>
>>>>a
>>>>
>>>>>handheld computer and a wireless card could
>>
>>send
>>
>>>>live
>>>>
>>>>>video feed of disaster areas for damage
>>>>
>>>>assessment. 
>>>>
>>>>>Communication between non hams at different
>>
>>sites
>>
>>>>>would fall under standard 3rd party
>>
>>communications
>>
>>>>>over the Part 97 Backbone.
>>>>
>>>>Again, see what does the customer want/need. 
>>
>>This
>>
>>>>may vary from customer to
>>>>customer.
>>>>
>>>>
>>>>>Back to the Database.  Site servers would
>>
>>contain
>>
>>>>>information for the local site.  That
>>
>>information
>>
>>>>>could then be relayed to a central database at
>>
>>HQ
>>
>>>>for
>>>>
>>>>>permanent storage.  This would be a necessary
>>
>>step
>>
>>>>to
>>>>
>>>>>prevent information being sent by non hams
>>
>>over
>>
>>>>the
>>>>
>>>>>part 97 "backbone."  The database relay would
>>
>>be
>>
>>>>>manually activiated by a Ham on duty.
>>>>>
>>>>
>>>>Walt/K5YFW
>>>>
>>>>
>>>>>So, there's a rough idea of what I'm thinking
>>
>>of.
>>
>>>>>--- "Eric S. Johansson" <esj at harvee.org>
>>
>>wrote:
>>
>>>>>>Steven Phillips wrote:
>>>>>>
>>>>>>>I have decided to use this topic as a
>>
>>research
>>
>>>>>>project
>>>>>>
>>>>>>>for my sociology class.  Here's a question
>>>>
>>>>that I
>>>>
>>>>>>have
>>>>>>
>>>>>>>come up with.
>>>>>>>
>>>>>>>In my opinion, one of the major uses of
>>
>>this
>>
>>>>type
>>>>
>>>>>>of
>>>>>>
>>>>>>>system would be for emergency use in
>>
>>disaster
>>
>>>>>>>situations.  With the exception of long
>>
>>range
>>
>>>>>>>communciation, is really necessary to use
>>
>>WiFi
>>
>>>>>>under
>>>>>>
>>>>>>>part 97?  What I"m getting at, is this. 
>>
>>In
>>
>>>>the
>>>>
>>>>>>event
>>>>>>...
>>>>>>
>>>>>>I've often argued that the best interface
>>
>>for
>>
>>>>>>emergency communications 
>>>>>>is a browser, and a standard e-mail client. 
>>>>
>>>>Which
>>>>
>>>>>>means amateur radio 
>>>>>>becomes a pipe over which non ham originated
>>>>>>messages pass.  Therefore, 
>>>>>>we should concentrate on building tools that
>>>>
>>>>work
>>>>
>>>>>>with standard Internet 
>>>>>>protocols on one side, transport messages
>>
>>across
>>
>>>>RF
>>>>
>>>>>>links, and then 
>>>>>>interoperate with standard Internet
>>
>>protocols on
>>
>>>>the
>>>>
>>>>>>other side.  I've 
>>>>>>often suggested that UUCP is a good
>>
>>conceptual
>>
>>>>model
>>>>
>>>>>>for this environment.
>>>>>>
>>>>>>before you get your part 97 undies in a
>>
>>bunch,
>>
>>>>yes I
>>>>
>>>>>>know there are 
>>>>>>content restrictions which I believe should
>>
>>be
>>
>>>>>>waived for the 
>>>>>>circumstances.  One could argue for this on
>>
>>the
>>
>>>>>>grounds that we're not 
>>>>>>providing general access, we're providing a
>>>>
>>>>publicly
>>>>
>>>>>>beneficial service 
>>>>>>to the agencies servicing disasters zones. 
>>
>>One
>>
>>>>>>could use tiered 
>>>>>>services to allow individuals to send "I'm
>>
>>alive
>>
>>>>and
>>>>
>>>>>>OK" messages 
>>>>>>outside but not accept any traffic back
>>
>>except
>>
>>>>under
>>>>
>>>>>>very special 
>>>>>>circumstances.  This traffic obviously would
>>>>
>>>>have to
>>>>
>>>>>>go through the part 
>>>>>>97 scrutiny process.
>>>>>>
>>>>>>>Sheesh I'm long winded. 
>>>>>>
>>>>>>comes with a territory.  I've had to go to
>>
>>water
>>
>>>>>>cooled finals I talk so 
>>>>>>much.
>>>>>>
>>>>>>---eric
-- 
Gerry Creager -- gerry.creager at tamu.edu
Network Engineering -- AATLT, Texas A&M University	
Cell: 979.229.5301 Office: 979.458.4020
FAX:  979.847.8578 Pager:  979.228.0173
Office: 903A Eller Bldg, TAMU, College Station, TX 77843




More information about the ham-80211 mailing list