Mesh Security Goals and Requirements

Mesh Security Goals and Requirements
Month Year doc.: IEEE yy/xxxxr0 March 2006 Mesh Security Goals and Requirements 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 Jesse Walker (Intel) et al John Doe, Some Company

Month Year doc.: IEEE yy/xxxxr0 March 2006 Abstract This submission summarizes security goals and requirements for a mesh network Jesse Walker (Intel) et al John Doe, Some Company

Agenda Analysis of PAR Security Clause Problem Statement
Month Year doc.: IEEE yy/xxxxr0 March 2006 Agenda Analysis of PAR Security Clause Problem Statement Mesh Security Goals Usage Models Revisited What’s Missing? Jesse Walker (Intel) et al John Doe, Some Company

Month Year doc.: IEEE yy/xxxxr0 March 2006 From the PAR… Clause 19 “Additional Explanatory Notes”: “An IEEE Extended Service Set (ESS) Mesh* is a collection of Access Points (APs) interconnected with wireless links that enable automatic topology learning and dynamic path configuration. The proposed amendment shall be an extension to the IEEE MAC (Medium Access Control). The amendment will define an architecture and protocol for providing an IEEE ESS Mesh using the IEEE MAC to create an IEEE Wireless Distribution System that supports both broadcast/multicast and unicast delivery at the MAC layer using radio-aware metrics over self-configuring multi-hop topologies. An ESS Mesh is functionally equivalent to a wired ESS, with respect to the Stations (STAs) relationship with the Basic Service Set (BSS) and ESS. The amendment shall enable interoperable formation and operation of an ESS Mesh, but shall be extensible to allow for alternative path selection metrics and/or protocols based on application requirements. A target configuration is up to 32 devices participating as Access Point (AP) forwarders in the ESS Mesh. However, larger configurations may also be contemplated by the standard. It is intended that the architecture defined by the amendment shall allow an ESS Mesh to interface with higher layers and to connect with other networks using higher layer protocols. The amendment shall utilize IEEE i security mechanisms, or an extension thereof, for the purpose of securing an ESS Mesh in which all of the APs are controlled by a single logical administrative entity for security. The amendment shall allow the use of one or more IEEE radios on each AP in the ESS Mesh. Jesse Walker (Intel) et al John Doe, Some Company

Analysis of PAR Security Clause
Month Year doc.: IEEE yy/xxxxr0 March 2006 Analysis of PAR Security Clause “…utilize IEEE i security mechanisms, or an extension thereof, for the purpose of securing an ESS Mesh in which all of the APs are controlled by a single logical administrative entity for security” Clause assumes i or an extension thereof is sufficient for “securing an ESS Mesh” Clause doesn’t define what “securing an ESS Mesh” means PAR identifies security in terms of the AP role, but Joint Proposal defines more roles than AP, leaving a gap The AP role implies auxiliary roles not defined by the Joint Proposal Jesse Walker (Intel) et al John Doe, Some Company

Month Year doc.: IEEE yy/xxxxr0 March 2006 Analysis of PAR Security Clause “…utilize IEEE i security mechanisms, or an extension thereof” 802.11i prevents unauthorized devices from directly sending and receiving traffic via the medium An extension to i may be required, because 802.11i uses 802.1X for authentication Many people have expressed reservations about i’s use of 802.1X for ad hoc authentication Mesh formation involves more than just authentication and link authorization, which is all 802.1X was designed to solve 802.11i does not have a way to protect routing and forwarding Jesse Walker (Intel) et al John Doe, Some Company

Month Year doc.: IEEE yy/xxxxr0 March 2006 Analysis of PAR Security Clause “an ESS Mesh in which all of the APs” The Joint Proposal defines the following in addition to Mesh APs (MAPs) Mesh Points – mesh nodes that are not APs but that forward and route Light-Weight Mesh Points (LWMPs) – non-AP mesh nodes that do not route and do not forward transit frames Mesh Portals – (MPPs) MPs that provide routes to destinations external to the mesh What does it mean to “secure” these roles? Jesse Walker (Intel) et al John Doe, Some Company

