Subject: howto WLAN, several subnets

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 20 Nov 2003 20:27:46 +0100

Hi, I was not at the last IETF, and couldn't see live the reportedly bad
workings of WLAN.  I am not going to make suggestions to 58crew since
I'm certain they've already tried lots of configurations.  Just to share
our thoughts on how we make work several
independent/deterministic-behaviour 802.11b subnets:

-for the general public, set the AP's with both an essid and a key, in
  Infrastructure mode (managed).

-for the aodv public, convene to use a different essid and a different
  key and ad-hoc mode.  If the aodv people need several ad-hoc mode
  subnets, just set yet another essid+key; of course all essid's and
  key's must be different each compared to the other.

We have experience with several independent/deterministic-behaviour WLAN
links set up that way.

But, even if this works well with several AP types and cards, there
exist cards out there that only support enc at 128bit while others only
at 64bit, which makes _any_ use of encryption non-portable.  That says,
if ietf crew decides to put a key 64bit then there will be people not
able to connect.  Same if it decides for 128bit.

To me, the whole story is a matter of compatibility, backward
compatibility and forward compatibility between various versions of the
802.11 standards _and_ of their implementations.

It is exactly like with Word versions: it's the same Doc format but not
quite depending on the Windows version too.

I do not think anyone could be blamed of "interfering" with a WLAN
network, most notably because this is unlicensed spectrum; I presume
harmonics of an old microwave oven could be blamed for interference with
the ietf wlan as much as a user not knowing his intel laptop has centrino.

Alex

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 20 Nov 2003 12:14:16 -0800 (PST)

what exactly is the point of having a wep key shared by 2000 people.

except to have another thing for people to screw up when they try and type 
it in our paste it. thereby increasing the support overhead at the help 
desk.

joelja

-- 
-------------------------------------------------------------------------- 
Joel Jaeggli  	       Unix Consulting 	       [email-masked]    
GPG Key Fingerprint:     5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 20 Nov 2003 21:43:59 +0100

> what exactly is the point of having a wep key shared by 2000 people.

I didn't mean it for data confidentiality; I meant it for building the
wires W in WEP not for the P privacy.  Basically one such W for ietf and 
one for aodv.

We've noticed that setting both the essid and the key helps a lot with
the automatic detection various procedures, such as end-user laptops
don't get automatically attached to essid's that happen to be advertised
  without keys by other end-users' laptops.

> except to have another thing for people to screw up when they try and
>  type it in our paste it. thereby increasing the support overhead at
>  the help desk.

Yes, I understand that talking in terms of 2000 actual people is 
different than in terms of 20some hosts we're using.

Alex

---

From: Pekka Savola <[email-masked]>
Date: Thu, 20 Nov 2003 22:43:16 +0200 (EET)

>   key's must be different each compared to the other.
[...]

Exactly what problem is being solved by the introduction of a key?

My perception is that it brings more problems than it fixes (as you 
stated), and gives a wrong sense of security to boot.
  
-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 20 Nov 2003 22:07:26 +0100

Pekka Savola wrote:
>> -for the general public, set the AP's with both an essid and a key,
>>  in Infrastructure mode (managed).
>> 
>> -for the aodv public, convene to use a different essid and a 
>> different key and ad-hoc mode.  If the aodv people need several 
>> ad-hoc mode subnets, just set yet another essid+key; of course all
>>  essid's and key's must be different each compared to the other.
> 
> [...]
> 

Maybe, helping to find conceptual "wires" to attach to in a
deterministic manner, not necessarily private.  One can not accidentally
attach to such a wire without explicitely setting a key.

> stated),

I stated that if crew decides 128bit then all people having 128bit cards
can work ok (and not those with 48bit-exclusively cards).

It does not stop an attacker to set his own linux AP with same key and 
essid ietf, fooling passers by; but at that point that person, if found, 
_can_ be blamed.

> and gives a wrong sense of security to boot.

I didn't claim security.

So, if the use of keys gives a false sense of security and moreover
brings overload at the helpdesk, sorry for the proposal, something else
must be used.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 20 Nov 2003 22:14:52 +0100

Joel Jaeggli wrote:
> I expect you'll get a bounch of nodes in adhoc mode with the ietf5X ssid 
> and the ietf5x wep key as well...

If my node has mode "managed" it will never attach to laptop nodes 
having same key same essid but mode ad-hoc.

(my linux node, I know not about windows drivers).

Alex

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 20 Nov 2003 13:54:43 -0800 (PST)

> (my linux node, I know not about windows drivers).

that's exactly what's happening though... we have very good ideas about 
whose wireless implementations are doing the right thing. it's the ones 
that aren't that are the problem.

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 20 Nov 2003 13:03:28 -0800 (PST)

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Nov 2003 18:39:24 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Alexandru" == Alexandru Petrescu <[email-masked]> writes:
    >> what exactly is the point of having a wep key shared by 2000 people.

    Alexandru> I didn't mean it for data confidentiality; I meant it for
    Alexandru> building the 
    Alexandru> wires W in WEP not for the P privacy.  Basically one such W
    Alexandru> for ietf and  
    Alexandru> one for aodv.

  Why do you think that the helpful drivers that kept us coming up in IBSS
