[tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - Concerns about text on conditioning rules

[Gorry Fairhurst <[e-mail]>]

This email describes a number of concerns with the inclusion of 
conditioning rules in the 802-11 draft.

The title and abstract of the draft describe a mapping function. 
However, the changes in rev -02 give me serious doubts about the 
remarking and drop recommendations, which I consider for a diffserv edge.

Point 1: I think the WG need to be very clear about the context of 
recommendations. I’d expect the class mappings to PHBs to be applied in 
all equipment that adheres to IETF standards. This should I think be the 
default for all APs - and I'd hope most vendors would start paying 
attention.

Point 2: My concern is that the draft now recommends diffserv edge 
mechanisms that I think are inappropriate for a mapping draft. I suggest 
the conditioning rules apply to specific deployment scenarios. I also 
suggest this does not apply to all equipment - any recommendations need 
to be certain about context for deployment. I think there is quite an 
opportunity for the present text on remarking and drop in the current 
revision to be wrongly interpreted. I seriously fear the inclusion of 
remarking and drop recommendations can make this become an impediment to 
sender marking of DSCP across IP paths that happen to include 802.11 
equipment.

Point 3: The specific conditioning rules argue for pervasive remarking 
of all “unknown” codepoints - this position is a very specific view. If 
stated in a PS for 802.11 this would have serious implications on the 
usefulness of diffserv, and I think the IETF really has to consider 
these in detail before it takes this approach for 802.11.

------------

So, starting with Point 1: I noted previously that I do see real benefit 
in recommendations on how to map DSCPs using 802.11 and I suspect, if 
done correctly, this can greatly ease the consistent use of DSCP.

It may be that the security considerations need to discuss the trust of 
markings and the possible need to remark or drop to protect the AP 
resources. I can also see how CS6 and CS7 may need to be discussed and 
text may have to say things about these when the AP is forms the edge of 
a network.

TEXT:
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).
- section 4.1.1. recommends drop or remark, and I struggle here to know 
that this is the correct statement to make in general for 802.11 usage. 
Is it strictly necessary to drop CS6 traffic at an AP, that seems 
plausible in managed (e.g. enterprise) deployment, or on the
upstream to an ISP in a home deployment (maybe in some places the 
operator own the AP?). Between IP networks in my house this seems like 
the wrong thing to do. It may be used by a routing protocol (e.g. RPL as 
noted) could use this DSCP, why can I not use a layer 2 technology to 
move these packets between parts of my IP network with the DSCP that has 
been assigned?

So, really I question if the current phrasing is the correct 
recommendation. I think the WG needs to choose appropriate words here 
but that needs I think to be balanced by explaining that these 
codepoints may be used within a house or whatever for routing and 
functions. - They are not just for the upstream ISP!

Point 2: As you noted, there is a wide variety of 802.11 equipment and 
uses and you highlight two distinct deployment models. 802.11 uses are 
really diverse - they include managed environments in Enterprises, 
public wifi access, home networks, use as layer infrastructure in a very 
general sense, bridging to other layer 2 infrastructure (zigbee, etc).

There now follows concerns about the new text, which largely stems from 
the above context (i.e., in a different document with a different 
purpose the comments would be different).

I am not sure this text is helpful:
" 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.
"
- Again, there are many cases where this also not the same as well. I 
have a number of APs in my house, and for that matter a zigbee bridge 
that connects IoT devices. For many flows the AP is one hop to the DSL 
modem, but flows also exist between endpoints in the house - e.g. to 
deliver TV content across my home network, or to turn on/off lights or 
simply access the house computer from my laptop.

On Point 3: I think it may be wrong to recommend this:
TEXT:
"
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."
- I would really hope APs do not do this, except if they within the 
control network of an upstream service provider that has configured 
consistent rules at the Apps for the service they offer.

I see the next para effectively implies SHOULD NOT remark or drop, in 
some other case - but even though I suspect you are hoping for the 
correct thing I do not see this clearly enough to feel confident that 
others will always understand what to do.

