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

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

Hi Gorry,

Thank you again for taking the time to review the draft.

Some comments/responses inline...

> -----Original Message-----
> From: Gorry Fairhurst [mailto:[e-mail]]
> Sent: Sunday, May 28, 2017 10:42 AM
> To: [e-mail]
> Cc: [e-mail]; Tim Szigeti (szigeti); [e-mail];
> Jerome Henry (jerhenry)
> Subject: 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.
> 

 [TS] 
I thought we already addressed this point on 5/24/17:

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.



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

 [TS] 
Apple has already paid attention to the recommendations in this draft and is now following these recommendations on over 1 billion iPads and iPhones. Similarly every Cisco AP shipped in the last 2 years includes these recommendations. 

The sooner we can reach a consensus, the sooner the rest of the industry will likely follow suit.


> Point 2: My concern is that the draft now recommends diffserv edge
> mechanisms that I think are inappropriate for a mapping draft.

[TS] 
Again - no new recommendations have been made. I'm not sure where this disconnect is coming from.


 I suggest the
> conditioning rules apply to specific deployment scenarios. 

[TS] 
The conditioning rules *do* apply to very specific scenarios, as detailed in Section 4.1

Section 4.1:
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.

   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.


> I also suggest this
> does not apply to all equipment - any recommendations need to be certain
> about context for deployment.

[TS] 
Deployment context is very clearly provide (as shown above).


>  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.
> 
[TS]
If the "802.11 equipment" referred to extends the IP infrastructure, then the recommendation above is to Map CS6 and CS7 to UP 7.

Otherwise, if the "802.11 equipment" referred to are endpoint devices, then can you provide a use-case where it would be beneficial to map these control-plane packet-markings to the 802.11 Access Category intended? If we recommend this, it presents a significant security vulnerability (i.e. the DoS attack vector caused by flooding packets downstream marked CS6 or CS7, which can disrupt service for ALL wireless devices in BOTH directions. Is this actually the recommendation you would prefer in this scenario? Please confirm.
 

> Point 3: The specific conditioning rules argue for pervasive remarking of all
> "unknown" codepoints - this position is a very specific view. 
[TS] 
Nowhere does the PS state to 'pervasively remark all unknown codepoints. 

What is stated is:

Section 2.1:

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.


An "unknown" codepoint is different from a codepoint that "is not in use".  If the administrator knows that a given codepoint is not in use, then he does well to remark or drop this traffic at the edge of the network. Again, it should be stressed as highlighted above, this recommendation *only* applies at the edge of the network (i.e. when the wireless edge is concurrently the edge of the network, as well as the edge of the Diffserv domain). Otherwise codepoints 41, 42, 43, 45, 47, 49, 50, 51, 52, 53, 54, 55, 57, 58, 59, 60, 61, 62, 63 (as well as unused codepoints in lower ranges) could all generate the DoS attack described above.



 > If stated in a PS
> for 802.11 this would have serious implications on the usefulness of diffserv,
[TS] 
I don't see how this is so. Across any network infrastructure (wired or wireless) Diffserv codepoints are untouched and unaltered.

The recommendation to remark or drop packets marked to control-plane and/or unused codepoints only applies at the edge of the network. 

I would argue that the wireless network becomes a significantly less-useful when *any* sender can cause a complete DoS of it by generating packets marked CS6 or CS7 (or various unused codepoints, as described above) in the upstream/downstream direction to/from devices that:
 1) do not participate in network control protocols and operations and
 2) are generating packet markings to codepoints that are not being used, per the administrative policy of the domain.

> 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.
> 
[TS] 
Can you elaborate on how you feel this should be "done correctly"?

i.e. are you saying that packets marked to control plane markings (or unused DSCP markings) should always be mapped to corresponding UP values? 

If so - does the rest of TSVWG agree? You guys beat us up pretty bad last WGLC due to security concerns. Now that we've tightened up the security considerations section (but kept all the recommendations the same), it seems that we're getting beat up again.

We simply can't do both. Either we present a universal mapping, complete with security vulnerabilities; or we present some deployment-specific recommendations to address very valid security concerns. 

Which is it to be?


> 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. 
[TS] 
The security section does include discuss trust and the need to remark and drop; and not just to protect the AP, but all devices on the (egalitarian) WLAN.


> 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.
> 
[TS] 
The text already contains these distinctions several times, as quoted above. 


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

[TS] 
The deployment model is clearly spelled out prior to this recommendation; the context is present, even if it wasn't quoted here.


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

[TS] 
OK - we're in agreement here.


> Between IP networks in my house this seems like the wrong thing to do. It
> may be used by a routing protocol 
[TS] 
The recommendation to drop or remark only applies at the edge of the network infrastructure. Is your routing protocol communicating to/from user endpoint-devices? 

If on the other hand, the wireless devices *extend* the network infrastructure, and are thus correctly and legitimately carrying routing protocols, this recommendation does not apply -- as is clearly stated multiple times.



