Peer link Set-up and Maintenance

Slides:



Advertisements
Similar presentations
Doc.: IEEE s Submission February 2007 Jan Kruys e.a. Cisco SystemsSlide 1 Peer link Set-up and Maintenance Notice: This document has.
Advertisements

June 2005 doc.: IEEE /0593r0 July 2005 Summary Presentation Proposal L:19 Siemens Proposal for WLAN Mesh Networking Date: Authors:
Use of KCK for TGr Management Frame Protection
[ Interim Meetings 2006] Date: Authors: July 2005
TCP Parameters and Settings
IEEE WG Status Report – July 2005
London TGu Motions Authors: January 2007 Date: Month Year
LB73 Noise and Location Categories
LB73 Noise and Location Categories
Waveform Generator Source Code
TGu Closing Report Date: Authors: November 2005
Mesh Frame Types & Subtypes
TGp Closing Report Date: Authors: July 2007 Month Year
Attendance and Documentation for the March 2007 Plenary
TGr Architectural Entities
Enhanced Direct Link Setup in nDLS
3GPP liaison report May 2006 May 2006 Date: Authors:
Motion to accept Draft p 2.0
Protected SSIDs Date: Authors: March 2005 March 2005
3GPP liaison report July 2006
[place presentation subject title text here]
JTC1 Ad Hoc Closing Report
Fast Transition Mobility (FTM) Domain
TGp Motions Date: Authors: November 2005 Month Year
TGp Closing Report Date: Authors: March 2006 Month Year
On Coexistence Mechanisms
TGu-changes-from-d0-02-to-d0-03
TGp Closing Report Date: Authors: May 2007 Month Year
Self-organizing and Auto-configuring Mesh Networks
AP Location Capability
Diagnostics and Troubleshooting
JTC1 Ad Hoc Mid-week Report
On Coexistence Mechanisms
TGp Closing Report Date: Authors: March 2006 Month Year
March 2007 doc.: IEEE /0389r0 March 2007
Reflector Tutorial Date: Authors: July 2006 Month Year
TGv Redline D0.07 Insert and Deletion
TGv Redline D0.06 Insert and Deletion
ADS Study Group Mid-week Report
DLS Link Timeout Date: Eunkyo Kim
IEEE P Wireless RANs Date:
TGu-changes-from-d0-01-to-d0-02
RFI Update Munich Meeting
LB73 Noise and Location Categories
IEEE “ Requirements” Date: Authors:
TGy draft 2.0 with changebars from draft 1.0
TGv Redline D0.10 Insert and Deletion
Suggested comment resolution on ATIM window parameter
WAPI Position Paper Sept 2005 Sept 2005 IEEE WG
Redline of draft P802.11w D2.2 Date: Authors:
TGr Proposed Draft Revision Notice
TGu-changes-from-d0-02-to-d0-03
May 2005 CAPWAP AHC Closing Report
Remedy for beacon bloat
Beamforming and Link Adaptation Motions
Questions to the Contention-based Protocol (CBP) Study Group
Motion to go to Letter Ballot
EC Motions – July 2005 Plenary
TGu-changes-from-d0-04-to-d0-05
Location Capability Negotiation
Transition Nowhere Date: Authors: Sept 2005 Sept 2005
TGu-changes-from-d0-03-to-d0-04
TGu Motions Date: Authors: May 2006 May 2006
RFI Update Munich Meeting
RFI Update Munich Meeting
MAC Address Spoofing in Mesh
WAPI Position Paper Sept 2005 Sept 2005 IEEE WG
Use of KCK for TGr Management Frame Protection
Use of KCK for TGr Management Frame Protection
TGp Motions Date: Authors: January 2006 Month Year
Presentation transcript:

Peer link Set-up and Maintenance Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2007 Peer link Set-up and Maintenance Date: 2007-02-07 Authors: Notice: This document has been prepared to assist IEEE 802.11. 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 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// 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 <stuart.kerry@philips.com> 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. Jan Kruys e.a. Cisco Systems John Doe, Some Company

Abstract Peer links are a basic building block of any mesh network Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2007 Abstract Peer links are a basic building block of any mesh network So far we have re-used the Association of the baseline protocol see draft D.1 We have discussed the need for a true peer link set-up protocol that is robust, fast and secure That combination proves a tough nut to crack but we are working on it We have not discussed how we monitor a link and terminate it in an orderly manner That is the subject of this presentation Jan Kruys e.a. Cisco Systems John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2007 Taking a step back Mesh networks are assumed to adapt to changes in environment and/or traffic demands That implies their connections change over time To determine who to link up with a mesh node must have some basic data about other nodes: Mesh ID, Capabilities, protocol, etc, all data are provided in beacons and probes – overhead, but a necessary one The peer link set-up process uses the above to find candidate peer nodes The peer link set up process determines if a candidate becomes a real peer Peer link set up is relative slow and costly in terms of overhead The “assett” of a peer link merits close monitoring to avoid unnecessary re-establishment Jan Kruys e.a. Cisco Systems John Doe, Some Company

