1 / 18

Waiver Request for IEEE.RAC Coordination Comments in P802.11aq

This document is a waiver request for not satisfying the mandatory coordination comments received from IEEE RAC during the P802.11aq sponsor ballot. The P802.11aq BRC requests a waiver for the specific comments listed in the document.

sizemorej
Download Presentation

Waiver Request for IEEE.RAC Coordination Comments in P802.11aq

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. P802.11aq Waiver request regarding IEEE RAC comments Date: 2018-01-09 Authors: Stephen McCann, BlackBerry

  2. Abstract Waiver request for not satisfying the mandatory coordination comments received from the IEEE RAC during the P802.11aq sponsor ballot Stephen McCann, BlackBerry

  3. The P802.11aq ballot resolution committee (BRC) has decided that satisfying the mandatory coordination comments received from the IEEE RAC impedes the utility of the P802.11aq amendment**. Therefore the P802.11aq BRC requests a waiver from satisfying the mandatory coordination comments. • These specific comments from the P802.11aq sponsor ballot are as follows: • r03-8 (9008) • r04-8 (10008) • r04-9 (10009) • r04-12 (10012) • r05-5 (11005) [references r04-9] • r05-6 (11006) [references r04-8] • r05-7 (11007) [references r04-12] • r06-9 (12009) • As detailed in the comment resolution spreadsheet tab “IEEE RAC Comments” ** IEEE-SA Standards Board Operations Manual: (Dec 2016) section 4.2.3.2 Stephen McCann, BlackBerry

  4. The following 8 slides summarize the specific MCCs. These summaries have been produced by the P802.11aq BRC to the best of their ability. • Each slide is formatted as follows: • Original MCC received from IEEE RAC • Original BRC comment resolution as provided by the P802.11aq BRC at the time of the re-circulation sponsor ballot • Current BRC commentary based the current state of the P802.11aq draft. This may differ from the original P802.11aq comment resolution, due to subsequent changes made to the P802.11aq draft Stephen McCann, BlackBerry

  5. Comment summary of r03-8 (9008) • Original MCC: • Random MAC address assignment would seem to be out-of-scope for the PAR • Original BRC Response summary: • Rejected • Randomizing the MAC address, as described in P802.11aq clause 12.2.10, is a perfectly reasonable part of the pre-association discovery scope. This avoids revealing privacy compromising information to STAs that are observing the P802.11aq traffic. • Current BRC commentary: • tbd Stephen McCann, BlackBerry

  6. Comment summary of r04-8 (10008) I • Original MCC: • 11aq specifies that devices select a 48-bit MAC address using 46 bits selected randomly (the other two set to indicate local unicast), whereas IEEE Std 802 (since the June 2017 approval of the amendment IEEE Std 802c) provides for four types of local addresses, and the random use of 46 bits will likely cause collisions with this allocation scheme. Further 44 bits is a large enough space. • Original BRC Response summary: • Revised • The P802.11aq draft behavior has been changed to allow a STA to conform to a local administered address space policy when it associates to a network. • The maximum number of bits of randomization for the MAC is beneficial to address privacy issues associated with network discovery when the STA is in the unassociated state. • Note: see also response summary to r05-6 Stephen McCann, BlackBerry

  7. Comment summary of r04-8 (10008) II • Current BRC commentary: • tbd Stephen McCann, BlackBerry

  8. Comment summary of r04-9 (10009) I • Original MCC: • There is nothing in the project scope to inform interested parties that the amendment will include specifications that present potential interoperability problems with many other standards that use IEEE Std 802 specified addressing • Original BRC Response summary: • Revised • Changes were made to the P802.11aq draft to make the device manageable at layer-2. Privacy enhancements may be required to perform pre-association service discovery. The draft has been modified to minimize the addressing conflicts suggested by the comment. • Any managed network will need to separate unmanaged devices from that network. This can easily achieved with a router, or alternatively enterprise class access points, which can separate devices that they know how to provision, as opposed to those that they can not. Any necessary isolation of the unmanaged devices, can be achieved through such a router. It is the responsibility of the network administrator to configure the network to provide these properties. • Note: see also response summary to r05-5 Stephen McCann, BlackBerry

  9. Comment summary of r04-9 (10009) II • Current BRC commentary: • tbd Stephen McCann, BlackBerry

  10. Comment summary of r04-12 (10012) I • Original MCC: • The draft is incompatible with IEEE Std 802-2014 because it doesn't allow for the local administrator administering the local addresses • Original BRC Response summary: • Revised • Privacy enhancements may be required to perform pre-association service discovery. The P802.11aq draft has been modified to eliminate the addressing conflicts suggested by the comment and allow for the STA to be configured in a mode consistent with a locally administered address space policy. • A managed network would not expect to connect to an unmanaged access network, as it would typically connect via a router. A managed network might connect directly to an access network of enterprise (managed) APs. Those APs would refuse to admit STAs that did not provide management of the local address space. • Note: see also response summary to r05-7 Stephen McCann, BlackBerry

  11. Comment summary of r04-12 (10012) II • Current BRC commentary • tbd Stephen McCann, BlackBerry

  12. Comment summary of r05-5 (11005) • Original MCC: • The RAC is not satisfied with the response to Comment r04-9 (slide #8). However, considering the scope of the project, per the PAR, it seems apparent that specifying a new method to assign LAN data frame addresses is out of scope • Original BRC Response summary: • Rejected • The P802.11aq draft does not specify a new method. It incorporates by reference IEEE 802-2014 and IEEE 802c-2017. • Current BRC commentary • tbd Stephen McCann, BlackBerry

  13. Comment summary of r05-6 (11006) I • Original MCC: • The RAC is not satisfied with the response to Comment r04-8 (slide #6). During the discovery process, the draft still specifies that station adopts a 46-bit random address • Original BRC Response summary: • Rejected • In the pre-associated state, the only communication is between STAs. Frames transmitted between a STA and an AP terminate at the AP and never reach the LAN. Security and duplication detection mechanisms prevent frames from a non-associated STA with a conflicting MAC address from affecting any traffic in the BSS. The P802.11aq draft does not specify any number of bits, as it refers to IEEE 802-2014 and IEEE 802c-2017. Stephen McCann, BlackBerry

  14. Comment summary of r05-6 (11006) II • Current BRC commentary • tbd Stephen McCann, BlackBerry

  15. Comment summary of r05-7 (11007) I • Original MCC: • The RAC is not satisfied with the response to Comment r04-12 (slide #10). The RAC would prefer a direct control functionality by which the network could specify a local address plan and policy. The current draft instead proposes a MIB-based solution without specifying any method to establish the relevant parameter • Original BRC Response summary: • Rejected • The method used to choose MAC addresses is performed using a MIB variable. This MIB variable can be set by a management agent such as an out-of-band provisioning protocol, for example: Passpoint, using an USB connection. • The MIB variable is the layer-2 part of a mechanism for management that needs additional support from the provisioning protocol. This is no different to the wired case, in that routers are configured through a proprietary management interface. Stephen McCann, BlackBerry

  16. Comment summary of r05-7 (11007) II • Current BRC commentary: • tbd Stephen McCann, BlackBerry

  17. Comment summary of r06-9 (12009) I • Original MCC: • The RAC remains unsatisfied with the responses to unresolved RAC Mandatory Coordination comments. RAC believes all remaining Mandatory Coordination issues can best be satisfied by deleting all references and specifications in the draft to use of random MAC addresses • Original BRC Response summary: • Revised • The P802.11aq draft has been modified to specify that the STA select a random address from the local address space according to IEEE 802-2014 and IEEE 802c-2017 while in the unassociated state. When the device selects a AP (BSS) for association, the STA checks the value for dot11LocallyAdministeredMACConfig and sets its MAC address according to the MAC address policy set by the Network Administrator for the BSS. Therefore a STA with MAC privacy enabled selects a random address compliant with IEEE 802c-2017 in the unassociated state and uses the Local Address configuration for a BSS once it associates to that BSS. Stephen McCann, BlackBerry

  18. Comment summary of r06-9 (12009) II • Current BRC commentary: • tbd Stephen McCann, BlackBerry

More Related