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

[<[e-mail]>]

Hi Gorry,

you suggest to limit the scope of draft-ietf-tsvwg-ieee-802-11 to specify a default Diffserv mapping behavior for a commodity piece of Hardware. Any IP related policies to be deployed if that piece of Hardware is used in a specific deployment should be separated and become part of a document in its own. 

I'm not a Wifi expert, but to me there's a point in your proposal.

Regards,

Ruediger

PS: I also thought about comparing the separation of mapping and policy to Diffserv-Intercon, which covers both. There we had some policy related discussions, about bleaching, for example. The latter is scoped for a specific deployment however.


-----Ursprüngliche Nachricht-----
Von: tsvwg [mailto:[e-mail]] Im Auftrag von Gorry Fairhurst
Gesendet: Sonntag, 28. Mai 2017 19:42
An: [e-mail]
Cc: [e-mail]; Jerome Henry (jerhenry); [e-mail]
Betreff: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - Concerns about text on conditioning rules

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