mode (proper name for new "ad-hoc" mode) won't use the keys as well?

  Further, as was said, it does nothing against malicious rogue APs?  

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Nov 2003 18:42:15 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Alexandru" == Alexandru Petrescu <[email-masked]> writes:
    Alexandru> If my node has mode "managed" it will never attach to laptop
    Alexandru> nodes  
    Alexandru> having same key same essid but mode ad-hoc. 

  No, that's isn't true.
  It is true for:
     "ad-hoc"  = Lucent Ad-HOC mode (deprecated)

  but not true for:
     "ad-hoc"  = 802.11 IBSS mode

  In fact, the client can't tell the difference between IBSS and BSS.
  Nor can Linux systems become IBSS systems without something like "hostap"

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 Nov 2003 11:14:48 +0100

>      "ad-hoc"  = 802.11 IBSS mode

Ok, it is true that that behaviour I mentioned above was with Lucent
cards and Cisco (which I don't know what chipset). Also, I didn't know
they call "ad-hoc" IBSS where I is for Infrastructure.

So I guess I was wrong.

So instead of forcing key+essid on the clients, would setting the AP's
MAC address on the clients be a solution?

>   Nor can Linux systems become IBSS systems without something like "hostap"

(hostap is one way, wireless bridging might be another way I think.)

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 Nov 2003 11:18:53 +0100

Michael Richardson wrote:
> Why do you think that the helpful drivers that kept us coming up in
> IBSS mode (proper name for new "ad-hoc" mode) won't use the keys as
> well?

Ok, I didn't know that.

> Further, as was said, it does nothing against malicious rogue APs?

Rogue malicious wily ruthless users skilled enough to configure hostap
can rightfully be blamed; but not the novice user turning on
a particular vendor's laptop.

Alex

---

From: shogunx <[email-masked]>
Date: Thu, 20 Nov 2003 07:23:26 -0500 (EST)

> (hostap is one way, wireless bridging might be another way I think.)

one could have multiple wireless cards in one machine acting as
access points also, routing between discrete wireless networks.
one could even use managed on one card and ad-hoc or hostap master
mode on the other, to move bandwidth from one network to another all
together, while appearing as a single client.

cheers
scott

> Alex

sleekfreak pirate broadcast
world tour 2002-3
live from the pirate hideout
http://sleekfreak.ath.cx:81/

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 21 Nov 2003 08:23:09 -0700 (MST)

> From: Alexandru Petrescu <[email-masked]>

> ...

That may be true in some situations, but should it be tolerated at
the IETF?  Why shouldn't such behavior be prima facie evidence of
insufficent interest or experience in the business of the IETF to be
allowed to participate?

Even in other situations, that sort of behavior is the direct cause
of most of the current security and spam problems on the Internet.
If people would not run "user friendly" products that have designed
and implemented such gross negligence that they execute with full
system privileges any data that happens to come along, then there
would be as many worms, virus, and spam amplifiers in general on the
Internet as there are among UNIX based products.

So a Modest Proposal: Discover which "user friendly" products were
responsible for your troubles and ban everything from their maker(s)
from the next meeting.  Ban any person who breaks that ban at the next
meeting from the following 3 meetings.

(Cue cries about the business of the IETF including educating the masses,
the complete unfairness of holding anyone accuntable for anything,
and the need to be "open to innovation.")

Vernon Schryver    [email-masked]

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 21 Nov 2003 08:03:41 -0800 (PST)

> MAC address on the clients be a solution?

not really unless you want to want to be associated with one of 30 aps for 
the entire conference...

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 Nov 2003 17:29:15 +0100

Joel Jaeggli wrote:
>> So instead of forcing key+essid on the clients, would setting the
>> AP's MAC address on the clients be a solution?
> 
> not really unless you want to want to be associated with one of 30
> aps for the entire conference...

Right.  So label the AP MAC address to the meeting room name then.
Something like: "Conrad C - 00:D0:59:14:EE:55" ?

Alex

---

From: Andrew Partan <[email-masked]>
Date: Fri, 21 Nov 2003 12:03:23 -0500

>aps for the entire conference...

The problem I ran into was seeing a number of IBSSs, most of which
seemed to be using unallocated mac addresses.  Unfortunately I did
not keep any notes of what I acutally did see.

I wished I could have told my 4.8 FreeBSD system to only associate
with one of a list of APs.  I would have given it a list of all of
the real APs and told it to only choose one of those.  Wildcarding
might have also been useful - I would have done (say) two mac address
ranges the real APs were using & ignored the rest.
	[email-masked] (Andrew Partan)