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

[<[e-mail]>]

Hi Tim,

then I try to elaborate. You responded to Fred

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

The scope could express that more clearly and section 1 and 1.3 are not very clearly stating that.

I further read into section 4, which specifies behavior for traffic from a fixed network to a wireless access. To me that means, that IP layer/Diffserv policy control is within the fixed network. CS6/CS7 marked IP traffic went through that policy control.  Section 4.1.1 of draft..ieee-802 reads

   "Before discussing a mapping recommendation for Network Control
   traffic marked CS6 DSCP, it is interesting to note a relevant
   recommendation from [RFC4594] pertaining to traffic marked CS7 DSCP:
   in [RFC4594] Section 3.1 it is 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."

I quoute from RFC 4594

"o  Drop or remark CS7 packets at ingress to DiffServ network domain."
                                 ^^^^^^^^^
I think section 4 of draft..ieee-802 discusses "egress".

Further, RFC4594 says:
   "CS7 DSCP value SHOULD
   be reserved for future use, potentially for future routing or control
   protocols.  Network administrators MAY use a Local/Experimental DSCP;
   therefore, they may use a locally defined service class within their
   network to further differentiate their routing and control traffic."

Drop or even remark at an egress isn't applicable in that case, I think.

Operational aspects may be considered at the network egress too:

- I prefer "remark unknown DSCP" to default. A misconfiguration of the 
  provider may cause packets to be marked by an unexpected DSCP. If that 
  traffic is dropped, the customer may not have been doing anything wrong, 
  but his traffic is dropped by the AP.
  "Be liberal in what you accept" seems to be the better guidance for the AP.

- consider a case of a HW supporting only 4 queues. One shares CS6 and 
  CS7 and a simple implementation may enforce CS6 and CS7 to use that 
  queue. If your recommendations are implemented and CS6 _and_ CS7 can't 
  be used, the entire queue is wasted.

Related to a WiFi network edge / demarcation router as a minimum, 
I'd suggest "SHOULD remark unexpected markings to default and MAY drop" in 
section 4, if unexpected markings are concerned. Further I think, 
"CS7 MAY be allowed for experimental local use", to me for whatever 
service.

Section 4.1.1 was not the only one Gorry was concerned about. For 
the time being I prefer to limit my comments to this section.

Regards, Ruediger


-----Ursprüngliche Nachricht-----
Von: Tim Szigeti (szigeti) [mailto:[e-mail]] 
Gesendet: Donnerstag, 1. Juni 2017 08:15
An: Geib, Rüdiger; [e-mail]
Cc: Jerome Henry (jerhenry); [e-mail]; [e-mail]
Betreff: RE: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - Concerns about text on conditioning rules

Hi Ruediger,

Good to hear from you. 

Some comments/questions inline,