Mesh Primary Functions*
Month Year doc.: IEEE yy/xxxxr0 March 2006 Mesh Primary Functions* Transport – Carry application (non-mesh) data between mesh neighbor devices Internal Routing – Establishes forwarding paths between mesh devices External Routing – Establishes forwarding path(s) to devices external to the mesh Forwarding – Transmits received frames originated by another device Access Point – Allows STAs to connect to a mesh via an AP * Alternate definitions for Transport and Forwarding in Backup Jesse Walker (Intel) et al John Doe, Some Company

Mapping Roles to Services
Month Year doc.: IEEE yy/xxxxr0 March 2006 Mapping Roles to Services MAP  Transport + Internal Routing + Forwarding + Access Point MPP  Transport + Internal Routing + Forwarding + External Routing MP  Transport + Internal Routing + Forwarding LWMP  Transport Jesse Walker (Intel) et al John Doe, Some Company

Problem Statement Securing a mesh means March 2006
Month Year doc.: IEEE yy/xxxxr0 March 2006 Problem Statement Securing a mesh means Securing the Transport function: Prevent unauthorized devices from directly sending or receiving traffic via the mesh Securing the Internal Routing function: Prevent or detect unauthorized devices from participating in internal routing protocols Securing the External Routing function: Prevent or detect unauthorized devices from participating in external routing protocols, i.e., set up forwarding tables to destinations external to the mesh Securing Forwarding: Prevent or detect when unauthorized devices forward mesh data frames Securing the AP function: Prevent or detect unauthorized devices from offering the Access Point function with the mesh Mesh Formation: Prevent mesh devices from establishing unauthorized mesh services with other devices Jesse Walker (Intel) et al John Doe, Some Company

Digression: Generic Service Model
Month Year doc.: IEEE yy/xxxxr0 March 2006 Digression: Generic Service Model Disabled Discovering Disabling Accessing Graceful Shutdown Accessed Jesse Walker (Intel) et al John Doe, Some Company

Month Year doc.: IEEE yy/xxxxr0 March 2006 Transport Security Security Goal: Prevent unauthorized devices from directly sending and receiving traffic via the mesh Transport Security by the Generic Model: Disabled: Do not advertise or respond to this mesh Discovering: Advertise this mesh; Search for other devices offering this mesh Accessing: Verify peer is authorized to use the transport Accessed: Accept forgery-protected frames from peer; discard other frames from peer; Send forgery protected frames to peer Disabling: Notify authorized peer in a forgery-protected way when removing a link to it Jesse Walker (Intel) et al John Doe, Some Company

Internal Routing Security
Month Year doc.: IEEE yy/xxxxr0 March 2006 Internal Routing Security Security Goal: Prevent unauthorized devices from routing internally or detect they are trying to do so Internal Routing Security by the Generic Model: Disabled: Do not initiate or respond to internal routing messages for this mesh Discovering: Advertise ability to route internally within this mesh; Search for other devices offering to route internally within this mesh Accessing: Verify discovered internal routing node has the right to do so Accessed: Initiate and respond to (end-to-end) forgery-protected route requests and responses to and from devices authorized to route internally; discard other internal routing frames Disabling: Generate forgery-protected notification to internal routing nodes when terminating internal routing; Delete routing cache entries in response to forgery-protected notification Jesse Walker (Intel) et al John Doe, Some Company

