Mesh Security Recommendation Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 Mesh Security Recommendation Date: 2006-05-09 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>. Walker and Zhao, Intel Corporation John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 Abstract This submission summarizes provides a security recommendation to IEEE 802.11 TGs. Walker and Zhao, Intel Corporation John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 Where we are Transport and AP security appear to be well-understood problems We believe 802.11i can be readily adapted to secure transport and mesh formation We believe adding AP security into 802.11s is straight-forward Walker and Zhao, Intel Corporation John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 Where we are Security for forwarding and routing analysis has started but is not complete See doc 11-06-0672-01 by Meiyuan Zhao Technology solutions to all security issues raised by fowarding and routing do not appear to exist Every few days we discover new unsolved security problems in the forwarding and routing space These are insider attacks caused by compromise of mesh nodes Realistic because of the lack of physical security for mesh nodes External routing appears to be a research problem It may be years before we understand how to approach this problem We don’t know how long the process of understanding the space will take Walker and Zhao, Intel Corporation John Doe, Some Company

Motivating Example: Misrouting leads to looping Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 Motivating Example: Misrouting leads to looping Attack Overview Combine efforts by routing and forwarding Change the message propagation direction Message authentication can’t help! Step 1: S sends RREQ broadcast to establish a route to D Step 2: RREQ is passed on by B, A, and C Step 3: F propagates RREQ from B Step 4: A keeps this RREQ, knowing that two paths to S exist Step 5: D sends back RREP to C, then A Step 6: A forwards RREP to F Step 7: A route {S, B, F, A, C, D} is established Step 8: S sends data to D Step 9: A forwards the data to B S, 1, S S, 2, B S, 3, F D, 4, F D, 2, C S B A C D F S, 2, B D, 3, A Walker and Zhao, Intel Corporation John Doe, Some Company

Recommendation Recommend TGs to Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 Recommendation Recommend TGs to Develop mesh transport security, by adapting 802.11i to its needs Including the mesh formation aspects governed by secure link establishment Extend AP security, by defining new AP state machines, so that the AP service is only available when the AS is reachable from the AP To address issues that are only implicit in the wired infrastructure case Satisfy the PAR When the understanding of mesh routing/forwarding matures, export security for Routing and Forwarding outside of TGs Walker and Zhao, Intel Corporation John Doe, Some Company

Straw Poll TGs to follow this recommendation For: Against: May 2006 Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 Straw Poll TGs to follow this recommendation For: Against: Walker and Zhao, Intel Corporation John Doe, Some Company

Backup May 2006 Month Year doc.: IEEE 802.11-yy/xxxxr0 Walker and Zhao, Intel Corporation John Doe, Some Company

Forwarding Threats May 2006 Month Year doc.: IEEE 802.11-yy/xxxxr0 Dropping Selectively Dropping Misroute Header forgery/ modification Starvation Partition/cut Delay forwarding blackhole Instability Looping Practical limited Very limited Walker and Zhao, Intel Corporation John Doe, Some Company

Motivating Example: Misrouting leads to looping Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 Motivating Example: Misrouting leads to looping Attack Overview Combine efforts by routing and forwarding Change the message propagation direction Message authentication can’t help! Step 1: S sends RREQ broadcast to establish a route to D Step 2: RREQ is passed on by B, A, and C Step 3: F propagates RREQ from B Step 4: A keeps this RREQ, knowing that two paths to S exist Step 5: D sends back RREP to C, then A Step 6: A forwards RREP to F Step 7: A route {S, B, F, A, C, D} is established Step 8: S sends data to D Step 9: A forwards the data to B S, 1, S S, 2, B S, 3, F D, 4, F D, 2, C S B A C D F S, 2, B D, 3, A Walker and Zhao, Intel Corporation John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 Defense Ordinary message authentication scheme can’t help against this attack Root problem: no mechanism to protect information about topology These are perfectly authentic messages, I’m just not going to send them in the right direction Problem for link-state, distance vector routing protocols We need to utilize additional information Carry source route in data frame: “hey, you are not suppose to forward this data to me” Use unique sequence numbers to detect loops: “hey, I’ve forwarded this data before” Walker and Zhao, Intel Corporation John Doe, Some Company

So…possible approach (1) Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 So…possible approach (1) Source route Change routing protocol to provide source route A authentication scheme to this information from forgery A key provisioning scheme to support source route authentication Does not introduce additional vulnerabilities subject to DoS attack With source routing protocol, can we prevent the loop from being established? YES Walker and Zhao, Intel Corporation John Doe, Some Company

Possible approach (2) Sequence number approach Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 Possible approach (2) Sequence number approach Add unique sequence number to each data frame (done) Intermediate nodes and destination node should verify its uniqueness A authentication scheme on data frame header Minimize storage requirements on forwarding nodes This approach mitigate the threat consequences in terms of resource consumption But this can’t prevent looping The network is still not available for victim nodes Walker and Zhao, Intel Corporation John Doe, Some Company

Thoughts on Mesh Architecture Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 Thoughts on Mesh Architecture Packing many functions into one layer causes security problems Size of the network matters Dense, small networks seem to have fewer severe routing problems Attacks are likely to succeed in sparse, large networks Walker and Zhao, Intel Corporation John Doe, Some Company