The IESG has approved the following document: - 'Diffserv to IEEE 802.11 Mapping' (draft-ietf-tsvwg-ieee-802-11-11.txt) as Proposed Standard This document is the product of the Transport Area Working Group. The IESG contact persons are Mirja Kühlewind and Spencer Dawkins. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11/ Technical Summary As internet traffic is increasingly sourced-from and destined-to wireless endpoints, it is crucial that Quality of Service be aligned between wired and wireless networks; however, this is not always the case by default. This document specifies a set Differentiated Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings to reconcile the marking recommendations offered by the IETF and the IEEE so as to maintain consistent QoS treatment between wired and IEEE 802.11 wireless networks. Working Group Summary This draft is supported by the portion of the tsvwg working group that is familiar with and interested in Diffserv. The mappings in this draft have been stable for about the past year and are being implemented. Recent activity on this draft stemming from WG Last Call has focused on other aspects, primarily security-related (e.g., network cannot "trust" DSCP markings set by the originator of traffic) and related concerns around dealing with possible use and misuse of the high priority CS6 and CS7 DSCP markings for network control traffic such as routing protocols. All of these concerns have been resolved, and the shepherd is confident that the draft reflects WG rough consensus. The TSVWG WG is working on revising and replacing the RFC 3662 specification of Lower Effort (less than best effort) Diffserv traffic; that revision will change the recommended DSCP. The WG has decided that this DSCP to UP mapping draft should reflect current "running code" that uses the CS1 codepoint for Lower Effort traffic and not wait for completion of work on replacement of RFC 3662 and selection of a new recommended default DSCP for Lower Effort traffic. Document Quality The draft has received significant review and critique from a number of Diffserv experts, including the draft shepherd. the draft has been significantly modified as a result, including revising the mappings to resolve concerns about potential priority inversion between wired and wireless networks. The WiFi material has also been reviewed by a WiFi expert. Personnel The Document Shepherd is David Black. The responsible Area Director is Spencer Dawkins. RFC Editor Note OLD o Setting a traffic conditioning policy reflective of business objectives and policy, such that traffic from authorized users and/or applications and/or endpoints will be accepted by the network; otherwise packet markings will be "bleached" (i.e. remarked to DSCP DF and/or UP 0). Additionally, Section 5.3 made it clear that it is generally NOT RECOMMENDED to pass through DSCP markings from unauthorized and/or unauthenticated devices, as these are typically considered untrusted sources. This is especially relevant for IoT deployments, where tens-of-billions of devices are being connected to IP networks with little or no security capabilities (making such vulernable to be utilized as agents for DDoS attacks, the effects of which can be amplified with preferential QoS treatments, should the packet markings of such devices be trusted). NEW o Setting a traffic conditioning policy reflective of business objectives and policy, such that traffic from authorized users and/or applications and/or endpoints will be accepted by the network; otherwise packet markings will be "bleached" (i.e. remarked to DSCP DF and/or UP 0). Additionally, Section 5.3 made it clear that it is generally NOT RECOMMENDED to pass through DSCP markings from unauthorized and/or unauthenticated devices, as these are typically considered untrusted sources. This is especially relevant for IoT deployments, where tens-of-billions of devices are being connected to IP networks with little or no security capabilities, leaving them vulnerable to be utilized as agents for DDoS attacks. These attacks can be amplified with preferential QoS treatments, should the packet markings of such devices be trusted.