> -----Original Message-----
> From: tsvwg [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: Monday, May 29, 2017 2:57 AM
> To: [e-mail]
> Cc: Jerome Henry (jerhenry); [e-mail]; [e-mail]
> Subject: Re: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - Concerns about 
> text on conditioning rules
> 
> Hi Gorry,
> 
> you suggest to limit the scope of draft-ietf-tsvwg-ieee-802-11 to 
> specify a default Diffserv mapping behavior for a commodity piece of 
> Hardware

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

. Any
> IP related policies to be deployed if that piece of Hardware is used 
> in a specific deployment should be separated and become part of a 
> document in its own.

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

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

Please elaborate/clarify.

TIA.

-tim

> 
> I'm not a Wifi expert, but to me there's a point in your proposal.
> 
> Regards,
> 
> Ruediger
> 
> PS: I also thought about comparing the separation of mapping and 
> policy to Diffserv-Intercon, which covers both. There we had some 
> policy related discussions, about bleaching, for example. The latter 
> is scoped for a specific deployment however.
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: tsvwg [mailto:[e-mail]] Im Auftrag von Gorry 
> Fairhurst
> Gesendet: Sonntag, 28. Mai 2017 19:42
> An: [e-mail]
> Cc: [e-mail]; Jerome Henry (jerhenry); 
> [e-mail]
> Betreff: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - Concerns about text 
> on conditioning rules
> 
> This email describes a number of concerns with the inclusion of 
> conditioning rules in the 802-11 draft.
> 
> The title and abstract of the draft describe a mapping function.
> However, the changes in rev -02 give me serious doubts about the 
> remarking and drop recommendations, which I consider for a diffserv edge.
> 
> Point 1: I think the WG need to be very clear about the context of 
> recommendations. I'd expect the class mappings to PHBs to be applied 
> in all equipment that adheres to IETF standards. This should I think 
> be the default for all APs - and I'd hope most vendors would start paying attention.
> 
> Point 2: My concern is that the draft now recommends diffserv edge 
> mechanisms that I think are inappropriate for a mapping draft. I 
> suggest the conditioning rules apply to specific deployment scenarios. 
> I also suggest this does not apply to all equipment - any 
> recommendations need to be certain about context for deployment. I 
> think there is quite an opportunity for the present text on remarking 
> and drop in the current revision to be wrongly interpreted. I 
> seriously fear the inclusion of remarking and drop recommendations can 
> make this become an impediment to sender marking of DSCP across IP paths that happen to include 802.11 equipment.
> 
> Point 3: The specific conditioning rules argue for pervasive remarking 
> of all "unknown" codepoints - this position is a very specific view. 
> If stated in a PS for 802.11 this would have serious implications on 
> the usefulness of diffserv, and I think the IETF really has to 
> consider these in detail before it takes this approach for 802.11.
> 
> ------------
> 
> So, starting with Point 1: I noted previously that I do see real 
> benefit in recommendations on how to map DSCPs using 802.11 and I 
> suspect, if done correctly, this can greatly ease the consistent use of DSCP.
> 
> It may be that the security considerations need to discuss the trust 
> of markings and the possible need to remark or drop to protect the AP 
> resources. I can also see how CS6 and CS7 may need to be discussed and 
> text may have to say things about these when the AP is forms the edge 
> of a network.
> 
> TEXT:
> Traffic marked CS7 DSCP
> SHOULD be dropped or remarked at this edge (as it is typically unused, 
> as CS7 SHOULD be reserved for future use).
> - section 4.1.1. recommends drop or remark, and I struggle here to 
> know that this is the correct statement to make in general for 802.11 usage.
> Is it strictly necessary to drop CS6 traffic at an AP, that seems 
> plausible in managed (e.g. enterprise) deployment, or on the upstream 
> to an ISP in a home deployment (maybe in some places the operator own the AP?).
> Between IP networks in my house this seems like the wrong thing to do. 
> It may be used by a routing protocol (e.g. RPL as
> noted) could use this DSCP, why can I not use a layer 2 technology to 
> move these packets between parts of my IP network with the DSCP that 
> has been assigned?
> 
> So, really I question if the current phrasing is the correct 
> recommendation. I think the WG needs to choose appropriate words here 
> but that needs I think to be balanced by explaining that these 
> codepoints may be used within a house or whatever for routing and 
> functions. - They are not just for the upstream ISP!
> 
> Point 2: As you noted, there is a wide variety of 802.11 equipment and 
> uses and you highlight two distinct deployment models. 802.11 uses are 
> really diverse - they include managed environments in Enterprises, 
> public wifi access, home networks, use as layer infrastructure in a 
> very general sense, bridging to other layer 2 infrastructure (zigbee, etc).
> 
> There now follows concerns about the new text, which largely stems 
> from the above context (i.e., in a different document with a different 
> purpose the comments would be different).
> 
> I am not sure this text is helpful:
> " In most commonly-deployed WLAN models, the wireless access point 
> represents not only the edge of the Diffserv domain, but also the edge 
> of the network infrastructure itself.
> As such, only client
> devices (and no infrastructure devices) are downstream from the access 
> points in these deployment models.
> "
> - Again, there are many cases where this also not the same as well. I 
> have a number of APs in my house, and for that matter a zigbee bridge 
> that connects IoT devices. For many flows the AP is one hop to the DSL 
> modem, but flows also exist between endpoints in the house - e.g. to 
> deliver TV content across my home network, or to turn on/off lights or 
> simply access the house computer from my laptop.
> 
> On Point 3: I think it may be wrong to recommend this:
> TEXT:
> "
> In such deployment models,
> it is RECOMMENDED that all packets marked to Diffserv Codepoints not 
> in use over the wireless network be dropped or remarked at the edge of 
> the Diffserv domain, as will be discussed in detail in Section 4.1.1."
> - I would really hope APs do not do this, except if they within the 
> control network of an upstream service provider that has configured 
> consistent rules at the Apps for the service they offer.
> 
> I see the next para effectively implies SHOULD NOT remark or drop, in 
> some other case - but even though I suspect you are hoping for the 
> correct thing I do not see this clearly enough to feel confident that 
> others will always understand what to do.
> 
> - It also suggests drop and remark are equal, they are not - the there 
> behaviour i) (carry as DF (ii) Remark to DF (iii) Drop have quite 
> different implications to those trying to write apps that wish to use diffserv.
> ---
> TEXT:
> "
> Thus the QoS treatment of packets at the access point will depend on 
> the position of the AP in the network infrastructure and on the WLAN 
> deployment model."
> - Oh indeed, but the more I read, the more I'd really rather see how 
> to handle edge treatment as a separate document that clearly explains 
> that at a diffserv edge you do conditioning and what are the 
> implications of the different approaches.
> ---
> TEXT:
> It is NOT RECOMMENDED to trust DSCP markings from devices that are not 
> authenticated and authorized; these are considered untrusted sources.
> - Question: What is the intent here? Are you encouraging DSCP 
> remarking (I hope not), or are you saying that the UP marking is 
> assigned using a local policy rather than from the DSCP?
> 
> - I suspect the context here is not about mapping it is about managed 
> use of an AP network. That varies, and I really think this is not the 
> document to discuss that. The security considerations could note this 
> - but quite honestly, if you expect my light bulbs and TV sets to 
> start authenticating with the AP, then I'm going to argue. Do these 
> devices benefit from using DSCPs - very very likely.
> 
> - Of course, if you were offering infrastucture to a range of 
> customers then you may need to consider these issues. Saying SHOULD 
> NOT trust seems to suggest you threaten to remark? or just to carry as 
> best-effort within this network?
> (Back to point 2: We all know that public radio networks need to 
> consider resource models, but this is not a PHB mapping question.)
> ---
> TEXT:
> "Alternatively, if a network device is configured to operate in an 
> untrusted manner, then it would remark packets as these entered the 
> device, typically to DF (or to a different marking value at the 
> network administrator's preference). Note:
> The terms "trusted" and "untrusted" are used extensively in RFC 4594."
> - This is NOT what I want from an out-of-the-box AP configuration, and 
> I think this muddies the deployment context.
> ---
> 
> More on point 3: I really do not agree with the text in section 5.4:
> TEXT:
> 5.4. Upstream DSCP Marking at the Wireless Access Point
> 
> An alternative option to mapping is for the administrator to treat the 
> wireless edge as the edge of the Diffserv domain and explicitly set 
> (or reset) DSCP markings in the upstream direction according to 
> administrative policy. This option is RECOMMENDED over mapping, as 
> this typically is the most secure solution, as the network 
> administrator directly enforces the Diffserv policy across the IP 
> network (versus an application developer and/or the wireless endpoint 
> device operating system developer, who may be functioning completely independently of the network administrator).
> 
> - Comment. I see the alternative and realise that the edge of a DS 
> domain can condition traffic, but it would be truly dismal if every 
> home router tried to reset all the DSCPs I use.
> - I strongly dislike an approach that drops packets with DSCPs ( 
> except for admitted services). I think drop and even remark is a 
> direct hurdle for apps to become able to use Diffserv across other 
> network paths. If this is approach is taken by a wireless AP - then 
> the network to which it connects is now deprived of application-chosen 
> DSCPs. APs are used in many ways, e.g., as bridges to other 
> infrastructure in IOT applications this recommendation would come in 
> the way of assigning DSCPs for control applications in this case. It 
> also produces a different DSCP behaviour when I use wifi AP to when I 
> use a wired network segment. I therefore do not support this as the recommended approach, what do others think?
> ---
> TEXT:
> "it is RECOMMENDED that all packets marked to Diffserv Codepoints not 
> in use over the wireless network be dropped or remarked"
> I strongly disagree with the following recommendation, which was 
> formally in the network control section and I had not understood that this "all packets"
> actually was intended as a general recommendation to reset all DSCPs.
> 
> It becomes very difficult to use diffserv at all if each layer 2 
> network has different remark/drop policies. At the moment many 
> networks neither remark nor drop - which I actually think is correct, 
> they are layer 2 devices and they have not been configured with any 
> information about the Diffserv capabilities of the networks they talk to.
> ---
> TEXT:
> "Section 4.1.1 RECOMMENDED that all packets marked to Diffserv 
> Codepoints not in use over the wireless network be dropped or remarked 
> at the edge of the Diffserv domain. This recommendation may help 
> mitigate a Denial-of-Service attack vector that exists at 
> wired-to-wireless edges in the downstream direction. For example, 
> consider a malicious user flooding traffic marked CS7 or CS6 DSCP 
> toward the WLAN. These codepoints would map by default to UP 7 and UP 
> 6 (respectively), both of which would be assigned to the Voice Access 
> Category (AC_VO). Such a flood could cause a Denial- of- Service to wireless voice applications."
> 
> I think it is useful case to describe, but I do not agree with the 
> recommendation for this document.
> ---
> TEXT:
> "Section 5.3 made it clear that it is NOT RECOMMENDED to trust DSCP 
> markings from devices that are not authenticated and authorized, as 
> these are considered untrusted sources. This is especially relevant 
> for IoT, as billions of devices are being connected to IP networks, 
> many of which have little or no security."
> 
> I share the concern here, and I think it is useful case to describe, 
> but I do not agree with the recommendation for this document:
> - In my home network?
> 
> I don't agree with the current text in section 5.3, which begins:
> "It is NOT RECOMMENDED to trust DSCP markings from devices that are 
> not authenticated and authorized; these are considered untrusted sources."
> 
> ---
> 
> I do not agree with this:
> Section 5.4 RECOMMENDED that the administrator treat the wireless edge 
> as the edge of the Diffserv domain and explicitly set (or
> reset) DSCP markings in the upstream direction according to 
> administrative policy.
> - the discussion goes on to talk about an example with CS6 and CS7, 
> there may be a case for admission control to this class - or at least 
> this PHB - but the general comment of requesting rewriting of all 
> codepoints goes against current practice as far as I can see, and also is most unhelpful.
> 
> ---
> TEXT
> Suffice it to say that
> the security of the devices and networks implementing QoS, including 
> QoS mapping between wired and wireless networks, SHOULD be considered 
> in actual deployments.
> - I agree that you must protect operator infrastructure, and all 
> people who use APs need to make decisions about which traffic to admit 
> to the network at a particular QoS level. That does not mean I agree 
> with thinking a device need to remark all my traffic because it is not 
> what you think is best to cross a wireless/wired boundary."
> 
> -------------------
> 
> I look forward to learning more what others think on this,
> 
> best wishes,
> 
> Gorry Fairhurst
> 
> 
>