Phases in the life of a peer link instance Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2007 Phases in the life of a peer link instance Set-up Starts from nothing Uses full EMSA handshake or abbreviated EMSA handshake Results in a secure link or nothing… Operation Supports secure frame transmission Does self-monitoring in the absence of traffic Close Assures orderly termination under all conditions Jan Kruys e.a. Cisco Systems John Doe, Some Company

Peer Discovery, example Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2007 Peer Discovery, example B B B B B B A B Beacon/Probe Response B Mesh ID, Capability, etc + PMK & Cipher Suite Information A collects information about other mesh members and decides to which to peer with Jan Kruys e.a. Cisco Systems John Doe, Some Company

(Abbreviated) Peer link set-up, example Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2007 (Abbreviated) Peer link set-up, example A B Open(ANonce, PMKInfo, Cipher Suite Info, GTK1, MIC) Open(BNonce, PMKInfo, Cipher Suite Info, GTK2, MIC) Confirm(BNonce||ANonce, PMKInfo, Cipher Suite Info, MIC) Confirm(ANonce||BNonce, PMKInfo, Cipher Suite Info, MIC) The result is An identifiable, bi-directional set of secure unicast “connections” between A and B (Link-ID = ANonce||BNonce) A secure broadcast “connection” from A to B (and all MPs with which it has set-up a peer link) Jan Kruys e.a. Cisco Systems John Doe, Some Company

Peer link Operation …is used for all frame exchanges between peers Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2007 Peer link Operation …is used for all frame exchanges between peers Unicasts from A>>B and B>>A For data transport and some management functions Broadcasts from A>>all-peers-of-A For some routing functions For some management functions Broadcasts from all-peers-of-A>>A …Is self-monitoring to assure continuity in the absence of traffic and routing frames Using unicast or broadcasts of “Thumbs-up” management frame Unicast is more efficient for a small number of peers Failure of peers to respond leads to termination of Link Operation through Peer Link Close and, eventually to a new Peer Link Set-up Jan Kruys e.a. Cisco Systems John Doe, Some Company

Peer link Close Attempts to orderly close a peer to peer link Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2007 Peer link Close Attempts to orderly close a peer to peer link By de-activation of the link instance using a secure unicast Non-protected unicast creates an opportunity for DoS attacks Peer responds with a Close “confirmation” Absence of a response within “Close time out” causes A to assume that the link instance is inactive A B Close (Link-ID, ANonce’,MIC) Close(Link-ID, BNonce’,MIC) Jan Kruys e.a. Cisco Systems John Doe, Some Company

High Level Peer Link Instance State Machine Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2007 High Level Peer Link Instance State Machine Set-up Close Operation Two-way CONFIRM OPEN or CONFIRM time-out THUMBS-UP Time out Two-way CLOSE or CLOSE time-out OPEN, OPEN time-out, etc Two-way THUMBS-UP Note: operationally, there is no need for an idle state: if there is no need to set up a link, there is no mesh, etc Jan Kruys e.a. Cisco Systems John Doe, Some Company

Another look at Thumbs-up Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2007 Another look at Thumbs-up Each side sends T-up at T_up_interval and keeps a T_up _timer (> T_up_interval) miss n in a row and you are assumed to be lost T_up_interval can be varied with traffic density No need to respond: can be broadcast or unicast Unicast under a TxOP allows immediate response if desirable Each instance is new - assures no spoofing is possible A B Thumbs-up (Link-ID, ANonce’,MIC) Thumbs-up (Link-ID, BNonce’,MIC) Jan Kruys e.a. Cisco Systems John Doe, Some Company

Context for the Link Instance State Machine Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2007 Context for the Link Instance State Machine New Peer Discovered or Open from peer while enabled causes an new instance to be created Set-up Close Operation Two-way CONFIRM OPEN or CONFIRM time-out THUMBS-UP Time out OPEN, OPEN time-out, etc Idle Two-way CLOSE or CLOSE time-out causes the instance to be terminated ??? out of scope for peering protocol THUMBS-UP received “Disable Mesh/Mesh Link ”command The link state machine is an instance that is created by events external to it and that disappears when there is no connection Jan Kruys e.a. Cisco Systems John Doe, Some Company

Link Process Description – Unilateral actions Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2007 Link Process Description – Unilateral actions If a link to some MP is needed, send an Open with a new Local L.ID The target MP is provided by Discovery or another function within the MP – that part is out of scope here. If a secure link has been set up, each, MP may want to send probes (Thumbs-up) to the other end to make sure it is still there. A Link-_time_out timer will catch link failures in the absence of any traffic between the nodes Jan Kruys e.a. Cisco Systems John Doe, Some Company

Basic Peer Link Set-up- Responder Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2007 Basic Peer Link Set-up- Responder Case Current State Received Content Action 1 Idle Triggered by external event New L.ID = Active L.ID state = Open 2 Open Open (Active L.ID = Peer L.ID) Process other variables 3 Open (Active L.ID = Peer L.ID +Peer Local L.ID) Process other variables, state = Confirm 4 Time-out Drop Active L.ID state = Idle 5 Confirm Confirm (Active L.ID = Peer L.ID +Peer Local L.ID) 6 Process other variables, state =Monitor 7 Drop L.ID & Peer ID state = Idle Jan Kruys e.a. Cisco Systems John Doe, Some Company