External Routing Security
Month Year doc.: IEEE yy/xxxxr0 March 2006 External Routing Security Security Goal: Prevent unauthorized devices from building routes to external networks or detect when they are doing so External Routing Security by the Model: Disabled: MPP: Do not initiate external routing tree for this mesh. Other: Do not respond to messages building external routing tree for this mesh. Discovering: MPP: Advertise ability to route externally from this mesh. Other: Search for candidate MPPs offering to route to destinations external to this mesh Accessing: MPP: Verify other nodes are authorized to route (internally or externally). Other: Verify alleged MPP is authorized to be an MPP Accessed: MPP: Build and maintain external routing tree. Other: For messages to external destinations, build and maintain internal route to tree root Disabling: MPP: Generate forgery-protected notification to internal routing peers when terminating external routing. Other: Delete routing cache entries in response to forgery-protected notification Jesse Walker (Intel) et al John Doe, Some Company

External Routing Security
Month Year doc.: IEEE yy/xxxxr0 March 2006 External Routing Security Bridge or Router Mesh Portal Layer 2 LAN Segment Layer 2 LAN Segment .11s Mesh #1 .11s Mesh #2 Jesse Walker (Intel) et al John Doe, Some Company

Month Year doc.: IEEE yy/xxxxr0 March 2006 Forwarding Security Security Goal: Prevent unauthorized devices from forwarding frames, or detect when they do Forwarding Security by the Model: Disabled: Do not accept frames to forward for this mesh; Do not advertise forwarding Discovering: Advertise forwarding capability for this mesh; Search for other devices offering to forward in this mesh Accessing: Verify alleged forwarder is authorized to do so Accessed: Accept forgery-protected forwarded frames (3- or 4-address format) only from mesh neighbors whose right to forward has been verified; Transmit forgery-protected received frames for other destinations, provided a route exists; discard other 3- or 4-address formats Disabling: Generate forgery-protected notification when terminating forwarding; Delete affected routes in response to forgery-protected notification of forwarding termination Jesse Walker (Intel) et al John Doe, Some Company

Month Year doc.: IEEE yy/xxxxr0 March 2006 Access Point Security Security Goal: Allow only authorized mesh devices to offer the AP function or detect when unauthorized devices do so Access Point Security by the Model Disabled: STA: Do not advertise AP beacons or respond to Probe Requests for this mesh Discovering: Search for AS Accessing: Establish security association with AS. Accessed: Exchange forgery-protected messages with the AS to authenticate and authorize classical i STAs Disabling: Notify the AS of shutdown in a forgery-protected way; respond to AS shutdowns by halting new AP service Jesse Walker (Intel) et al John Doe, Some Company

Mesh Formation Security
Month Year doc.: IEEE yy/xxxxr0 March 2006 Mesh Formation Security Security Goal: Prevent mesh devices from establishing unauthorized mesh services with other devices Mesh Formation Security by the Generic Model: Disabled: Do not initiate association messages to nodes in this mesh or accept association messages from nodes in this mesh Discovering: Advertise ability to accept associations for this mesh; Active and/or passive scan to discover neighbor mesh nodes Accessing: Initiate association with a mesh node advertising itself as a member of the mesh or verify that a peer mesh node is authorized to associate Accessed: Build and maintain associations with peer mesh nodes Disabling: Disassociate from mesh; delete security context for peer mesh nodes Jesse Walker (Intel) et al John Doe, Some Company

Mesh Formation or Bootstrap
Month Year doc.: IEEE yy/xxxxr0 March 2006 Mesh Formation or Bootstrap Mesh formation supports the other primary mesh functions Primary functions are not useful without discovery and accessing states Chicken-and-Egg problem The accessing step for (internal and external) routing and forwarding require verification that peers have these rights Verification which depends on the routing and forwarding services of the peer being verified must not result in false positives This suggests authentication/authorization options available during mesh formation are limited On-line “trusted third party” (e.g., an 802.1X AS external to the MP, LWMP, MAP, MPP) may be applicable in only some usage models Jesse Walker (Intel) et al John Doe, Some Company

Speculation on Usage Models
Month Year doc.: IEEE yy/xxxxr0 March 2006 Speculation on Usage Models 802.11s usage models are Peer-to-peer ad hoc (1-hop meshes) Home mesh networks Metropolitan public mesh networks Enterprise meshes Emergency Response Military Jesse Walker (Intel) et al John Doe, Some Company

