1 / 8

Resolution Policies for Remaining Comments

Resolution Policies for Remaining Comments. Authors:. Date: 2014-01 -14. Abstract. This document describes the resolution policies for the remaining comments assigned to Hitoshi Morioka. The CIDs are 3242, 2389, 2998, 3078, 3367, 3388, 2090, 2164, 3178 and 2613. CID3242. Comment

marek
Download Presentation

Resolution Policies for Remaining Comments

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. Resolution Policies for Remaining Comments Authors: Date: 2014-01-14 Hitoshi Morioka, Allied Telesis R&D Center

  2. Abstract This document describes the resolution policies for the remaining comments assigned to Hitoshi Morioka. The CIDs are 3242, 2389, 2998, 3078, 3367, 3388, 2090, 2164, 3178 and 2613. Hitoshi Morioka, Allied Telesis R&D Center

  3. CID3242 • Comment • It is odd that the GTK is not wrapped with AES key wrap, as is done elsewhere in 802.11. While this field is covered by the AEAD encryption, best practices as defined by NIST would have the key wrapped even when covered by AEAD. • Proposed Change • Either add key wrapping or include a note as to why the GTK does not need to be key wrapped. • Resolution Policy • Add key wrapping for GTK. The key wrapping method will be imported from existing EAPOL-Key key wrapping. Hitoshi Morioka, Allied Telesis R&D Center

  4. CID2389, 2998, 3078, 3367, 3388 • Comment • These comments pointed out the lack of Annex B (PICS). • Proposed Change • Add description in Annex B. • Resolution Policy • I already presented in 11-13/1503r0 and I got feedback. • I’ll implement the feedback in the next revision. Hitoshi Morioka, Allied Telesis R&D Center

  5. CID2090, 2164, 3178 (Comments) • Comment • "The choice is determined by the STA based on what IP Address assignment methods are supported by the AP.” [CID2090]This smacks of multiple options for political rather than technical reasons. If there is genuinely no good technical reason, expect the market to be confused and support neither of them. • I really question the wisdom of doing L3 work at L2. L3 will evolve ... IPv9, IPv99. By adding these fixed fields in billions of deployed products in the wrong layer we make it VASTLY harder to upgrade the network. We run the risk of forcing the network to ossify. Related, the video I have seen for poor discovery performance without FILS (~10sec) must have used the worst DHCP server in the world since IMHO most users in most environments have a completely different & better experience; so I am not yet convinced of the technical need for this layer violation. (OK, Proxy ARP has already gone here ...) [CID2164] • "using FILS IP address assignment method" No reference to this method is provided. Assuming the intended reference is to subclause 10.44.4.2 (IP address assignment using FILS IP Address Configuration), then I have the following additional comment: as an IP address assignment protocol definition, this procedure is unnecessary and inadequate. Unnecessary because it does not differentiate itself in any way from widely implemented protocols that achieve the same purpose (DHCP and IPv6 autoaddress configuration). Inadequate because it does not address failure cases, address revocation, exchange timeouts, address renewal, conflict resolution, mobility within an ESS, etc. [CID3178] Hitoshi Morioka, Allied Telesis R&D Center

  6. CID2090, 2164, 3178 (Proposed Changes) • Proposed Change • Either justify why there are two optional methods, or make one of them mandatory.[CID2090] • Remove the encapsulated IPv4/v6 address assignment at L2 (just rely on encapsulated HLPs, or - require that ALL FILS STAs shall support the HLP encap mechanism so that IPv9 or v99 (and other-than-IP address assignment) can be supported without ANY future change to L2 devices built in 2014/15.Else, as a minimum, a) provide a survey of high density networks using properly desinged DHCP servers and show that this is a genuine problem needing an IEEE solution, and b) review this layer violation with ARCH and 802.1. [CID2164] • Remove subclauses 8.4.2.186.2, 8.4.2.186.3 and 10.44.4.2 [CID3178] Hitoshi Morioka, Allied Telesis R&D Center

  7. CID2090, 2164, 3178 (Resolution Policy) • Resolution Policy • Remove “FILS IP address configuration”. (clause 8.4.2.186.2-4, 10.44.4.2 and modify related clauses) • Because the all information carried by “FILS IP address request TLV” (8.4.2.186.2), “FILS IP address response TLV” (8.4.2.186.3) and “FILS DNS Information TLV” (8.4.2.186.4) can be carried by the higher layer packets such as DHCP, ARP, RA and NA. • By this modification, the higher layer setup method (frame format and protocol sequense) can be unified. • It will affect the resolution for CID2172, 2176 and the resolutions for removed clauses. • I discussedwith George Cherian by e-mail. But I cannot find any technical benefits of “FILS IP address configuration” at this moment. • I’ll make a resolution proposal to remove “FILS IP address configuration”. Hitoshi Morioka, Allied Telesis R&D Center

  8. CID2613 • Comment • Example usage of "FILS HLP wrapped data TLV" should be introduced. • Proposed Change • Add examples usage of "FILS HLP wrapped data TLV" as a new Annex. See 11-13/1047r0. • Resolution Policy • Add the example usage based on 11-13/1047r0 according to the resolution for CID2090. • Or reject the comment as “out of scope”. • IETF matter? • I’ll make a resolution proposal based on 11-13/1047r0 and ask the group whether “it’s our business” or “it’s IETF business”. Hitoshi Morioka, Allied Telesis R&D Center

More Related