Re: howto WLAN, several subnets
Michael Richardson wrote: Alexandru == Alexandru Petrescu [EMAIL PROTECTED] 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 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? In fact, the client can't tell the difference between IBSS and BSS. Nor can Linux systems become IBSS systems without something like hostap (hostap is one way, wireless bridging might be another way I think.) Alex
Re: howto WLAN, several subnets
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
Re: howto WLAN, several subnets
In fact, the client can't tell the difference between IBSS and BSS. Nor can Linux systems become IBSS systems without something like hostap (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/
Re: howto WLAN, several subnets
From: Alexandru Petrescu [EMAIL PROTECTED] ... 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. 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 PROTECTED]
Re: howto WLAN, several subnets
On Fri, 21 Nov 2003, Alexandru Petrescu 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... In fact, the client can't tell the difference between IBSS and BSS. Nor can Linux systems become IBSS systems without something like hostap (hostap is one way, wireless bridging might be another way I think.) Alex -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Re: howto WLAN, several subnets
Joel Jaeggli wrote: On Fri, 21 Nov 2003, Alexandru Petrescu 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
Re: howto WLAN, several subnets
On Fri, Nov 21, 2003 at 05:29:15PM +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... 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 PROTECTED] (Andrew Partan)
howto WLAN, several subnets
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
Re: howto WLAN, several subnets
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 On Thu, 20 Nov 2003, Alexandru Petrescu wrote: 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 -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Re: howto WLAN, several subnets
Joel Jaeggli wrote: 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
Re: howto WLAN, several subnets
On Thu, 20 Nov 2003, Alexandru Petrescu 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. [...] 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 Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: howto WLAN, several subnets
On Thu, 20 Nov 2003, Alexandru Petrescu wrote: Joel Jaeggli wrote: 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. I expect you'll get a bounch of nodes in adhoc mode with the ietf5X ssid and the ietf5x wep key as well... 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 -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Re: howto WLAN, several subnets
Pekka Savola wrote: On Thu, 20 Nov 2003, Alexandru Petrescu 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. [...] Exactly what problem is being solved by the introduction of a key? 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. My perception is that it brings more problems than it fixes (as you 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
Re: howto WLAN, several subnets
Joel Jaeggli wrote: 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. 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
Re: howto WLAN, several subnets
On Thu, 20 Nov 2003, Alexandru Petrescu wrote: Joel Jaeggli wrote: 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. 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). 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. Alex -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Re: howto WLAN, several subnets
-BEGIN PGP SIGNED MESSAGE- Alexandru == Alexandru Petrescu [EMAIL PROTECTED] writes: Alexandru Joel Jaeggli wrote: 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 PROTECTED] http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic(Just another Debian GNU/Linux using, kernel hacking, security guy); [ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP71Qq4qHRg3pndX9AQH37QP+IdXat9qKozC8eq7sgvr0IIrKE1E+0je8 +VAByQ6CnWPj3g9dzuL/lj7A7x14S2Qvv0UF7bcv9qRCGxz1QrF1Egw41oNzv/Ro gWh0FEjPkbc+4itFRqVzFmO5YxSY93v2QPHuYLZgzDPmq+98NaZxtNWo3LbJb5Dj w7rQGUslLIc= =e4MB -END PGP SIGNATURE-
Re: howto WLAN, several subnets
-BEGIN PGP SIGNED MESSAGE- Alexandru == Alexandru Petrescu [EMAIL PROTECTED] 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 ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson,Xelerance Corporation, Ottawa, ON|net architect[ ] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic(Just another Debian GNU/Linux using, kernel hacking, security guy); [ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP71RVYqHRg3pndX9AQHgqAP/cMNuKQpXOyheLXHeg3RFJEa3usyT0ZyS c7y2qKkdmuTwZEDIAkt1hc2l62G91+aFDzQbx/3OYQhqG9I+4yXz3e2UnMe4btGh RMJQnxYrfv1EyrY4fGcsiCN2qRcuJ3KyNrkrRDRnfW0Fw/t9LsRALEfcsR/NGbog TAEnhWQp5t4= =qHj+ -END PGP SIGNATURE-