(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?
> 
[TS] 
If you're using wireless devices to extend your network in your home, then as noted above, the recommendation to drop or remark does not apply.


> 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!
> 
[TS] 
This isn't a matter of whether the wireless deployment is intended for an enterprise, a public hot-spot, a home network, etc.

The only consideration that applies is whether or not the wireless AP represents the edge of the IP network; 
- if so, then a very valid security consideration is addressed by remarking control-plane and unused codepoints (in the downstream direction, that is, toward the endpoint devices); 
- if not, (i.e. the wireless infrastructure is extending the IP network) then codepoints are passed unaltered and mapped to the appropriate access-categories


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

 [TS] 
All of these context use only one of the two general deployment models discussed: 
- either the wireless AP represents the edge of the IP network (with only client endpoint devices downstream)
- or not.


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

 [TS] 
Are any downstream devices participating in IP control-plane protocols and operations? If so, then this fits the deployment model where wireless devices are extending the IP network infrastructure; if not, then it fits the wireless-edge model. It doesn't matter if this network is in a home, in an enterprise or in some other context.


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

 [TS] 
OK -we can remove that recommendation, but only if you and all of TSVWG are all ok with leaving any wireless network wide-open for a very easy DoS attack.


> 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

 [TS] 
There's no implication that they are equal. A choice is presented to the administrator, that is all.

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

[TS] 
Are you suggesting we change the context of the PS to Diffserv edge (only).

If so, that would be ironic. As originally that was the context and we were asked to include both deployment models (wireless-edge and extended-infrastructure).

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

 [TS] 
This was a direct comment from the last round of WGLC reviews to address the security concern that just because a device can mark DSCP doesn't necessarily mean that it should be trusted to by the network.


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

 [TS] 
No one suggested that these devices start authenticating to the AP; it's just a general security recommendation made at a TSVWG reviewer's direct request to highlight the security vulnerability to blanketly accept any markings from any device.

If the device is authorized to operate on your network, then fine. If it's not, then we're recommending not to trust it. 


> then I'm going to argue. Do these devices benefit from using DSCPs - very
> very likely.
> 
[TS] 
OK - and if someone takes control of the software running on your lightbulbs and begins blasting traffic marked CS7/UP7 from your lightbulb, causing a complete DoS of your WLAN, then you're still ok with this?

Look, we can change this if that's what you guys really want. But don't hammer us for security concerns, if (as it seems from this latest round) you actually want all of these removed.


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


[TS] 
The recommendation reads:
> It is NOT RECOMMENDED to trust DSCP markings from devices that are not
> authenticated and authorized; these are considered untrusted sources.

You're objecting to the recommendation to NOT trust markings from such devices; are you then really recommending the opposite? i.e. trusting the packet markings of unauthenticated and/or unauthorized devices?

Wow. I really feel like there's an over-rotation against security on this round of review.



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

[TS] 
OK - but again - you can't have it both ways. If you want everything to be trusted out-of-the-box, then you have to accept the security vulnerabilities that this presents.

However, I think that as 90%+ of wireless APs are deployed at the edge of the network (and are NOT being used to extend the IP network infrastructure), that this is the better recommendation for most users' out-of-the-box preferences.



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

[TS] 
That's not being recommended. Trusting DSCP is discussed immediately previously in Section 5.3 and is a perfectly valid option, even as described:

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:

Your home router scenario fits in well with what is being described here. As such, there's no need to interpret Sections 5.3 and 5.4 as presenting 'dismal' recommendations.

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

[TS] 
The dropping/remarking recommendation is made in the downstream direction, and only in deployment models where the AP represents the edge of the network. Hence there are no "other network paths" to choose from in this deployment model, and as such the objection does not apply.


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.

[TS] 
We've covered this ground already: if downstream devices are participating in network control protocols and operations, then the recommendation does not apply. 


 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.
> 
[TS] 
All DSCPs <> all DSCPs *not in use*


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

[TS] 
Until you're hit by an easily-achievable DoS attack by any app developer. In which case it may not seem as 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.


[TS] 
OK - I think we've been over this quite a few times. 

If TSVWG really wants us to remove all of these security recommendation, then we will. But I'm extremely hesitant to just yank all these out b/c of one reviewer's comments, especially when so many have expressed concern that the PS previously did not include enough security considerations.


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

[TS] 
OK - so again, to be clear, TSVWG really is recommending that we offer a PS that leave WLANs wide open from DoS attacks from any IoT device?

I just want to make sure there's consensus before I go an hack all these recommendations out.

> - In my home network?


[TS] 
I think you're overly-focused on your atypical home network, which (as has been previously discussed) can cleanly fit into one or the other deployment models presented in the PS, depending on whether you have any control-plane protocols in use downstream from the wired network. As such, I don't see any conflict between the recommendations in the PS and the home network scenario you keep referring to.

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


[TS] 
Haven't we already covered this ground already, more than once?

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


[TS] 
Again - seems like the same objections are being raised multiple times. 


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


[TS] 
It has nothing to do with that I think best crosses a wired/wireless boundary.

If the operator is using codepoints that cross the wired/wireless boundary, then these should be honored and preserved; this is clearly spelled out.

If the operator is using codepoints for control plane protocols beyond the wired/wireless boundary, then these should be honored and preserved; this is clearly spelled out.

If not, then these are recommended to be dropped at the edge of the network (only).

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


[TS] 
So do I. As the comments to date have been guiding us in the opposite direction.

-tim

> best wishes,
> 
> Gorry Fairhurst
> 
> 
>