Speculation on Peer-to-Peer Ad Hoc Security
Month Year doc.: IEEE yy/xxxxr0 March 2006 Speculation on Peer-to-Peer Ad Hoc Security Since 1-hop networks require no routing, forwarding, APs, or portals, we conjecture that Transport security is all that is required to enable this market segment The experience with i suggests security will not be enabled in Peer-to-Peer Ad Hoc networks until the credentials provisioning problem is solved It remains to see whether efforts such as Wi-Fi Alliance Simple Config will “solve” this problem. The credentials provisioning problem is outside the scope of s, , and all 802 WGs Jesse Walker (Intel) et al John Doe, Some Company

Speculation on Home Mesh Network Security
Month Year doc.: IEEE yy/xxxxr0 March 2006 Speculation on Home Mesh Network Security Experience with suggests consumers will deploy home mesh networks regardless of security or its lack Experience also suggests the analysts will criticize a security-less s mercilessly, so security will eventually be used as a purchasing criteria Experience with i suggests consumers will not enable security until the credentials provisioning problem is solved This suggests that security is not necessary initially to enable this market, but that a full solution will eventually be necessary, and should be provided or anticipated by s Jesse Walker (Intel) et al John Doe, Some Company

Month Year doc.: IEEE yy/xxxxr0 March 2006 Speculation on Metropolitan Public and Enterprise Mesh Network Security Experience suggests the only technology difference between the two is the credentials provisioning model, which is outside the scope of s, , and all 802 WGs Pre i experience suggests Enterprises and will deploy meshes broadly only when they can secure all mesh functions Pre i experience suggests Service Providers will refuse to deploy meshes broadly without closing off mesh roles (routing, forwarding, AP, portal) to outsiders This suggests these market segments require solutions to their security problems raised to succeed We don’t know yet which security features these markets will care about But has the market asked for a standardized solution for metropolitan meshes? Jesse Walker (Intel) et al John Doe, Some Company

Speculation on Emergency Response and Military Mesh Network Security
Month Year doc.: IEEE yy/xxxxr0 March 2006 Speculation on Emergency Response and Military Mesh Network Security Emergency Response or Military have specified no unique security requirements beyond the needs of Metropolitan or Enterprise However, experience suggests they may have unique security requirements 802.11s cannot address the unique security requirements before Emergency Response and Military are articulated Jesse Walker (Intel) et al John Doe, Some Company

Summary of Speculation on Usage Models
Month Year doc.: IEEE yy/xxxxr0 March 2006 Summary of Speculation on Usage Models Peer-to-Peer Ad Hocs appear to require only an i extension, but their security is reliant on solution of out-of-scope issues to succeed Home meshes will be deployed with or without security, but security will not be enabled without reliance on solutions to out-of-scope issues TGs can drive a consistent solution If s does not require the security functions, then security in the home will not happen Enterprise and Service Providers are unlikely to deploy meshes without solutions to all relevant problems Emergency Response and Military should make their security requirements explicit before TGs can determine how to address these market segments Jesse Walker (Intel) et al John Doe, Some Company

Three Paths Forward These slides outline lots of work
Month Year doc.: IEEE yy/xxxxr0 March 2006 Three Paths Forward These slides outline lots of work 802.11i addresses transport security requirements, not routing, forwarding, or mesh formation issues TGs must decide how much security it will provide for each usage scenario Possible Solution Spaces: Address all relevant security problems within TGs But this will likely delay final ratification Address no security problems within TGs Would require changing the PAR Address only some security problems relevant to the usage models TGs intends to enable; spin out some problems to a new TG E.g., since each class of mesh routing protocols will lead to a unique security model, form a TG to deal with each standardized routing protocol and its security. TGs must agree on which mesh functions to secure Jesse Walker (Intel) et al John Doe, Some Company

