1 / 17

WLAN Segregated Data Services

Learn about the importance of segregating data services in 802.11 networks, from simple home setups to complex enterprise systems. Explore scenarios, requirements, and mechanisms for secure data segregation in WLAN meshes.

Download Presentation

WLAN Segregated Data Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. WLAN Segregated Data Services Authors: Date: 2007-09-17 Slide 1 D. Eastlake (Motorola), G. Hiertz (Philips)

  2. Abstract 802.11 networks, particularly meshes, need VLANs or a similar mechanism for segregated data services. The need varies from a mild requirement to distinguish “visitors” from “residents” in a one AP home network to much stronger and more complex requirements in enterprise, municipal, and other systems. The requirements are particularly important in WLAN meshes. Scenarios and requirements for adding segregated services to IEEE 802.11 are presented along with some comments on existing, under development, or prospective mechanisms to met those requirements. Slide 2 D. Eastlake (Motorola), G. Hiertz (Philips)

  3. Motivation • Segregating traffic for “visitors” who should only have access to the Internet and limited facilities, from “insider” traffic. • Provision of different services for free and subscriptions services in Hot Zone or Municipal systems. (May also segregate subscription service through different carriers.) • In mesh environments, ability to safely forward data through nodes with limited trust. • To enable aggregation of traffic over a single infrastructure for efficient deployment. • Dedicated traffic segregation by type, such as VoIP Slide 3 D. Eastlake (Motorola), G. Hiertz (Philips)

  4. Protected Services Firewall MAP 1 AP 2 Example Scenario I(unified infrastructure, single interface end stations) Internet MAP 2 Local Station Local Station Local Station Guest Station Local VLAN Guest VLAN Wired Connection Local Station Guest Station D. Eastlake (Motorola), G. Hiertz (Philips)

  5. Organization 1 Infrastructure Organization 2 Infrastructure Local Mesh Service Organization 1 Service Organization 2 Service Org 1MPP Org 1MP Org 2MP Org 2MP Org 2MPP Org 2MP Org 1MP Org 3MP Org 1MP Example Scenario II(diverse mesh, multi-interface mesh points) Internet D. Eastlake (Motorola), G. Hiertz (Philips)

  6. Org 1MPP Org 1MP Org 2MP Org 2MP Org 2MPP Org 2MP Org 1MP Org 3MP Org 1MP Scenario II without segregated data services Internet Organization 1 Infrastructure Organization 2 Infrastructure Organization 1 Service Organization 2 Service D. Eastlake (Motorola), G. Hiertz (Philips)

  7. Requirements • Advertising Availability of Services • Associating/Authenticating/Authorizing for One or more Specific Services • Multiple Service Security Channels Between Two Stations • Transit Frame Labelling • Protection of Segregated Data from Unauthorized Access • Configuration and Management Slide 7 D. Eastlake (Motorola), G. Hiertz (Philips)

  8. 1. Advertising Availability of Services • Current practice: Transmit multiple Beacons, as is done at IEEE 802 meetings. • Work in progress: General Advertisement Service (GAS) mechanisms in 802.11 TGu (Interworking with External Networks). • Includes SSIDC (SSID Container IE) for transmission of multiple SSIDs (with or without multiple BSSIDs) in a single beacon. • No additional chartered work appears necessary for this requirement. The TGu mechanisms are adequate. Slide 8 D. Eastlake (Motorola), G. Hiertz (Philips)

  9. 2. Associating/Authenticating/Authorizing for a Specific Service • Current practice: Only one association, 802.11i security. • Work in progress: • TGw (Protected Management Frames) to extends security to some control messages • TGs (Mesh Networking) with authentication to mesh distinguished from authentication to an AP • TGu (Interworking with External Networks) different credentials/authentication for different back end carriers • Possible new work:Ability to have different credentials / authentication for different Services/VLANs. Slide 9 D. Eastlake (Motorola), G. Hiertz (Philips)

  10. 3. Multiple Service Security Channels Between Stations • Current Practice: • AP can have multiple security associations but each with a different end station. • Two stations can have multiple IPsec security associations or the like at the application level. • Work in Progress: TGs (Mesh Networking) permits multiple associations but each with a different mesh point. • Possible new work: • Different security associations for different services/VLANs • Need to handling unicast, multicast, and broadcast • Development of a new Authenticator PAE function that can manage multiple SAs with a given neighbor Slide 10 D. Eastlake (Motorola), G. Hiertz (Philips)

  11. 4. Transit Frame Labelling • Current Practice: • Current standard explicitly permits 802.1Q-Tag in payload (802.11-2007 Annex M) but Q-Tag’s priority and VLAN ID fields are otherwise ignored. • Only obvious way is to use different MAC addresses. • Work in Progress: none... • Possible new work: • Header addition to distinguish Service/VLAN • Other mechanisms? Slide 11 D. Eastlake (Motorola), G. Hiertz (Philips)

  12. 5. Protection of Segregated Data from Unauthorized Access • Current Practice: Have to use IPsec or some similar application level mechanism to protect data at intermediate hops. • Work in Progress: none... • Possible new work: • Optional edge-to-edge security between original source station and final destination station. But not all services would require this. (If VLAN mapping is possible, authentication should be keyed to SSID, not VLAN ID.) Slide 12 D. Eastlake (Motorola), G. Hiertz (Philips)

  13. 6. Configuration and Management Current Practice: SNMP (Simple Network Management Protcol) GVRP (GARP VLAN Registration Protocol) Proprietary command line interfaces and protocols Work in Progress: SNMP MIB (Management Information Base) additions by TGu (Interworking with External Networks) Possible new work: MIB additions or other mechanisms for configuration and management including setting-up and deleting VLANs Slide 13 D. Eastlake (Motorola), G. Hiertz (Philips)

  14. Straw Polls in San Francisco • Results in WNG SC during morning session on 17 July 2007: • Should the 802.11 WNG SC proceed at this time to vote on a motion to set up a Study Group?Yes: 6 No: 27 Abstain: 18 • Should 802.11 receive further presentations on the topic of segregated data services?Yes: 46 No: 0 Abstain: 1 Slide 14 D. Eastlake (Motorola), G. Hiertz (Philips)

  15. Motion Changes from previous draft motion: Remove Requirement 1, which is covered by TGu, from the purview of the proposed Study Group. The Study Group would not be directed to produce a PAR and 5 Criterion to amend 802.11 but can consider whatever is the best course within the 802.11 rules. Slide 15 D. Eastlake (Motorola), G. Hiertz (Philips)

  16. Motion (cont.) Moved, To request the IEEE 802.11 Working Group to approve and forward to the IEEE 802 Executive Committee the creation of a “WLAN Segregated Data Services” Study Group to consider how best to meet requirements as follows: labeling frames per service; security of data within a service; and the configuration and management of such services. Moved: Seconded: Yes: No: Abstain: Slide 16 D. Eastlake (Motorola), G. Hiertz (Philips)

  17. References • Draft 802.11s D1.06 – ESS Mesh Networking • Draft 802.11u D1.0 – Interworking with External Networks • Draft 802.11w D2.1, – Protected Management Frames • IEEE Standard 802.11-2007 – WLANs • IEEE Standard 802.1Q-2005 – VLANs, GVRP • IETF STD 62 (IETF RFCs 3411 through 3418) – SNMP Slide 17 D. Eastlake (Motorola), G. Hiertz (Philips)

More Related