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

[Fred Baker <[e-mail]>]

I'm now back from vacation.

Here's where our views seem to diverge. You argue that you are basing the comment about dropping CS6 on RFC 4594. What RFC 4594 says, however, is:

   o  Drop or remark CS7 packets at ingress to DiffServ network domain.
   o  CS7 marked packets SHOULD NOT be sent across peering points.
      Exchange of control information across peering points SHOULD be
      done using CS6 DSCP and the Network Control service class.

It doesn't say to drop CS6, and the argument for dropping CS6 is that routing traffic is not exchanged on WiFi networks (which is the assumption I commented on). That is true today, but may not be true in the future. I think the assumption that routing traffic will never be exchanged on WiFi networks is a dangerous assumption long term. 

> On May 24, 2017, at 6:43 PM, Tim Szigeti (szigeti) <[e-mail]> wrote:
> 
> Hi Fred,
> 
>> For CS7 (and any DSCP value not implemented in the domain) I would agree
>> that it should be remarked or dropped. For CS6, recall that I have pointed out
>> the assumptions that WiFi is the edge of the diffusers domain and has no IP
>> layer routing across it. I think, and have said before that I think, that is a
>> limiting assumption.
> 
> Nothing is being assumed here Fred. Two distinct recommendations are being made:
> 
> In the case where the wireless access-point represents the edge of the network (and thus simultaneously the edge of the Diffserv domain), then a recommendation is being made to remark or drop packets marked CS6 or CS7 (as there are no downstream devices participating in network control exchanges, and preserving these markings presents an easy attack-vector for WLAN DoS).
> 
> In the deployment model where the wireless access-point is NOT the edge of the network, then this recommendation does not apply (as brought out in Section 4.1.1).
> 
> A single recommendation simply will not ensure secure and consistent QoS treatment in both wireless deployment models.
> 
> -tim
> 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> Sent: Wednesday, May 24, 2017 2:28 PM
>> To: Tim Szigeti (szigeti)
>> Cc: [e-mail]; [e-mail]; Jerome Henry (jerhenry)
>> Subject: Re: draft-ietf-tsvwg-ieee-802-11-02 - editorial comments
>> 
>> .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;
>> 
>> For CS7 (and any DSCP value not implemented in the domain) I would agree
>> that it should be remarked or dropped. For CS6, recall that I have pointed out
>> the assumptions that WiFi is the edge of the diffusers domain and has no IP
>> layer routing across it. I think, and have said before that I think, that is a
>> limiting assumption.