--- 1/draft-ietf-tsvwg-ieee-802-11-03.txt 2017-07-03 15:13:23.093778785 -0700 +++ 2/draft-ietf-tsvwg-ieee-802-11-04.txt 2017-07-03 15:13:23.161780428 -0700 @@ -1,19 +1,19 @@ Transport Working Group T. Szigeti Internet-Draft J. Henry Intended status: Standards Track Cisco Systems -Expires: November 25, 2017 F. Baker - May 24, 2017 +Expires: January 4, 2018 F. Baker + July 3, 2017 Diffserv to IEEE 802.11 Mapping - draft-ietf-tsvwg-ieee-802-11-03 + draft-ietf-tsvwg-ieee-802-11-04 Abstract 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 @@ -27,21 +27,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 25, 2017. + This Internet-Draft will expire on January 4, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -52,68 +52,70 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Related work . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Interaction with RFC 7561 . . . . . . . . . . . . . . . . 4 1.3. Applicability Statement . . . . . . . . . . . . . . . . . 4 1.4. Document Organization . . . . . . . . . . . . . . . . . . 5 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 5 - 1.6. Terminology Used in this Document . . . . . . . . . . . . 5 + 1.6. Terminology Used in this Document . . . . . . . . . . . . 6 2. Service Comparison and Default Interoperation of Diffserv and IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Diffserv Domain Boundaries . . . . . . . . . . . . . . . 9 - 2.2. Default DSCP-to-UP Mappings and Conflicts . . . . . . . . 9 - 2.3. Default UP-to-DSCP Mappings and Conflicts . . . . . . . . 10 + 2.2. Default DSCP-to-UP Mappings and Conflicts . . . . . . . . 10 + 2.3. Default UP-to-DSCP Mappings and Conflicts . . . . . . . . 11 3. Wireless Device Marking and Mapping Capability Recommendations . . . . . . . . . . . . . . . . . . . . . . . 12 4. DSCP-to-UP Mapping Recommendations . . . . . . . . . . . . . 12 4.1. Network Control Traffic . . . . . . . . . . . . . . . . . 13 4.1.1. Network Control Protocols . . . . . . . . . . . . . . 13 4.1.2. Operations Administration Management (OAM) . . . . . 14 - 4.2. User Traffic . . . . . . . . . . . . . . . . . . . . . . 15 + 4.2. User Traffic . . . . . . . . . . . . . . . . . . . . . . 14 4.2.1. Telephony . . . . . . . . . . . . . . . . . . . . . . 15 4.2.2. Signaling . . . . . . . . . . . . . . . . . . . . . . 15 4.2.3. Multimedia Conferencing . . . . . . . . . . . . . . . 16 4.2.4. Real-Time Interactive . . . . . . . . . . . . . . . . 16 - 4.2.5. Multimedia-Streaming . . . . . . . . . . . . . . . . 17 + 4.2.5. Multimedia-Streaming . . . . . . . . . . . . . . . . 16 4.2.6. Broadcast Video . . . . . . . . . . . . . . . . . . . 17 4.2.7. Low-Latency Data . . . . . . . . . . . . . . . . . . 17 - 4.2.8. High-Throughput Data . . . . . . . . . . . . . . . . 18 + 4.2.8. High-Throughput Data . . . . . . . . . . . . . . . . 17 4.2.9. Standard Service Class . . . . . . . . . . . . . . . 18 - 4.2.10. Low-Priority Data . . . . . . . . . . . . . . . . . . 19 - 4.3. DSCP-to-UP Mapping Recommendations Summary . . . . . . . 19 + 4.2.10. Low-Priority Data . . . . . . . . . . . . . . . . . . 18 + 4.3. DSCP-to-UP Mapping Recommendations Summary . . . . . . . 18 5. Upstream Mapping and Marking Recommendations . . . . . . . . 20 5.1. Upstream DSCP-to-UP Mapping within the Wireless Client - Operating System . . . . . . . . . . . . . . . . . . . . 21 + Operating System . . . . . . . . . . . . . . . . . . . . 20 5.2. Upstream UP-to-DSCP Mapping at the Wireless Access Point 21 - 5.3. Upstream DSCP-Trust at the Wireless Access Point . . . . 22 + 5.3. Upstream DSCP-Trust at the Wireless Access Point . . . . 21 5.4. Upstream DSCP Marking at the Wireless Access Point . . . 22 - 6. Appendix: IEEE 802.11 QoS Overview . . . . . . . . . . . . . 23 + 6. Appendix: IEEE 802.11 QoS Overview . . . . . . . . . . . . . 22 6.1. Distributed Coordination Function (DCF) . . . . . . . . . 23 - 6.1.1. Slot Time . . . . . . . . . . . . . . . . . . . . . . 24 + 6.1.1. Slot Time . . . . . . . . . . . . . . . . . . . . . . 23 6.1.2. Interframe Spaces . . . . . . . . . . . . . . . . . . 24 - 6.1.3. Contention Windows . . . . . . . . . . . . . . . . . 25 + 6.1.3. Contention Windows . . . . . . . . . . . . . . . . . 24 6.2. Hybrid Coordination Function (HCF) . . . . . . . . . . . 25 6.2.1. User Priority (UP) . . . . . . . . . . . . . . . . . 25 - 6.2.2. Access Category (AC) . . . . . . . . . . . . . . . . 26 - 6.2.3. Arbitration Inter-Frame Space (AIFS) . . . . . . . . 27 + 6.2.2. Access Category (AC) . . . . . . . . . . . . . . . . 25 + 6.2.3. Arbitration Inter-Frame Space (AIFS) . . . . . . . . 26 6.2.4. Access Category Contention Windows (CW) . . . . . . . 27 6.3. IEEE 802.11u QoS Map Set . . . . . . . . . . . . . . . . 28 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 + 8.1. General QoS Security Recommendations . . . . . . . . . . 29 + 8.2. WLAN QoS Security Recommendations . . . . . . . . . . . . 30 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 10.1. Normative References . . . . . . . . . . . . . . . . . . 31 - 10.2. Informative References . . . . . . . . . . . . . . . . . 32 + 10.2. Informative References . . . . . . . . . . . . . . . . . 33 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 1. Introduction Wireless has become the preferred medium for endpoints connecting to business and private networks. However, the wireless medium defined by IEEE 802.11 [IEEE.802.11-2016] presents several design challenges for ensuring end-to-end quality of service. Some of these challenges relate to the nature of the IEEE 802.11 RF medium itself, being a @@ -387,39 +390,39 @@ o [IEEE.802.11-2016] loosely supports a [RFC3662] Lower Effort PDB service via the Background Access Category (AC_BK) As such, these high-level considerations should be kept in mind when mapping from Diffserv to [IEEE.802.11-2016] (and vice-versa); however, access points may or may not always be positioned at Diffserv domain boundaries, as will be discussed next. 2.1. Diffserv Domain Boundaries - It is important to note that the wired-to-wireless edge may or may - not equate to the edge of the Diffserv domain. + It is important to recognize that the wired-to-wireless edge may or + may not equate to the edge of the Diffserv domain. In most commonly-deployed WLAN models, the wireless access point represents not only the edge of the Diffserv domain, but also the edge of the network infrastructure itself. As such, only client - devices (and no infrastructure devices) are downstream from the - access points in these deployment models. In such deployment models, - 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, as will be discussed in detail in - Section 4.1.1. + endpoint devices (and no infrastructure devices) are downstream from + the access points in these deployment models. Note: security + considerations and recommendations for hardening such Wifi-at-the- + edge deployment models are detailed in Section 8. Alternatively, in other deployment models, such as Wi-Fi backhaul, - wireless mesh infrastructures, or other types of wireless AP-to-AP - deployments, the wireless access points extend the network - infrastructure and thus, typically, the Diffserv domain. In such - deployments, both client devices and infrastructure devices may be - expected downstream from the access points. + wireless mesh infrastructures, wireless AP-to-AP deployments, or in + cases where a Wi-Fi link connects to a device providing service via + another technology (e.g. Wi-Fi to Bluetooth or Zigbee router), the + wireless access point extends the network infrastructure and thus, + typically, the Diffserv domain. In such deployments, both client + devices and infrastructure devices may be expected downstream from + the access points. Thus the QoS treatment of packets at the access point will depend on the position of the AP in the network infrastructure and on the WLAN deployment model. However, regardless of the access point being at the Diffserv boundary or not, Diffserv to [IEEE.802.11-2016] (and vice-versa) marking-specific incompatibilities exist that must be reconciled, as will be discussed next. @@ -597,73 +600,55 @@ (signaling) that may be generated by some applications or services. Network control traffic MAY be split into two service classes: o Network Control, and o Operations Administration and Management (OAM) 4.1.1. Network Control Protocols The Network Control service class is used for transmitting packets - between network devices (routers) that require control (routing) + between network devices (e.g. routers) that require control (routing) information to be exchanged between nodes within the administrative - domain as well as across a peering point between different - administrative domains. The RECOMMENDED DSCP marking for Network - Control is CS6, per [RFC4594] Section 3.2. - - Before discussing a mapping recommendation for Network Control - traffic marked CS6 DSCP, it is interesting to note a relevant - recommendation from [RFC4594] pertaining to traffic marked CS7 DSCP: - in [RFC4594] Section 3.1 it is RECOMMENDED that packets marked CS7 - DSCP (a codepoint that SHOULD be reserved for future use) be dropped - or remarked at the edge of the Diffserv domain. - - 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. + domain, as well as across a peering point between different + administrative domains. - It is important to note that the wired-to-wireless edge may or may - not equate to the edge of the Diffserv domain, as discussed in - Section 2.1; as such, this recommendation may or may not apply at the - wired-to-wireless edge (and vice-versa). + The RECOMMENDED DSCP marking for Network Control is CS6, per + [RFC4594] Section 3.2; additionally, CS7 DSCP value SHOULD be + reserved for future use, potentially for future routing or control + protocols, again, per [RFC4594] Section 3.2. - In most commonly-deployed WLAN models, where wireless access point - represents not only the edge of the Diffserv domain, but also the - edge of the network infrastructure itself. Traffic marked CS7 DSCP - SHOULD be dropped or remarked at this edge (as it is typically - unused, as CS7 SHOULD be reserved for future use). Network control - traffic marked CS6 DSCP SHOULD also be dropped or remarked at this - edge, considering that only client devices (and no network - infrastructure devices) are downstream from the wireless access - points in these deployment models; such client devices would be - considered as untrusted sources of a network control traffic. In - such cases, no Network control traffic would be (legitimately) - expected to be sent or received from wireless client endpoint - devices, and thus this recommendation would apply. + By default, packets marked DSCP CS7 will be mapped to UP 7 and + serviced within the Voice Access Category (AC_VO). This represents + the RECOMMENDED mapping for CS7, that is, packets marked to CS7 DSCP + are RECOMMENDED to be mapped to UP 7. - Alternatively, in other deployment models, where the wireless access - point extends the network infrastructure and thus, typically, the - Diffserv domain, the above recommendation would not apply, as the - wired-to-wireless edge does not represent the edge of the Diffserv - domain. Furthermore, as these deployment models require Network - Control traffic to be propagated across the wireless network, it is - RECOMMENDED to map Network Control traffic marked CS6 to UP 7 (per - [IEEE.802.11-2016] Section 10.2.4.2, Table 10-1), thereby admitting - it to the Voice Access Category (AC_VO). Similarly, if CS7 is in use - as a network control protocol it would be RECOMMENDED to map it also - to UP 7. + However, by default, packets marked DSCP CS6 will be mapped to UP 6 + and serviced within the Voice Access Category (AC_VO); such mapping + and servicing is a contradiction to the intent expressed in [RFC + 4594] section 3.2. As such, it is RECOMMENDED to map Network Control + traffic marked CS6 to UP 7 (per [IEEE.802.11-2016] Section 10.2.4.2, + Table 10-1), thereby admitting it to the Voice Access Category + (AC_VO), albeit with a marking distinguishing it from (data-plane) + voice traffic. It should be noted 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. + Addtionally, and as previously noted, the Security Considerations + section (Section 8) contains additional recommendations for hardening + Wifi-at-the-edge deployment models, where, for example, network + control protocols are not expected to be sent nor recevied between + APs and downstream endpoint client devices. + 4.1.2. Operations Administration Management (OAM) The OAM (Operations, Administration, and Management) service class is RECOMMENDED for OAM&P (Operations, Administration, and Management and Provisioning). The RECOMMENDED DSCP marking for OAM is CS2, per [RFC4594] Section 3.3. By default, packets marked DSCP CS2 will be mapped to UP 2 and serviced with the Background Access Category (AC_BK). Such servicing is a contradiction to the intent expressed in [RFC4594] Section 3.3. @@ -866,66 +850,69 @@ 4.3. DSCP-to-UP Mapping Recommendations Summary Figure 1 summarizes the [RFC4594] DSCP marking recommendations mapped to [IEEE.802.11-2016] UP and access categories applied in the downstream direction (i.e. from wired-to-wireless networks). +------------------------------------------------------------------+ | IETF Diffserv | PHB |Reference| IEEE 802.11 | | Service Class | | RFC |User Priority| Access Category | - |===============+======+=========+=============+===================| + |===============+======+=========+=============+====================| | | | | 7 | AC_VO (Voice) | |Network Control| CS7 | RFC2474 | OR | - |(reserved for | | | Remark/Drop at Diffserv Boundary| - | future use) | | | (See Section 4.1.1) | - +---------------+------+---------+-------------+-------------------+ + |(reserved for | | | 0 | AC_BE (Best Effort)| + | future use) | | |See Security Considerations-Sec.8)| + +---------------+------+---------+-------------+--------------------+ | | | | 7 | AC_VO (Voice) | |Network Control| CS6 | RFC2474 | OR | - | | | | Remark/Drop at Diffserv Boundary| - | | | | (See Section 4.1.1) | - +---------------+------+---------+-------------+-------------------+ + | | | | 0 | AC_BE (Best Effort)| + | | | |See Security Considerations-Sec.8)| + +---------------+------+---------+-------------+--------------------+ | Telephony | EF | RFC3246 | 6 | AC_VO (Voice) | - +---------------+------+---------+-------------+-------------------+ + +---------------+------+---------+-------------+--------------------+ | VOICE-ADMIT |VOICE-| RFC5865 | 6 | AC_VO (Voice) | | |ADMIT | | | | - +---------------+------+---------+-------------+-------------------+ + +---------------+------+---------+-------------+--------------------+ | Signaling | CS5 | RFC2474 | 5 | AC_VI (Video) | - +---------------+------+---------+-------------+-------------------+ + +---------------+------+---------+-------------+--------------------+ | Multimedia | AF41 | | | | | Conferencing | AF42 | RFC2597 | 4 | AC_VI (Video) | | | AF43 | | | | - +---------------+------+---------+-------------+-------------------+ + +---------------+------+---------+-------------+--------------------+ | Real-Time | CS4 | RFC2474 | 4 | AC_VI (Video) | | Interactive | | | | | - +---------------+------+---------+-------------+-------------------+ + +---------------+------+---------+-------------+--------------------+ | Multimedia | AF31 | | | | | Streaming | AF32 | RFC2597 | 4 | AC_VI (Video) | | | AF33 | | | | - +---------------+------+---------+-------------+-------------------+ + +---------------+------+---------+-------------+--------------------+ |Broadcast Video| CS3 | RFC2474 | 4 | AC_VI (Video) | - +---------------+------+---------+-------------+-------------------+ + +---------------+------+---------+-------------+--------------------+ | Low- | AF21 | | | | | Latency | AF22 | RFC2597 | 3 |AC_BE (Best Effort)| | Data | AF23 | | | | - +---------------+------+---------+-------------+-------------------+ + +---------------+------+---------+-------------+--------------------+ | OAM | CS2 | RFC2474 | 0 |AC_BE (Best Effort)| - +---------------+------+---------+-------------+-------------------+ + +---------------+------+---------+-------------+--------------------+ | High- | AF11 | | | | | Throughput | AF12 | RFC2597 | 0 |AC_BE (Best Effort)| | Data | AF13 | | | | - +---------------+------+---------+-------------+-------------------+ + +---------------+------+---------+-------------+--------------------+ | Standard | DF | RFC2474 | 0 |AC_BE (Best Effort)| - +---------------+------+---------+-------------+-------------------+ + +---------------+------+---------+-------------+--------------------+ | Low-Priority | CS1 | RFC3662 | 1 | AC_BK (Background)| | Data | | | | | - +------------------------------------------------------------------+ + +-------------------------------------------------------------------+ + + Note: All unusued codepoints are recommended to be mapped to UP 0 + (See Security Considerations Section - Section 8) Figure 1: Summary of Downstream DSCP to IEEE 802.11 UP and AC Mapping Recommendations 5. Upstream Mapping and Marking Recommendations In the upstream direction (i.e. wireless-to-wired), there are three types of mapping that MAY be implemented: o DSCP-to-UP mapping within the wireless client operating system @@ -945,22 +932,30 @@ 5.1. Upstream DSCP-to-UP Mapping within the Wireless Client Operating System Some operating systems on wireless client devices utilize a similar default DSCP-to-UP mapping scheme as described in Section 2.2. As such, this can lead to the same conflicts as described in that section, but in the upstream direction. Therefore, to improve on these default mappings, and to achieve parity and consistency with downstream QoS, it is RECOMMENDED that - such wireless client operating systems utilize instead the same DSCP- - to-UP mapping recommendations presented in Section 4. + wireless client operating systems utilize instead the same DSCP-to-UP + mapping recommendations presented in Section 4, with the explicit + RECOMMENDATION that packets requesting a marking of CS6 or CS7 DSCP + SHOULD be mapped to UP 0 (and not to UP 7). Furthermore, in such + cases the wireless client operating system SHOULD remark such packets + to DSCP 0. This is because CS6 and CS7 DSCP, as well as UP 7 + markings, are intended for network control protocols and these SHOULD + NOT be sourced from wireless client endpoint devices. This + recommendation is detailed in the Security Considerations section + (Section 8). 5.2. Upstream UP-to-DSCP Mapping at the Wireless Access Point UP-to-DSCP mapping generates a DSCP value for the IP packet (either an unencapsulated IP packet or an IP packet encapsulated within a tunneling protocol such as CAPWAP - and destined towards a wireless LAN controller for decapsulation and forwarding) from the Layer 2 [IEEE.802.11-2016] UP marking. This is typically done in the manner described in Section 2.3. @@ -988,23 +983,23 @@ [IEEE.802.11-2016] UP markings as set by wireless hosts and subsequently perform a UP-to-DSCP mapping in the upstream direction, but rather, if wireless host markings are to be trusted (as per business requirements, technical constraints and administrative policies), then it is RECOMMENDED to trust the Layer 3 DSCP markings set by these wireless hosts instead, as is discussed in the next section. 5.3. Upstream DSCP-Trust at the Wireless Access Point - It is NOT RECOMMENDED to trust DSCP markings from devices that are - not authenticated and authorized; these are considered untrusted - sources. + It is generally NOT RECOMMENDED to trust DSCP markings from + unauthenticated and unauthorized devices, as these are typically + considered untrusted sources. When business requirements and/or technical constraints and/or administrative policies require a trust function at the wireless edge, then it is RECOMMENDED to trust DSCP (over [IEEE.802.11-2016] UP markings) markings in the upstream direction, for the following reasons: o [RFC2474], [RFC2475] and [RFC8100] all allow for hosts to set DSCP markings to achieve an end-to-end differentiated service @@ -1084,24 +1079,24 @@ 6.1.1. Slot Time The slot time is the basic unit of time measure for both DCF and HCF, on which all other timers are based. The slot time duration varies with the different generations of data-rates and performances described by the [IEEE.802.11-2016] standard. For example, the [IEEE.802.11-2016] standard specifies the slot time to be 20 us ([IEEE.802.11-2016] Table 15-5) for legacy implementations (such as IEEE 802.11b, supporting 1, 2, 5.5 and 11 Mbps data rates), while - newer implementations (including IEEE 802.11g, 80.11a, 802.11n and - 802.11ac, supporting data rates from 500 Mbps to over 1 Gbps) define - a shorter slot time of 9 us ([IEEE.802.11-2016], Section 17.4.4, - Table 17-21). + newer implementations (including IEEE 802.11g, 802.11a, 802.11n and + 802.11ac, supporting data rates from 6.5 Mbps to over 2 Gbps per + spatial stream) define a shorter slot time of 9 us + ([IEEE.802.11-2016], Section 17.4.4, Table 17-21). 6.1.2. Interframe Spaces The time interval between frames that are transmitted over the air is called the Interframe Space (IFS). Several IFS are defined in [IEEE.802.11-2016], with the two most relevant to DCF being the Short Interframe Space (SIFS) and the DCF Interframe Space (DIFS). The SIFS is the amount of time in microseconds required for a wireless interface to process a received RF signal and its associated @@ -1310,22 +1306,21 @@ DSCP values, and 2) (up to 21) exceptions from these range-based DSCP to/from UP mapping associations may be optionally and explicitly specified. In line with the recommendations put forward in this document, the following recommendations apply when the QoS Map element is enabled: 1) each of the eight UP values (0-7) are RECOMMENDED to be mapped to DSCP 0 (as a baseline, so as to meet the recommendation made in - Section 4.1.1 that packets marked to unused Diffserv Codepoints be - remarked at the edge of the Diffserv domain), and + Section 8.2 2) (up to 21) exceptions from this baseline mapping are RECOMMENDED to be made in line with Section 4.3, to correspond to the Diffserv Codepoints that are in use over the IP network. It is important to note that the QoS Map element is intended to be transmitted from a wireless access point to a non-AP station. As such, the model where this element is used is that of a network where the AP is the edge of the Diffserv domain. Networks where the AP extends the Diffserv domain by connecting other APs and @@ -1338,75 +1333,111 @@ This memo asks the IANA for no new parameters. 8. Security Considerations The recommendations put forward in this document do not present any additional security concerns that do not already exist in wired and wireless devices. In fact, several of the recommendations made in this document serve to mitigate and protect wired and wireless networks from potential abuse arising from existing vulnerabilities. - For example, it may be possible for a wireless device, either a host - or a network device, to mark packets in a manner that interferes with - or degrades existing QoS policies. Similarly, it may be possible for - a device to map L2/L3 markings in a manner that causes similar - effects. Such marking or mapping may be done intentionally or - unintentionally by the developers and/or users and/or administrators - of such devices. To illustrate: A gaming application designed to run - on a smart-phone or tablet may request that all its packets be marked - DSCP EF and/or UP 6. However, if the traffic from such an - application is trusted over a business network, then this could - interfere with QoS policies intended to provide priority services for - enterprise voice applications. To mitigate such attack vectors it is - RECOMMENDED to implement security measures, such as policing EF - marked packet flows, as detailed in [RFC2474] Section 7 and [RFC3246] - Section 3. +8.1. General QoS Security Recommendations - Furthermore, several recommendations have been made in this document - to mitigate the potential for deliberate or inadvertent violations. - Specifically the following recommendations have been made for - primarily security reasons: + It may be possible for a wired or wireless device (which could be + either a host or a network device) to mark packets (or map packet + markings) in a manner that interferes with or degrades existing QoS + policies. Such marking or mapping may be done intentionally or + unintentionally by developers and/or users and/or administrators of + such devices. - Section 4.1.1 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 recommendation - may help mitigate a Denial-of-Service attack vector that exists at - wired-to-wireless edges in the downstream direction. For example, - consider a malicious user flooding traffic marked CS7 or CS6 DSCP - toward the WLAN. These codepoints would map by default to UP 7 - and UP 6 (respectively), both of which would be assigned to the - Voice Access Category (AC_VO). Such a flood could cause a Denial- - of-Service to wireless voice applications. + To illustrate: A gaming application designed to run on a smart-phone + or tablet may request that all its packets be marked DSCP EF and/or + UP 6. However, if the traffic from such an application is trusted + over a business network, then this could interfere with QoS policies + intended to provide priority services for business voice + applications. - Section 5.3 made it clear 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. + To mitigate such scenarios it is RECOMMENDED to implement general QoS + security measures, including: - Section 5.4 RECOMMENDED that the administrator treat the wireless - edge as the edge of the Diffserv domain and explicitly set (or - reset) DSCP markings in the upstream direction according to - administrative policy. UP-to-DSCP mapping was explicitly NOT - RECOMMENDED in Section 5.2. Also DSCP-trust was heavily caveated - in Section 5.3. These recommendations collectively serve to - mitigate Denial-of-Service attacks in the upstream direction. For - example, consider a malicious user flooding traffic from a - wireless endpoint device marked DSCP 48 and/or UP 6. If default - UP-to-DSCP mapping were enabled at the access-point, these flows - would be mapped to DSCP 48, and could thus interfere with QoS - policies intended to protect control plane protocols over the IP - network, resulting in potential network instability; such could - likewise happen if DSCP-trust were enabled in the same scenario. + Setting a trust boundary 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 trust 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, many of which have little or + no security. - Furthermore, it should be noted that the recommendations put forward - in this document are not intended to address all attack vectors + Policing EF marked packet flows, as detailed in [RFC2474] + Section 7 and [RFC3246] Section 3. + + In addition to these general QoS security recommendations, WLAN- + specific QoS security recommendations can serve to further mitigate + attacks and potential network abuse. + +8.2. WLAN QoS Security Recommendations + + The wireless LAN presents a unique DoS attack vector, as endpoint + devices contend for the shared media on a completely egalitarian + basis with the network (as represented by the AP). This means that + any wireless client could potentially monopolize the air by sending + packets marked to preferred UP values (i.e. UP values 4-7) in the + upstream direction. Similarly, airtime could be monopolized if + excessive amounts of downstream traffic were marked/mapped to these + same preferred UP values. As such, the ability to mark/map to these + preferred UP values (of UP 4-7) should be controlled. + + If such marking/mapping were not controlled, then, for example, a + malicious user could cause WLAN DoS by flooding traffic marked CS7 + DSCP downstream. This codepoint would map by default to UP 7 and + would be assigned to the Voice Access Category (AC_VO). Such a flood + could cause Denial-of-Service to not only wireless voice + applications, but also to all other traffic classes. + + Therefore, to mitigate such an attack, it is RECOMMENDED that all + packets marked to Diffserv Codepoints not in use over the wireless + network be mapped to UP 0. + + Such a policy of mapping unused codepoints to UP 0 would also prevent + an attack where non-standard codepoints were used to cause WLAN DoS. + Consider the case where codepoints are mapped to UP values using a + range function (e.g. DSCP values 48-55 all map to UP 6), then an + attacker could flood packets marked, for example to DSCP 49, in + either the upstream or downstream direction over the WLAN, causing + DoS to all other traffic classes in the process. + + It should be strongly noted that in the wireless deployment model + where the AP represents not only the edge of the Diffserv domain, but + also the edge of the network infrastructure itselt, then CS6 and CS7 + also fall into the category of codepoints that are not in use over + the wireless LAN. This is because only wireless endpoint client + devices are downstream from the AP in this model, and as such, these + devices do not (legitimately) participate in network control protocol + exchanges. As such, it is RECOMMENDED that CS6 and CS7 DSCP be + mapped to UP 0 in these Wifi-at-the-edge deployment models. + Otherwise, it would be easy for a malicious developer, or even an + inadvertently poorly-programmed IoT device, to cause WLAN DoS and + even wired IP network instability by flooding traffic marked CS6 + DSCP, which would (by default) be mapped to UP 6, causing all other + traffic classes on the WLAN to be starved, as well hijacking queues + on the wired IP network that are intended for the servicing of + routing protocols. To this point, it was also recommended in + Section 5.1 that packets requesting a marking of CS6 or CS7 DSCP + SHOULD be remarked to DSCP 0 and mapped to UP 0 by the wireless + client operating system. + + Finally, it should be noted that the recommendations put forward in + this document are not intended to address all attack vectors leveraging QoS marking abuse. Mechanisms that may further help mitigate security risks include strong device- and/or user- authentication, access-control, rate limiting, control-plane policing, encryption and other techniques; however, the implementation recommendations for such mechanisms are beyond the scope of this document to address in detail. Suffice it to say that the security of the devices and networks implementing QoS, including QoS mapping between wired and wireless networks, SHOULD be considered in actual deployments. @@ -1481,22 +1512,21 @@ . [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, March 2017, . 10.2. Informative References [I-D.ietf-tsvwg-le-phb] Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", - draft-ietf-tsvwg-le-phb-01 (work in progress), February - 2017. + draft-ietf-tsvwg-le-phb-02 (work in progress), June 2017. [IEEE.802-11u.2011] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications", IEEE Standard 802.11, 2011, .