Subject: [tsvwg] Summary of Comments/Changes: draft-ietf-tsvwg-ieee-802-11-02

From: "Tim Szigeti (szigeti)" <[email-masked]>
Date: Tue, 9 May 2017 22:04:28 +0000

First off, I'd like to thank David Black, Gorry Fairhurst, Ruediger Geib, Vincent Roca, Brian Carpenter, Tom Jones and Cullen Jennings for providing excellent constructive comments on this PS. The feedback is very valuable and makes for a better PS. As David well put it: an extensive set of comments is like a "backhanded compliment", and that's how I'm taking it ;-)

Next, I'd like to share a summary of the comments and actions taken that have gone into the latest revision, posted today:
https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11-02 

-tim

---

SUMMARY OF COMMENTS AND CHANGES: draft-ietf-tsvwg-ieee-802-11-02

Source/Date: V. Roca 12/20/16
Reference:  https://www.ietf.org/mail-archive/web/tsvwg/current/msg14878.html  
Comment: "1- Abstract is pretty similar to the general introduction... I'd suggest to shorten the abstract and go deeper into details in Section 1 to avoid such differences."

Action: Abstract has been shortened per suggestion

---

Source/Date: V. Roca 12/20/16
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14878.html   
Comment: "2-Section 4.1.1: Could you please simplify the following sentence:  "So too SHOULD Network Control..."

Action: Sentence has been reworded per suggestion ("Network control traffic marked CS6 DSCP SHOULD also be...")

---

Source/Date: V. Roca 12/20/16
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14878.html    
Comment: "3-Section 5.3: the notion of "DSCP trust" is a little bit strange. For me, the notion of trust is associated to a security assessment. For instance, marking could be trusted because it's handled by a secure mechanism, because the packet integrity is verifiable, etc. From what I understand, "trusted" means that DSCP marking is more accurate (6 bits) than UP marking (3 bits). That's totally different."

Action: A formal definition of "trust" specific to the context of this document (and in line with the way this term has been used extendedly in RFC4594) has been added to a new Terminology section (Section 1.6).  Specifically:
" Trust: From a QoS-perspective, trust refers to the accepting of the QoS markings of a packet by a network device. Trust is typically extended at Layer 3 (by accepting the DSCP), but may also be extended at lower layers, such as at Layer 2 by accepting User Priority markings. For example, if an access point is configured to trust DSCP markings and it receives a packet marked EF, then it would treat the packet with the Expedite Forwarding PHB and propagate the EF marking value (DSCP 46) as it transmits the packet. Alternatively, if a network device is configured to operate in an untrusted manner, then it would remark packets as these entered the device, typically to DF (or to a different marking value at the network administrator's preference). Note: The terms "trusted" and "untrusted" are used extensively in RFC 4594."

---

Source/Date: V. Roca 12/20/16
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14878.html     
Comment: "4-Section 8, "Security considerations": this section is strange as it references a single threat. Do you mean that no other risk exists Whether this is the case or not, this should be clearly said."

Action: Security Considerations section (Section 8) has been heavily revised and expanded; similarly, multiple sections throughout the document (notably Sections 4.1.1, 5.2, 5.3 and 5.4) have all been revised to include security-related concerns and recommendations.

---

Source/Date: V. Roca 12/20/16
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14878.html      
Comment: "5-Section 8, "Security considerations":  More generally, if a end-host can cheat while marking its traffic, then DoS are pretty easy to launch. Is there any solution to this problem? One can probably reduce risks, for instance by rate limiting techniques on a per source MAC or IP address basis (assuming this address has not been forged), but solving risks totally seems difficult without strong authentication. Perhaps WPA/WPA2 could help here? I don't know what you think about it?"

Action: All of these considerations and recommendations have been included in the expanded and revised Security Considerations section (Section 8)

---

Source/Date: V. Roca 12/20/16
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14878.html       
Comment: "6-Section 8, "Security considerations": I'm also wondering if the DSCP/UP mapping process can be considered secure? Section 3 gives some insights ("all wireless endpoint devices support the ability to support fully-configurable mappings..."). A malware may corrupt this end-host mapping, no?"

Action: This consideration has been included in the expanded and revised Security Considerations section (Section 8)

---

Source/Date: V. Roca 12/20/16
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14878.html        
Comment:  "7-Section 8, "Security considerations": Having an empty 8.1 Privacy considerations section is strange. Say explicitely that you don't think this document has any impact here."

Action: The Privacy Considerations section has been deleted

---

Source/Date: V. Roca 12/20/16
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14878.html         
Comment: "Typos and other details..."

Action: All typos have been corrected, per suggestions

---

