Re: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - editorial comments

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

Hi Gorry,

Thanks again for taking the time to review and comment on this draft.

A few responses inline...


> -----Original Message-----
> From: Gorry Fairhurst [mailto:[e-mail]]
> Sent: Tuesday, May 23, 2017 1:19 AM
> To: Tim Szigeti (szigeti); [e-mail]; [e-mail]
> Subject: draft-ietf-tsvwg-ieee-802-11-02 - editorial comments
> 
> I have some comments on:
> https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11-02
> 
> and also an observation about the new text in the last revision.
> 
> The top-level observation (I'll follow-up with another email if needed about
> specific text) is that the latest revision discusses the way in which access
> points and wireless devices can change the DSCP marking or drop traffic
> because of the DSCP marking.
> 

I'd like to first stress the point that the remarking and dropping recommendations of network control traffic (marked CS6/CS7) at the edge of the wired-to-wireless network (as made in Section 4.1.1) were part of the original 2015 draft, and are not new recommendations in this latest revision. 

Additionally, these recommendations are drawn from similar recommendations made in RFC 4594-Section 3.2 which:

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

Our argument is that when the wireless access point represents the edge of the network infrastructure (and thus the edge of the Diffserv domain), this recommendation should hold; otherwise a very easily exploitable DoS attack-vector (as discussed in Section 8-Security Considerations) is presented: namely, that devices can flood traffic marked CS6/CS7 upstream and/or downstream to/from the wireless network, causing a DoS for all other traffic flows; furthermore, as no network devices would be located downstream in such scenarios, then no such traffic would be legitimately marked to CS6/CS7.

NOTE: in the cases where the wireless edge is NOT the edge of the network infrastructure, this recommendation would not apply, as clearly expressed in Section 4.1.1.

 
 
> My point is that I do see real benefit in recommendations on how to forward
> DSCPs across APs and I suspect, if done correctly, this can greatly ease the
> consistent use of DSCP. I like the way this maps PHBs, and I hope this can
> allow all equipment to support a well-understood default treatment.
> 

We're in agreement in principle on this point. We would like the mappings to be as broadly encompassing as possible; however, a single recommendation that works in a deployment model where the AP represents the network edge (90%+ use-case), may not work in deployment models where the AP extends the IP network (e.g. wireless-mesh or an AP-to-AP infrastructures, etc.). As such, we are seeking to make secure and consistent marking recommendations that are nonetheless flexible enough to accommodate these distinct use-cases.


> However, I think the new remarking and drop recommendations in this new
> version are not helpful in this general context as **general guidance** to
> manufacturers and users of 802.11 equipment. 


Again, I feel the need to stress that the remarking and dropping recommendations are not new in this version, but have been present from the original draft in 2015.


> Although RFC 4594 Section 3.1
> (etc) allows a diffserv domain to configure polices at the edge, the types of
> policy (and security and QoS implications) that are needed depends on the
> deployment scenario - and I do not see the current rules as being good
> defaults for all of the wide variety of 802.11 equipment. 


Again - agreed. There is no single one-size-fits-all recommendation that provides consistent QoS treatment in a secure manner for both wireless-edge and wireless-extended-infrastructure deployment model scenarios. This is why these two distinct use-cases are separated and explicit recommendations are made for each. 


> What works in
> managed environments in enterprises, public wifi access, isn't what is best
> when I place it in my home network, use as a layer 2 infrastructure in a very
> general sense, as a bridge to other layer 2 infrastructure (zigbee, etc), etc.
> 

The security recommendations offered for wireless-edge scenarios apply to all such, including enterprise, public wifi and even home networks. For every one of these wireless-edge deployment scenarios, it would be a protection to the network to prevent packets being sent/received from wireless endpoint devices with markings intended for network infrastructure control flows. Such endpoint devices would never be legitimately sending or receiving such flows.

However, the recommendations to remark or drop packets marked CS6/CS7 (i.e. network control traffic flows) would not apply in the deployment cases where the network was extended over wireless bridges, as has been clearly called out in Section 4.1.1. 

Making a single recommendation for these two very distinct wireless deployment scenarios would require a tradeoff: either the wireless-edge deployments (which represent the majority use-case) become less secure (as any type of marking is honored, including network control flows to/from devices which should not be sending nor receiving such flows), or the wireless extended infrastructures do not benefit from protection of their control plane protocols. Neither option is beneficial to both scenarios; and as such two distinct recommendations are made; one for each.


> I, for one, would not wish to see a plethora of simple APs to implement
> default dropping of classes they do not have PHB support for and remarking
> of other packets to what they see as the best DSCP for my traffic - to me,

OK - but the tradeoff here requires leaving wireless-edge networks exposed to the simple DoS attack-vector of flooding network control traffic to/from devices that do not legitimately participate in network control functions. Is that the tradeoff that TSVWG is recommending? We got beat up pretty bad in WGLC on predominantly security concerns, such as this one. 


> that would really mess-up ability to use diffserv in other segments of the
> network

Why would it mess up ability to use Diffserv in other segments of the network? In the case where the wireless AP represents the edge of the network (i.e. the deployment-model where this recommendation applies), remarking or dropping flows makes no difference to how these flows would be treated in any other part of the network. 


 - and is really quite at odds with what I see is currently possible
> where most markings are actually being passed through most network links.
> 
> Specifically, I fear the present text could become an impediment to sender
> marking of DSCP across IP networks in general.

Consistent and in line with RFC 2474, 2475 and 8100, we offer recommendations for sender markings  in Section 5.3, albeit with the appropriate security caveats (that the previous round of commenters explicitly requested us to make).


> I am not even sure this is the
> correct document to talk about what I would call managed
> 802.11 networks, but if it reallty is - then I think this needs to be clearly
> separated from other uses.
> 
> The editorial comments are below,
> 
> best wishes,
> 
> Gorry Fairhurst
> 
> ----
> 
> - rephrase?
> OLD:
> a [RFC3246] EF PHB service
> NEW:
> an EF PHB service [RFC3246]

Done.

> 
> - rephrase?
> OLD:
> a [RFC2597] AF PHB service
> MEW:
> an AF PHB service [RFC2597]
> 

Done.

> - Comment, if there is no other classification or marking policy enforcement
> point, then this sets the DSCP that will be used on the remainder of the
> Internet path. Could we say that?
> TEXT:
> This derived DSCP value
> is then used for QoS treatment between the wireless access point and the
> nearest classification and marking policy enforcement point (which may be
> the centralized wireless LAN controller, relatively deep within the network).


Added.

> 
> 
> - Comment, the new text below reads like this is always the case, whereas
> there is now work in the IETF to revise these definitions. I think there is value
> in pointing to the WG ID on this topic as informational, and I think we need to
> reconsider citing "draft-tsvwg-le-phb" as well as RFC3662.
> TEXT:
> and causing legitimate business-relevant High-Throughput Data to receive a
> [RFC3662] Lower Effort PDB, for which it is not intended


Added.

> 
> - Question, is it helpful to insert /present/ before wireless device to suggest
> that this is not necessarily the preferred approach.
> TEXT:
> Most wireless device operating systems generate UP values by the same
> method as described in Section 2.2 (i.e


Added.

(A new version has been submitted for upload with the above editorial comments made. This will be posted shortly.)


Thank you again Gorry for the review and comments.

-tim