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

["Tim Szigeti (szigeti)" <[e-mail]>]

Hi Ruediger,

Good to hear from you. 

Some comments/questions inline,

> -----Original Message-----
> From: tsvwg [mailto:[e-mail]] On Behalf Of
> [e-mail]
> Sent: Monday, May 29, 2017 2:57 AM
> To: [e-mail]
> Cc: Jerome Henry (jerhenry); [e-mail]; [e-mail]
> Subject: Re: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - Concerns about text
> on conditioning rules
> 
> 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

[TS] 
OK - but keep in mind that a single Diffserv mapping behavior for a commodity piece of hardware, regardless of how it's used, can present some significant security vulnerabilities. Are we sure that this is what we want to recommend in a PS?

. 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.

[TS] 
Won't that cause even more confusion? In this PS, there is a relatively minor part that addresses the exception use-case where APs are used to extend the infrastructure (and specifically relate to control plane markings only). Other than that, the mapping behavior is a universal recommendation. 

Would really a separate draft/PS be warranted for this minor use-case? That in all other respects would be the same overall recommendations?

Please elaborate/clarify.

TIA.

-tim

> 
> 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
> 
> 
>