Source/Date: D. Black 01/04/17
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.html 
Comment:  "Major Issues [1] Security!!  This text in Section 3 ... strikes me as sufficient to send a knowledgeable security directorate reviewer into low earth orbit.  I would hope the recent IoT-botnet-based DDoS attacks make it painfully clear that the operating systems and applications in endpoint devices cannot be trusted, at least as the term "trust" is used here...  IMNSHO, Section 5.3 needs a complete rethink and rewrite. [In My Not-So-Humble Opinion]  The Security Considerations in section 8 also need attention, as this topic is not mentioned there."

Action: All sections referenced in the comments have been completely re-written with the recommendations revised based on the feedback. This includes Section 3, Section 8 (Security Considerations) and Section 5 (Upstream Mapping/Marking Recommendations). Additionally, the term "trust" has been explicitly defined (in the new Terminology Section 1.6) in the same context (of QoS) as it is extensively used in RFC 4594. 

---

Source/Date: D. Black 01/04/17
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.html  
Comment:  "Major Issues [2] Diffserv domain/region boundaries... I think a new section on this topic is called for as it applies to traffic in both directions."

Action: A new section has been added (Section 2.1 Diffserv Domain Boundaries) and all points in the comments have been addressed

---

Source/Date: D. Black 01/04/17
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.html   
Comment:  "Major Issues [3] Section 4 - Relationship to RFC 4594 In Section 4, significant discussion, and often actual text are reproduced from RFC 4594, without making it clear that RFC 4594 is the source.  For example, Section 4.1 (without subsections) is entirely from RFC 4594 (there is nothing in there that isn't covered by RFC 4594).  All of section 4 needs to be edited to indicate what concepts are repeated from RFC 4594 vs. what is new to this draft. "

Action: All sections (and especially Section 4) have been edited to indicate what concepts are repeated from RFC4594, as well as the specific section of that RFC that these are being referenced from

---

Source/Date: D. Black 01/04/17
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.html    
Comment:  "Minor Issues [A] Optimality s/b Consistency...  the draft is written in terms of optimizing and (even worse)optimal QoS.  The latter is not realistic - a fine companion to the tooth fairy, Santa Claus and the Easter Bunny.  I suggest changing from optimal QoS as the goal to consistent
QoS...  This needs to be done throughout the draft.  All related terms need to be changed, e.g., "sub-optimal" -> "inconsistent" or "less consistent"

Action: "Optimal" has been changed to "consistent" throughout the document; all related terms have likewise been changed, per suggestion

---