- It also suggests drop and remark are equal, they are not - the there 
behaviour i) (carry as DF (ii) Remark to DF (iii) Drop have quite 
different implications to those trying to write apps that wish to use 
diffserv.
---
TEXT:
”
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."
- Oh indeed, but the more I read, the more I’d really rather see how to 
handle edge treatment as a separate document that clearly explains that 
at a diffserv edge you do conditioning and what are the implications of 
the different approaches.
---
TEXT:
It is NOT RECOMMENDED to trust DSCP markings from devices that are
not authenticated and authorized; these are considered untrusted
sources.
- Question: What is the intent here? Are you encouraging DSCP remarking 
(I hope not), or are you saying that the UP marking is assigned using a 
local policy rather than from the DSCP?

- I suspect the context here is not about mapping it is about managed 
use of an AP network. That varies, and I really think this is not the 
document to discuss that. The security considerations could note this - 
but quite honestly, if you expect my light bulbs and TV sets to start 
authenticating with the AP, then I'm going to argue. Do these devices 
benefit from using DSCPs - very very likely.

- Of course, if you were offering infrastucture to a range of customers 
then you may need to consider these issues. Saying SHOULD NOT trust 
seems to suggest you threaten to remark? or just to carry as best-effort 
within this network?
(Back to point 2: We all know that public radio networks need to 
consider resource models, but this is not a PHB mapping question.)
---
TEXT:
"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."
- This is NOT what I want from an out-of-the-box AP configuration, and I 
think this muddies the deployment context.
---

More on point 3: I really do not agree with the text in section 5.4:
TEXT:
5.4. Upstream DSCP Marking at the Wireless Access Point

An alternative option to mapping is for the administrator to 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. This option is RECOMMENDED over mapping, as
this typically is the most secure solution, as the network
administrator directly enforces the Diffserv policy across the IP
network (versus an application developer and/or the wireless endpoint
device operating system developer, who may be functioning completely
independently of the network administrator).

- Comment. I see the alternative and realise that the edge of a DS 
domain can condition traffic, but it would be truly dismal if every home 
router tried to reset all the DSCPs I use.
- I strongly dislike an approach that drops packets with DSCPs ( except 
for admitted services). I think drop and even remark is a direct hurdle 
for apps to become able to use Diffserv across other network paths. If 
this is approach is taken by a wireless AP - then the network to which 
it connects is now deprived of application-chosen DSCPs. APs are used in 
many ways, e.g., as bridges to other infrastructure in IOT applications 
this recommendation would come in the way of assigning DSCPs for control 
applications in this case. It also produces a different DSCP behaviour 
when I use wifi AP to when I use a wired network segment. I therefore do 
not support this as the recommended approach, what do others think?
---
TEXT:
“it is RECOMMENDED that all packets marked to Diffserv Codepoints not
in use over the wireless network be dropped or remarked”
I strongly disagree with the following recommendation, which was 
formally in the network control section and I had not understood that 
this “all packets” actually was intended as a general recommendation to 
reset all DSCPs.

It becomes very difficult to use diffserv at all if each layer 2 network 
has different remark/drop policies. At the moment many networks neither 
remark nor drop - which I actually think is correct, they are layer 2 
devices and they have not been configured with any information about the 
Diffserv capabilities of the networks they talk to.
---
TEXT:
“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.”

I think it is useful case to describe, but I do not agree with the 
recommendation for this document.
---
TEXT:
“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.”

I share the concern here, and I think it is useful case to describe, but 
I do not agree with the recommendation for this document:
- In my home network?

I don’t agree with the current text in section 5.3, which begins:
"It is NOT RECOMMENDED to trust DSCP markings from devices that are not 
authenticated and authorized; these are considered untrusted sources."

---

I do not agree with this:
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.
- the discussion goes on to talk about an example with CS6 and CS7,
there may be a case for admission control to this class - or at least 
this PHB - but the general comment of requesting
rewriting of all codepoints goes against current practice as far
as I can see, and also is most unhelpful.

---
TEXT
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.
- I agree that you must protect operator infrastructure, and all people 
who use APs need to make decisions about which traffic to admit to the 
network at a particular QoS level. That does not mean I agree with 
thinking a device need to remark all my traffic because it is not what 
you think is best to cross a wireless/wired boundary.”

-------------------

I look forward to learning more what others think on this,

best wishes,

Gorry Fairhurst