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

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 23 May 2017 09:19:18 +0100

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.

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.

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

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, that would really mess-up ability to use diffserv in 
other segments 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. 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]

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

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

- 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

- 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

---

From: Fred Baker <[email-masked]>
Date: Tue, 23 May 2017 10:57:32 +0100

Thanks, Gorry.

Tim, I'm on vacation. You'll need to handle this. But this is similar to the concern I raised on our call regarding CS6/CS7.

Sent using a machine that autocorrects in interesting ways...

> On May 23, 2017, at 9:19 AM, Gorry Fairhurst <[email-masked]> wrote:
> 
> I have some comments on:
> 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.
> 
> 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.
> 
> 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. 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. 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.
> 
> 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, that would really mess-up ability to use diffserv in other segments 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. 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.
>

---

From: "Tim Szigeti (szigeti)" <[email-masked]>
Date: Wed, 24 May 2017 21:18:57 +0000

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:[email-masked]]
> Sent: Tuesday, May 23, 2017 1:19 AM
> To: Tim Szigeti (szigeti); [email-masked]; [email-masked]
> Subject: draft-ietf-tsvwg-ieee-802-11-02 - editorial comments
> 
> I have some comments on:
> 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.

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

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

Done.

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

> 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

---

From: [email-masked]
Date: Wed, 24 May 2017 22:28:07 +0100

.The top-level observation (I'll follow-up with another email if needed about
> 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.

---

From: "Tim Szigeti (szigeti)" <[email-masked]>
Date: Thu, 25 May 2017 01:43:47 +0000

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

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, May 24, 2017 2:28 PM
> To: Tim Szigeti (szigeti)
> Cc: [email-masked]; [email-masked]; Jerome Henry (jerhenry)
> Subject: Re: draft-ietf-tsvwg-ieee-802-11-02 - editorial comments
> 
> >> specific text) is that the latest revision discusses the way in which
> >> access points and wireless devices can change the DSCP marking or
> > 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:
> >
> > 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.

---

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 28 May 2017 18:42:12 +0100

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

---

From: <[email-masked]>
Date: Mon, 29 May 2017 09:57:16 +0000

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:[email-masked]] Im Auftrag von Gorry Fairhurst
Gesendet: Sonntag, 28. Mai 2017 19:42
An: [email-masked]
Cc: [email-masked]; Jerome Henry (jerhenry); [email-masked]
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.
---

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

-------------------

best wishes,

Gorry Fairhurst

---

From: Fred Baker <[email-masked]>
Date: Tue, 30 May 2017 12:09:50 -0700

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) <[email-masked]> wrote:
> 
> Hi Fred,
>

---

From: "Tim Szigeti (szigeti)" <[email-masked]>
Date: Thu, 1 Jun 2017 05:59:46 +0000

Hi Gorry,

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

Some comments/responses inline...

> Sent: Sunday, May 28, 2017 10:42 AM
> To: [email-masked]
> Cc: [email-masked]; Tim Szigeti (szigeti); [email-masked];
> Jerome Henry (jerhenry)
> Subject: draft-ietf-tsvwg-ieee-802-11-02 - Concerns about text on
> conditioning rules
> 
> 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. 

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

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

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

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

> the above context (i.e., in a different document with a different purpose the
> comments would be different).
> 
> represents not only the edge of the Diffserv domain, but also the edge of
> the network infrastructure itself.
> As such, only client
> - 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.

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

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

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

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

> authenticated and authorized; these are considered untrusted sources."

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

> Section 5.4 RECOMMENDED that the administrator treat the wireless edge as
> the edge of the Diffserv domain and explicitly set (or
> - 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).

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

-tim

---

From: "Tim Szigeti (szigeti)" <[email-masked]>
Date: Thu, 1 Jun 2017 06:14:50 +0000

Hi Ruediger,

Good to hear from you. 

Some comments/questions inline,

> From: tsvwg [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, May 29, 2017 2:57 AM
> To: [email-masked]
> Cc: Jerome Henry (jerhenry); [email-masked]; [email-masked]
> 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

> 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.
> 
> 
> mechanisms that I think are inappropriate for a mapping draft. I suggest the
> conditioning rules apply to specific deployment scenarios. I also suggest this
> about context for deployment. I think there is quite an opportunity for the
> "unknown" codepoints - this position is a very specific view. If stated in a PS
> resources. I can also see how CS6 and CS7 may need to be discussed and text
> may be used by a routing protocol (e.g. RPL as
> become able to use Diffserv across other network paths. If this is approach is
> case. It also produces a different DSCP behaviour when I use wifi AP to when
> remark nor drop - which I actually think is correct, they are layer 2 devices

---

From: "Tim Szigeti (szigeti)" <[email-masked]>
Date: Thu, 1 Jun 2017 06:18:21 +0000

Hi Fred,

Glad to hear your back from vacation.

A couple of comments inline...

> From: Fred Baker [mailto:[email-masked]]
> Sent: Tuesday, May 30, 2017 12:10 PM
> 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:
> 
> 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). 

[TS] 
The context is very clearly limited to WiFi networks where the AP represents the edge of the network, and not WiFi networks in general.

When the only devices downstream are end-user client devices, then routing protocols are not legitimately expected to be exchanged. 

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

[TS] 
We certainly don't think that. This is why the deployment model of wireless networks that extend the IP infrastructure (and over which routing traffic is legitimately exchanged) is clearly called out and addressed..

HTH clarify Fred.

-tim

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