Source/Date: D. Black 01/04/17
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.html     
Comment:  "Minor Issues [B] 1.2.  Interaction with RFC 7561  ["]The GSMA specification was developed without reference to the service plan documented in Section 1.1, and conflicts both in the services specified and the code points specified for them. ["] The above sentence is unclear.   Section 1.1 does not describe a service plan (e.g., that term doesn't occur there), and the nature of the conflict is unclear.  I suggest focusing this sentence to say that RFC 7561 and RFC 4594 conflict and add text to section 1.1 about the role of RFC 4594.   The term "service plan" is also vague in this context, and probably should not be used - see RFC 4594 for ideas on what to say instead."

Action: Section 1.2 has been reworded per suggestions. The referenced part now reads: " The GSMA specification was developed without reference to existing IETF specifications for various services, referenced in Section 1.1. Thus, [RFC7561] conflicts with the overall Diffserv traffic-conditioning service plan, both in the services specified and the code points specified for them."

---

Source/Date: D. Black 01/04/17
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.html      
Comment:  "Minor Issues [C] This draft needs a terminology section, as the initial expansions of acronyms are sprinkled across a number of places including the Abstract.  The terminology section needs to include AP, UP, DSCP, WiFi, QoS, and all the acronyms in the 6.x section headings.  Also, please ensure that WiFi is never hyphenated across a line break as Wi-Fi. While this concern is nominally editorial, it is a significant hurdle for document accessibility to non-experts, and hence I've tagged it as a minor issue."

Action: A new Terminology section (Section 1.6) has been added to the document, with all called out terms explicitly added (along with others).

---

Source/Date: D. Black 01/04/17
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.html       
Comment:  "Minor Issues [D] Section 2.  Comparison and Default Interoperation ... "Comparison" ->  "Service Comparison" to fit the scope of the section. ["] The following comparisons between IEEE 802.11 and DiffServ should be noted:["]  "comparisons" -> "service comparisons" OR insert "services" after "Diffserv"  Also note that lower case 's' is the correct capitalization of Diffserv (i.e., not camel-case DiffServ)."

Action: Changes have been made to Section 2 per the suggestions. Also all instances of "DiffServ" have been corrected to "Diffserv" throughout the document.

---

Source/Date: D. Black 01/04/17
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.html        
Comment:  "Minor Issues [E] 2.2.  Default UP-to-DSCP Mappings and Conflicts ["] Mapping UP 4 (Multimedia Conferencing and/or Real-Time Interactive) to CS4, thus losing the ability to distinguish between these two distinct traffic classes["] Need to explain somewhere how to differentiate between these two distinct traffic classes for this bullet item and following ones. Also, are these traffic classes defined by RFC 4594 or 802.11? That's not clear for bullets after the first one in the list where the quoted text is the second bullet item. "

Action: Added specific references to the respective RFC 4594 sections for the recommendations of how to differentiate services for each of the called out service classes in Section 2.2

---

Source/Date: D. Black 01/04/17
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.html         
Comment:  "Minor Issues [F] 4.1.1.  Network Control Protocols (DSCP usage) ["] Following this recommendation, it is RECOMMENDED that all packets  marked to DiffServ Codepoints not in use over the wireless network be dropped or remarked at the edge of the DiffServ domain.["]  This general recommendation should not be buried in a section on network control protocols.  At the very least it should be elevated to section 4 and included in the summary in section [4.]3.  Also, this recommendation originates from RFC 2475 and should be described accordingly, although the recommendation may not be stated as concisely in RFC 2475 by comparison to RFC 4594."

Action: This recommendation has been elevated to Section 2.1, to Section 4, and to the summary in Section 4.3, as per suggestions

---

Source/Date: D. Black 01/04/17
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.html          
Comment:  "Minor Issues [G] 4.1.1.  Network Control Protocols (drop CS6 at domain boundaries)... A specific concern is that I think
this recommendation to drop CS6 prevents running routing protocols across the wireless-to-wired boundary in this case.  While not typical, I believe that this can be done, although in the specific case of routing protocols, the boundary AP ought to be a participant in any IGP (internal) routing protocol.  OTOH, I suppose one could run an EGP (external) routing protocol, e.g., BGP here, and the AP is unlikely to be an inter-domain BGP speaker. Some more discussion seems to be in order, and the discussion should probably also note that encapsulated routing protocols for encapsulated or overlay networks (e.g., VPN, NVO3) are not network control traffic for any physical network at the AP, and hence SHOULD NOT be marked with CS6 in the first place."

Action: Revised the section per suggestions and included the specific recommended comments.

---

Source/Date: D. Black 01/04/17
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.html           
Comment:  "Minor Issues [H] 4.2.7.  Low-Latency Data ["] In line with the recommendations made in Section 4.2.2, mapping Low- Latency Data to UP 3 may allow such to receive a superior level of service via transmit queues servicing the EDCAF hardware for the Best Effort Access Category (AC_BE).["] This cross-reference to Section 4.2.2 is hard to follow.  The discussion of EDCAF hardware behavior should be factored out to somewhere near the start of Section 4.  While this concern is nominally editorial, it is a significant clarity problem for non-experts, and hence I've tagged it as a minor issue." 

Action: Revised these sections  and elevated the discussion of EDCAF to the start of Section 4 (as suggested).

---

Source/Date: D. Black 01/04/17
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.html            
Comment:  "Minor Issues [I] 4.3.  DSCP-to-UP Mapping Recommendations Summary In Figure 1, the "(See Section 4.1.1)" text for Network Control traffic won't suffice for an implementer who is looking at the 4.3 summary because Section 4 in its entirety caused a tl;dr [too long; didn't read] reaction.  Please add a short paragraph summarizing what to do (always drop CS7, drop CS6 at Diffserv boundaries, otherwise map CS6 to ...)." 

Action: Revised Figure 1 in Section 4.3 per suggestions

---

Source/Date: D. Black 01/04/17
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.html             
Comment:  "Minor Issues [J] 5.1.  Upstream DSCP-to-UP Mapping ["]   it is RECOMMENDED that such wireless client operating systems utilize instead the same DSCP-to-UP mapping recommendations presented in Section 4 and/or fully customizable UP markings.["]  I don't understand "and/or fully customizable UP markings."  As written, this allows arbitrary mappings to be consistent with the recommendation which is surely not what was intended.  I suggest ending the sentence with a period after "Section 4" and handling customizable UP markings in a separate sentence.

Action: Revised the sentence exactly as suggested.

---

Source/Date: D. Black 01/04/17
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.html              
Comment:  "Editorial/Nits..."

Action: All editorial suggestions have been implemented

---

Source/Date: B. Carpenter 01/12/17
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14885.html 
Comment:  "As stated in RFC 2474...  The defense against this class of theft- and denial-of-service attacks consists of the combination of traffic conditioning at DS domain boundaries with security and integrity of the network infrastructure within a DS domain. If the network includes devices that have been maliciously programmed to set EF on every packet, and if a router implements EF correctly, the result would be that every packet beyond the capacity allocated to EF "SHOULD be dropped" according to RFC 3246. So the service would be significantly worse than best effort. The same therefore applies to any 802.11 marking that is mapped to EF. There could be similar but less serious effects from spurious CSx or AFxy markings."

Action: This security recommendation has been added to the heavily revised and expanded Security Considerations section (Section 8)

---

Source/Date: B. Carpenter 01/12/17
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14885.html  
Comment:  " You can't trust markings from random devices. Unless devices have been identified, authenticated and authorized they aren't trustworthy. Several WGs are expending considerable effort on this problem; I'm no expert, but draft-ietf-anima-bootstrapping-keyinfra is one example."

Action: This important security consideration has now been explicitly called out in Section 5.3 " Upstream DSCP-Trust at the Wireless Access Point", which begins: "It is NOT RECOMMENDED to trust DSCP markings from devices that are not authenticated and authorized; these are considered untrusted sources." This same consideration is explicitly called out again in Section 8 "Security Considerations", which repeats that "it is NOT RECOMMENDED to trust DSCP markings from devices that are not authenticated and authorized, as these are considered untrusted sources. This is especially relevant for IoT, as billions of devices are being connected to IP networks, many of which have little or no security."

---

Source/Date: B. Carpenter 01/12/17
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14885.html  
Comment:  "BTW, I noticed that section 5.3 refers to sections 3.1 and 3.2, which don't exist."

Action: The references have been corrected to point to Sections 2.2 (Default DSCP-to-UP Mapping) and 2.3 (Default UP-to-DSCP Mapping)

---

Source/Date: B. Carpenter 01/12/17
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14885.html   
Comment:  "Since the QoS characteristics of wired and wireless networks are quite different, it might in fact be exactly the right place for a diffserv domain boundary, complete with traffic classification, re-marking and policing."

Action: This recommendation has been made, per the suggestion, in Sections 2.1 and 4.1.1

---

Source/Date: B. Carpenter 01/12/17
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14885.html    
Comment:  "If somebody has legitimately marked traffic as CS6 or CS7,  we would be arrogant to assume that we know better and the packet can be dropped. Saying that it should be re-marked, even to CS0, would be reasonable. RPL (RFC 6550) is absolutely intended to cross wireless/wired boundaries. I don't know whether RPL deployments apply CS6 but it seems entirely reasonable that they might. It's apparently been discussed in 6tisch, which is IEEE 802.15.4."

Action: All six occurrences of the 'recommendation' to drop unused codepoints at the wireless edge are actually already phrased "dropped or remarked", meeting the above suggestion.

---

Source/Date: B. Carpenter 01/12/17
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14885.html     
Comment:  "Maybe this draft should cite draft-tsvwg-le-phb instead of RFC3662?"

Action: draft-tsvwg-le-phb is expired; whereas RFC3662 is the current guiding reference for Lower Effort PDB

---

Source/Date: T. Jones [forwarded to TSVWG by G. Fairhurst] 02/24/17
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14925.html 
Comment:  "As requested, I have reviewed draft-ietf-tsvwg-ieee-802-11-01, you asked me to specifically look at the Appendix describing 80211 QoS. From a close read and referring to some standards material on the DCF I am happy with your explanation of how this works."

Action: This addresses D. Black's comment from 1/4/17  "Unfortunately, I'm not able to review Section 6's discussion of how 802.11 (WiFi) works for correctness, so someone who is an 802.11 expert will need to check that text. 
https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.html 

---

Source/Date: T. Jones [forwarded to TSVWG by G. Fairhurst] 02/24/17
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14925.html  
Comment:  " In addition I wanted to verify against a code base that the mappings were operating correctly. I have included a comparison to the FreeBSD 80211 stack, which agrees with your description."

Action: This comment [and the supplied code] validates 2.2. Default DSCP-to-UP Mappings operations, specifically the part that reads:  "a common practice in the networking industry is to map these by what we will refer to as 'Default DSCP-to-UP Mapping' (for lack of a better term), wherein the 3 Most Significant Bits (MSB) of the DSCP are used as the corresponding L2 markings."

---

Source/Date: T. Jones [forwarded to TSVWG by G. Fairhurst] 02/24/17
Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14925.html   
Comment:  " - Typo?
OLD:
   The Standard Service Class loosely corresponds to the 802.11 Best
   Effort Access Category (AC_BK)
NEW:
   The Standard Service Class loosely corresponds to the
   802.11 Best Effort Access Category (AC_BK)
                     ^^^^^^^"
         
Action: I cannot discern any difference between the OLD and the NEW; no action taken