Next Steps Agree that 802.11s will define how to secure the following:
Month Year doc.: IEEE yy/xxxxr0 March 2006 Next Steps Agree that s will define how to secure the following: Transport, including formation Bring up a MAP Return in May with order-of-magnitude estimate of effort for securing the following mesh function Internal Routing External Routing Forwarding Mesh Formation Debate which of the three options TGs will take in May Jesse Walker (Intel) et al John Doe, Some Company

Month Year doc.: IEEE yy/xxxxr0 March 2006 Summary A full security solution requires that all the primary mesh functions are secured Transport Internal and external routing Forwarding AP Mesh formation Some market segments are unlikely to require a full solution to succeed (or to succeed initially) Peer-to-peer ad hoc Home Some market segments are likely to require a full solution at the outset to succeed Metropolitan networks Enterprise networks TGs should defer the decision about what to do, not do, or spin out until the May meeting Jesse Walker (Intel) et al John Doe, Some Company

Feedback? March 2006 Month Year doc.: IEEE 802.11-yy/xxxxr0
Jesse Walker (Intel) et al John Doe, Some Company

Backup March 2006 Month Year doc.: IEEE 802.11-yy/xxxxr0
Jesse Walker (Intel) et al John Doe, Some Company

Mesh Primary Function Alternate Definitions
Month Year doc.: IEEE yy/xxxxr0 March 2006 Mesh Primary Function Alternate Definitions Transport Definition – Carry application (non-mesh) data between mesh neighbor devices Alternate Transport Definition – Carry application (non-mesh) data between mesh devices or clients Forwarding Definition – Transmits received frames originated by another device Alternate Forwarding Definition – Transmits frames, whether received from another device or originated by same device The alternate definitions lead to efficient layer 3 implementations The alternate definitions are inconsistent with customary usage The alternate definitions biases discussion toward end-to-end solutions, which are available at higher layers, and which conflict with the i model for STA-to-STA traffic via an AP Jesse Walker (Intel) et al John Doe, Some Company

What’s Missing? Inside/Outside address enforcement by MPPs? What else?
Month Year doc.: IEEE yy/xxxxr0 March 2006 What’s Missing? Inside/Outside address enforcement by MPPs? External Routing Tree formation/802.1d spanning tree construction at MPP can recognize all “inside” MAC addresses An MPP could discard all forwarded frames sourced from “outside” MAC addresses received inside, and vice versa Is this important? What else? Jesse Walker (Intel) et al John Doe, Some Company

802.1X Observations 802.11i requires pre-shared keys or 802.1X AS
Month Year doc.: IEEE yy/xxxxr0 March 2006 802.1X Observations 802.11i requires pre-shared keys or 802.1X AS Case 1, PSK: Any STA can masquerade as the AP if STAs have the same pre-shared key, so PSK assumes different PSKs for each STA Case 2, AS: A mesh either it has its own AS, or else it has an MPP, or else it has no MAPs Jesse Walker (Intel) et al John Doe, Some Company

Digression: Generic Authorization Model
Month Year doc.: IEEE yy/xxxxr0 March 2006 Digression: Generic Authorization Model Party X Access Credentual Resource Controller Verify this is X No: Reject Verified Access Credential Authorization DB Authoritative Authorization Verify X may use Resource No: Reject Access Allowed Jesse Walker (Intel) et al John Doe, Some Company

Secondary Mesh Resorces
Month Year doc.: IEEE yy/xxxxr0 March 2006 Secondary Mesh Resorces Mesh Authentication Mesh Authorization Station-Mesh (802.1X) Authentication Jesse Walker (Intel) et al John Doe, Some Company

Mesh Security Goals and Requirements

Similar presentations

Presentation on theme: "Mesh Security Goals and Requirements"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Mesh Security Goals and Requirements

Similar presentations

Presentation on theme: "Mesh Security Goals and Requirements"— Presentation transcript:

Similar presentations

About project

Feedback