Capwap Mailing List: RE: BSSID-WLAN mappings

[Bob O'Hara (boohara) (boohara]

The mechanism below is, of course, not compliant with the 802.11 standard.  It is a proprietary extension.  It is not clear to me why CAPWAP should support this mechanism, or any other proprietary mechanism.  As Jeff points out below, this is not compatible with all clients (most likely because the mechanism is not mentioned in the standard) and also violates the security assumptions of 802.11.

 -Bob
 

 

---

From: Jeff Joslin [mailto:jjoslin [at] belairnetworks.com]
Sent: Friday, April 28, 2006 12:19 PM
To: capwap [at] frascone.com
Subject: RE: [Capwap] BSSID-WLAN mappings

You can implement multiple SSID with single BSSID by having only one SSID in the beacon; the others SSIDs are hidden. If a client broadcasts a probe for one of those hidden SSIDs the AP will respond and the client can then do a normal association. The AP maintains one broadcast/multicast key for each encryption type (WEP, TKIP, AES) and uses the appropriate one according to the encryption type of the frame’s SSID. This allows a certain amount of information leakage between SSIDs, but in most applications this is acceptable.

 

The above scheme works, after a fashion, but creates some client compatibility issues. Multiple BSSID is preferable.

 

One SSID == 1 WLAN. In general we cannot assume that 1 BSSID == 1 WLAN.

 

Perhaps 1 VLAN == 1 WLAN is more helpful? It is standard practice to map each SSID to a separate VLAN.

 

Jeff Joslin

Senior Network Architect

BelAir Networks

 

---

From: Pat Calhoun (pacalhou) [mailto:pcalhoun [at] cisco.com]
Sent: 28 April 2006 2:57 PM
To: Puneet; Bob O'Hara (boohara)
Cc: capwap [at] frascone.com
Subject: RE: [Capwap] BSSID-WLAN mappings

 

Well, first, there is no way that I am aware of where you can have multiple SSIDs for a single BSSID. Furthermore, if one were to do this, how would you handle broadcast packet encryption, where a station would see packets from a BSSID, but would not be able to decrypt it - presumably because the AC would have multiple GTKs, not indexed on a BSSID, but some other non-defined mechanism.

 

I contend 1 BSSID == 1 WLAN.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

 

---

From: Puneet [mailto:pb.ietf [at] gmail.com]
Sent: Monday, April 17, 2006 10:39 AM
To: Bob O'Hara (boohara)
Cc: capwap [at] frascone.com
Subject: Re: [Capwap] BSSID-WLAN mappings

Bob,

> We should not be implementing, or requiring an CAPWAP implementation to implement a method
> that lowers the security of the WLAN.

I am not sure I understand the argument here: supporting open or WEP also does the same thing, but CAPWAP supports those encryption protocols. CAPWAP does not force everyone to support WEP, but it *allows* it to be setup on a WLAN. Along the same lines we should allow this mapping too. Maybe make a note that it does not allow WLAN traffic separation into logical groups over the air (Saravanans point)

Thanks,
Puneet

On 4/17/06, Bob O'Hara (boohara) <boohara [at] cisco.com> wrote:

There are also security issues when there is not a 1:1 mapping of WLAN to BSSID.  Without this restriction, a station will not have any assurance that traffic it believes is encrypted and protected according to the policy of the WLAN to which it is associated is not being decrypted by an oracle (the AP) and rebroadcast to other stations without the same requirements for abiding with the same security policies.

 

We should not be implementing, or requiring an CAPWAP implementation to implement a method that lowers the security of the WLAN.

 -Bob
 

 

 

---

From: Puneet [mailto: pb.ietf [at] gmail.com]

Sent: Sunday, April 16, 2006 4:47 PM
To: Saravanan Govindan
Cc: capwap [at] frascone.com
Subject: Re: [Capwap] BSSID-WLAN mappings

Hi Saravanan,

I see your point, but this seems to address a very specific deployment scenario (service providers sharing WLAN equipment). If nothing else in the CAPWAP messages is dependent on this, then this should be a recommendation instead of a mandate. That way the protocol remains inclusive, and also meets its objective.

I think it is very important that existing implementations are not excluded just because they dont seem to meet one specific need in a specific deployment scenario.

Thanks,
Puneet

On 4/15/06, Saravanan Govindan <saravanang [at] hotmail.com> wrote:

Hi Puneet,

My concern regarding the BSSID - WLAN mapping is based on the mandatory
Objective "Logical Groups" (Section 5.1.1 of CAPWAP Objectives).

The Objective requires that WTP traffic be kept logically distinct among
logical groups. This arises from the commercial need of service providers
sharing WLAN infrastructure equipment. Service providers want their traffic
to be distinguished both over the wireless environment (e.g. BSSIDS) and
over the AC-WTP environment (e.g. WLANs).

The BSSID-WLAN mapping issue is the technical requirement coming from this
commercial need. It allows an AC - or WTP - to decide how logical groups are
separated over the wireless and AC-WTP segments. So by making this mapping,
CAPWAP frames of different logical groups (WLANs) can be distinctly
exchanged.

I agree with others that this mapping should not exclude any implementation
- my concern is that the mapping be including in the first place.

Cheers,

Saravanan




>  ------------------------------
> *From:* Puneet [mailto:pb.ietf [at] gmail.com]
> *Sent:* Friday, April 14, 2006 12:29 AM
> *To:* capwap [at] frascone.com
> *Subject:* [Capwap] BSSID-WLAN mappings
>
> the BSSID description in Section 11.9.1 'WTP Radio Configuration' notes
> that a WTP that supports 16 WLANS MUST have 16 MAC addresses reserved for
> it. Why? ie. what part of the protocol does not work if we have multiple
> SSIDs on a single BSSID? (whether thats good design or bad is a different
> matter). Since the WLAN ID could be used in all such places to convey
WLAN
> information back to the AC, why do we need to mandate this 1:1 BSSID-WLAN
> mapping?
>
> Thanks,
> Puneet
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap
>

_________________________________________________________________
Get an advanced look at the new version of MSN Messenger.
http://messenger.msn.com.sg/Beta/Default.aspx

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap