1. Shared Infrastructure
November 2005
doc.: IEEE /1062r0
November 2005
Shared Infrastructure
Date:
Authors:
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Mike Moreton, STMicroelectronics
Mike Moreton, STMicroelectronics

2. November 2005
doc.: IEEE /1062r0
November 2005
Abstract
This submission discusses the impact of shared infrastructure environments (e.g. Airports) on the 11u architecture.
Mike Moreton, STMicroelectronics
Mike Moreton, STMicroelectronics

3. Informal Feedback from Wi-Fi M&PA
November 2005
Informal Feedback from Wi-Fi M&PA
“We need support for shared infrastructure environments such as airports”
APs are not owned by a single operator, but are shared between multiple operators
Allows better RF planning in the 2.4GHz band
Only 3 channels, so multiple operators would be restricted to a single (possibly shared) channel
Reduces the cabling requirement
Mike Moreton, STMicroelectronics

4. Isn’t this the same as a Roaming Agreement?
November 2005
Isn’t this the same as a Roaming Agreement?
A roaming agreement is normally between two operators
In this case the APs may be managed by a 3rd party, who wants no direct commercial relationship with the users
A roaming agreement is not normally between two direct competitors
More normally a way of extending coverage to areas not covered by the home network
In this case the aim is for direct competitors to share the same network.
There’s a lot less trust than there is normally…
Mike Moreton, STMicroelectronics

5. November 2005
doc.: IEEE /1062r0
November 2005
Motion
Accept the following text as a TGu requirement for proposals, and include it in the requirements document, with requirement status set to “Optional”.
Define how shared infrastructure architectures where the DS is shared by directly competing operators will be supported.
Informative Note: This is an environment where the normal trust model within the DS does not apply. While the actual implementation may prove to be outside the scope of this TG, our architecture should have some idea of how this would be achieved.
Proposed:
Seconded:
Result (for/against/abstain):
Mike Moreton, STMicroelectronics
Mike Moreton, STMicroelectronics

6. November 2005
A Change of Tone
The first part of this presentation proposed a new requirement that we should add to our document.
The rest of this document describes a possible solution, and what its impact would be.
Mike Moreton, STMicroelectronics

7. 802.11 Security Model 802.11 secures the local link to the AP
November 2005
Security Model
secures the local link to the AP
Once you’re there it pretty much assumes you’re in a trusted environment
In the shared infrastructure environment, operators don’t want to trust the DS.
MAC address spoofing
Traffic monitoring
Impersonation
They want a secure path across this “crocodile infested pond” to their network
Mike Moreton, STMicroelectronics

8. 11u Functional Architecture
November 2005
doc.: IEEE /1062r0
November 2005
11u Functional Architecture AP
STA
Gateway AS DS
DS is a logical entity – could be a layer 2 network, or could use encapsulation within IP.
Mike Moreton, STMicroelectronics
Mike Moreton, STMicroelectronics

9. A Modified 11u Architecture
November 2005
A Modified 11u Architecture AS
STA AP DS
Gateway
STA AP
Mike Moreton, STMicroelectronics

10. A Modified 11u Architecture
November 2005
A Modified 11u Architecture
Major purpose of AP is to create a tunnel between the STA and the Gateway
Operators don’t trust the AP or the DS, so don’t rely on them for too much
Authentication is between the STA and the Gateway
It’s really nothing to do with the access network. Why should it get involved?
Encryption is tunnelled through to the Gateway
Passing security information to the AP can be considered a possible attack opportunity, so why ask it to do the decryption?
Data is protected across the DS
Mike Moreton, STMicroelectronics

11. Isn’t This a Bit Radical?
November 2005
Isn’t This a Bit Radical?
This is a model, not an implementation
Implementers can distribute the Gateway function across the APs if they wish. How they make that work is an implementation decision.
It’s Backwards Compatible
The idea is that an AP would support this access mechanism in addition to more conventional mechanisms
Mike Moreton, STMicroelectronics

12. How Does This Fit in With CAPWAP?
November 2005
How Does This Fit in With CAPWAP?
CAPWAP is proposing an architecture where the functionality of an AP is split between different devices
This is really very similar
Though the requirement to perform encryption in the gateway is slightly different
Maybe we should assume CAPWAP (or something similar) as a pre-requisite for 11u?
Mike Moreton, STMicroelectronics