Basic Link Monitor & Close - Responder Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2007 Basic Link Monitor & Close - Responder Case Current State Content Action 1 Monitor Any with invalid MIC Ignore 2 Probe (Active L.ID = Peer L.ID +Peer Local L.ID) Restart protective link probe timer 3 Close (Active L.ID = Peer L.ID +Peer Local L.ID) or Close_time_ out Send Close, state = Close 4 Anything else Close Close (Active L.ID = Peer L.ID +Peer Local L.ID) or Close_ time_out State = Idle Open (new Peer L.ID) New L.ID = Active L.ID Set Local L.ID, state = Open Jan Kruys e.a. Cisco Systems John Doe, Some Company

Adding Security January 2007 Sync Link IDs Perform 802.1X exchange Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2007 Adding Security Parameters external to the Link Process determine the security details of the Set-up phase Abbreviated EMSA handshake Set-up Close Operation Two-way CONFIRM OPEN or CONFIRM time-out THUMBS-UP Time out OPEN, OPEN time-out, etc Sync Link IDs and GTKs Validate possession of PMK Sync Link IDs Validate possession of PMK (4-way hsk) Sync Link IDs Validate possession of PMK Perform 802.1X exchange Perform MKD exchange Full 802.1X handshake EMSA “get key” handshake Jan Kruys e.a. Cisco Systems John Doe, Some Company

Peer Link Set-up with Full EMSA handshake Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2007 Peer Link Set-up with Full EMSA handshake Case Current Link State Content Action 3a Open/c Active L.ID = Peer L.ID +Peer Local L.ID, Authenticate: start 802.1X exchange, etc) Process other variables, if authentication complete: state = Confirm, send Confirm (802.1X exchange and first 2 of 4-way handshake) 5a Confirm Confirm (Active L.ID = Peer L.ID +Local L.ID) **) Process other variables 6a Confirm (Active L.ID = Peer L.ID + Local L.ID …MIC) **) Process other variables, state =Monitor **) Ideally these two should look like the last two of the 4way handshake Jan Kruys e.a. Cisco Systems John Doe, Some Company

Peer Link Set-up with Abbr. EMSA handshake Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2007 Peer Link Set-up with Abbr. EMSA handshake Case Current Link State Content Action 3b Open (Active L.ID = Peer L.ID +Peer Local L.ID… GTK, MIC, etc) Process other variables, if GTK is ok: state = Confirm, send Confirm 5a Confirm Confirm (Active L.ID = Peer L.ID +Local L.ID) Process other variables 6a Confirm (Active L.ID = Peer L.ID + Local L.ID …MIC) Process other variables, state =Monitor Jan Kruys e.a. Cisco Systems John Doe, Some Company

Impact on the draft January 2007 Re-sequence to improve accessibility: Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2007 Impact on the draft Re-sequence to improve accessibility: A11.1 Mesh Intro Mesh Membership / Mesh ID Channel Selection Default Mesh metric Default Wireless Mesh Routing Protocol Default Mesh Security (EMSA = Efficient Mesh Security Architecture) Extensibility A11.2 Interworking A11.3 Peer Link Control Procedures Discovery Set-up – invokes EMSA security Monitor Close A11.4 [Route] Selection and Forwarding A11.5 HWMP Jan Kruys e.a. Cisco Systems John Doe, Some Company

The bigger picture: Mesh Services Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2007 The bigger picture: Mesh Services Discovery Allows MPs to find others MPs and their roles Peer Link Control Uses information provided by the Discovery Service Allows MPs to set up, maintain and close secure links between MPs that are considered neighbours according to some criteria Transport Gets the bits across a link between two neighbour MPs that have joined the mesh (using the Formation Service) Routing Creates routes to destinations inside or outside the mesh – uses the Transport Service Forwarding Delivers bits across the mesh using the Transport Service Jan Kruys e.a. Cisco Systems John Doe, Some Company

Relationships of Mesh Services Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2007 Relationships of Mesh Services 802.11 Mesh MAC User (LLC) Forwarding Service Routing Service 802.11 Layer Management Transport Service Peer Link Control Discovery Service Basic 802.11 MAC Services Jan Kruys e.a. Cisco Systems John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2007 Summary Mesh Link processes cover three phases: set-up, monitor and close Adding security does not change this – EMSA (full and abbrev.) can be incorporated into the set-up phase The three possible cases: full 802.1X, MKD key pull and abbreviated handshake can be performed as part of the peer link open/confirm process By separating out link monitor and link close, the whole process can be made more easily understood and the state machine simplified The context in which this process operates can be mapped to the infamous/abstract MLME interface With a bit of restructuring, the mesh part of the Amendment can be made easier to understand and apply. Jan Kruys e.a. Cisco Systems John Doe, Some Company