Subject: [tsvwg] David Black's review of draft-ietf-tsvwg-ieee-802-11-01

From: "Black, David" <[email-masked]>
Date: Wed, 4 Jan 2017 21:21:36 +0000

While it's slightly after the end date of WG Last Call, I have done a review of this draft, as an individual, although as WG chair, I'll comment that the major issues MUST be addressed and the minor issues SHOULD be addressed - a revision of the draft will definitely be needed.  We'll also need to find some more people to review the draft, as we like to see more than one WGLC review, and I'm not able to review the discussion of how WiFi works.

Review of: draft-ietf-tsvwg-ieee-802-11-01
Reviewer: David Black
Date: January 4, 2017
-------------------------------------------------------

This draft is a significant piece of very useful work that the
IETF should publish as an RFC.  I have now done a detailed review
and found a number of things, starting with major security and
Diffserv architecture issues.  Unfortunately, I'm not able to
review Section 6's discussion of how 802.11 (WiFi) works for
correctness, so someone who is an 802.11 expert will need to
check that text.

This review may seem long and daunting - I'd ask the authors to
take this as a backhanded compliment as I only invest this much
review time/effort in work that is seriously good and important
- overall, the recommended mappings are solid, and the problems
are in the surrounding material and some of the details.  In
20/20 hindsight, I wish I'd found the time to do this level of
review a year ago, and apologize for not doing so.

--- Major Issues ---

[1] Security!!

This text in Section 3 ...

   o  trust the DSCP markings set by wireless endpoint devices (as
      discussed in Section 5.3)

... strikes me as sufficient to send a knowledgeable security
directorate reviewer into low earth orbit.  

I would hope the recent IoT-botnet-based DDoS attacks make it
painfully clear that the operating systems and applications in
endpoint devices cannot be trusted, at least as the term "trust" is
used here.

The only cases where I'd find some form of trust argument plausible
are where the network operator controls device software/firmware
(e.g., dumb phones, un-rooted smartphones in some cases), and even
then, latent vulnerabilities can enable introduction of untrusted code.

IMNSHO, Section 5.3 needs a complete rethink and rewrite.
[In My Not-So-Humble Opinion]  The Security Considerations in
section 8 also need attention, as this topic is not mentioned there.

Authors - please let me know whether I should try to find a
security expert to help.

[2] Diffserv domain/region boundaries.

The same bullet in section 3 that exhibits the security problem:

   o  trust the DSCP markings set by wireless endpoint devices (as
      discussed in Section 5.3)

is also incorrect if the wireless-to-wired network interconnect
is a Diffserv domain boundary, especially if that Diffserv
domain boundary is also a Diffserv region boundary.  It may suffice
to call out this exception, but see RFC 2475 for further discussion.

There's actually good material on this topic elsewhere in the draft
that could form the basis for a higher-level discussion on Diffserv
boundaries.  In  the downstream direction, there's some useful material
in Section 4.1.1, but that's too specific a section (network control)
for this discussion.  There also appears to be some useful material
on upstream traffic in Section 5.2.

I think a new section on this topic is called for as it applies to
traffic in both directions.

[3] Section 4 - Relationship to RFC 4594

In Section 4, significant discussion, and often actual text are
reproduced from RFC 4594, without making it clear that RFC 4594
is the source.  For example, Section 4.1 (without subsections) is
entirely from RFC 4594 (there is nothing in there that isn't
covered by RFC 4594).  All of section 4 needs to be edited to
indicate what concepts are repeated from RFC 4594 vs. what is new
to this draft. 

--- Minor Issues ---

[A] Optimality s/b Consistency

Starting with this text in the Abstract:

   and, as such, to optimize
   wired-and-wireless interconnect QoS.

the draft is written in terms of optimizing and (even worse)
optimal QoS.  The latter is not realistic - a fine companion
to the tooth fairy, Santa Claus and the Easter Bunny.  I
suggest changing from optimal QoS as the goal to consistent
QoS, e.g.:

   and thereby enable consistent
   wired-and-wireless QoS among interconnected networks.

This needs to be done throughout the draft.  All related terms
need to be changed, e.g., "sub-optimal" -> "inconsistent" or
"less consistent"

[B] 1.2.  Interaction with RFC 7561

   The GSMA specification was developed without reference to the service
   plan documented in Section 1.1, and conflicts both in the services
   specified and the code points specified for them.

The above sentence is unclear.   Section 1.1 does not describe
a service plan (e.g., that term doesn't occur there), and the nature
of the conflict is unclear.  I suggest focusing this sentence to say
that RFC 7561 and RFC 4594 conflict and add text to section 1.1 about
the role of RFC 4594.   The term "service plan" is also vague in this
context, and probably should not be used - see RFC 4594 for ideas on
what to say instead.

[C] This draft needs a terminology section, as the initial expansions
of acronyms are sprinkled across a number of places including the
Abstract.  The terminology section needs to include AP, UP, DSCP, WiFi,
QoS, and all the acronyms in the 6.x section headings.  Also, please
ensure that WiFi is never hyphenated across a line break as Wi-Fi.
While this concern is nominally editorial, it is a significant hurdle
for document accessibility to non-experts, and hence I've tagged it as
a minor issue.

[D] Section 2.  Comparison and Default Interoperation ...

"Comparison" ->  "Service Comparison" to fit the scope of the section.

   The following comparisons between IEEE 802.11 and DiffServ should be
   noted:

"comparisons" -> "service comparisons" OR
insert "services" after "Diffserv" 

Also note that lower case 's' is the correct capitalization of Diffserv
(i.e., not camel-case DiffServ).

[E] 2.2.  Default UP-to-DSCP Mappings and Conflicts

   o  Mapping UP 4 (Multimedia Conferencing and/or Real-Time
      Interactive) to CS4, thus losing the ability to distinguish
      between these two distinct traffic classes

Need to explain somewhere how to differentiate between these
two distinct traffic classes for this bullet item and following ones.

Also, are these traffic classes defined by RFC 4594 or 802.11?
That's not clear for bullets after the first one in the list
where the quoted text is the second bullet item.

[F] 4.1.1.  Network Control Protocols (DSCP usage)

   Following this recommendation, 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.

This general recommendation should not be buried in a section on
network control protocols.  At the very least it should be elevated
to section 4 and included in the summary in section 3.  Also, this
recommendation originates from RFC 2475 and should be described
accordingly, although the recommendation may not be stated as
concisely in RFC 2475 by comparison to RFC 4594.

[G] 4.1.1.  Network Control Protocols (drop CS6 at domain boundaries)

   For example, in most commonly deployed 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, and in line
   with the above recommendation, 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).  So too SHOULD Network Control
   traffic marked CS6 DSCP, considering that only client devices (and no
   network infrastructure devices) are downstream from the wireless
   access points in these deployment models.

This text bothers me, starting with the last sentence being incorrect
if there are AP-to-AP WiFi hops.  A specific concern is that I think
this recommendation to drop CS6 prevents running routing protocols across
the wireless-to-wired boundary in this case.  While not typical, I believe
that this can be done, although in the specific case of routing protocols,
the boundary AP ought to be a participant in any IGP (internal) routing
protocol.  OTOH, I suppose one could run an EGP (external) routing protocol,
e.g., BGP here, and the AP is unlikely to be an inter-domain BGP speaker.

Some more discussion seems to be in order, and the discussion should
probably also note that encapsulated routing protocols for encapsulated
or overlay networks (e.g., VPN, NVO3) are not network control traffic
for any physical network at the AP, and hence SHOULD NOT be marked
with CS6 in the first place.

[H] 4.2.7.  Low-Latency Data

   In line with the recommendations made in Section 4.2.2, mapping Low-
   Latency Data to UP 3 may allow such to receive a superior level of
   service via transmit queues servicing the EDCAF hardware for the Best
   Effort Access Category (AC_BE).

This cross-reference to Section 4.2.2 is hard to follow.  The discussion
of EDCAF hardware behavior should be factored out to somewhere near the
start of Section 4.  While this concern is nominally editorial, it is a
significant clarity problem for non-experts, and hence I've tagged it as
a minor issue.

[I] 4.3.  DSCP-to-UP Mapping Recommendations Summary

In Figure 1, the "(See Section 4.1.1)" text for Network Control
traffic won't suffice for an implementer who is looking at the 4.3
summary because Section 4 in its entirety caused a tl;dr [too long;
didn't read] reaction.  Please add a short paragraph summarizing
what to do (always drop CS7, drop CS6 at Diffserv boundaries,
otherwise map CS6 to ...).

[J] 5.1.  Upstream DSCP-to-UP Mapping

   it is RECOMMENDED that
   such wireless client operating systems utilize instead the same DSCP-
   to-UP mapping recommendations presented in Section 4 and/or fully
   customizable UP markings.

I don't understand "and/or fully customizable UP markings."  As written,
this allows arbitrary mappings to be consistent with the recommendation
which is surely not what was intended.  I suggest ending the sentence with
a period after "Section 4" and handling customizable UP markings in a
separate sentence.

--- Editorial/Nits ---

- Abstract

OLD
  The purpose of this document is to propose
NEW
  This document specifies

- 1. Introduction

OLD
   Wireless has become the medium of choice for endpoints connecting to
   business and private networks.
NEW
   Wireless has become a frequently used medium for endpoints connecting to
   business and private networks.

Original text overstates the point.

OLD
   other challenges relate to the fact that the
   802.11 standard is not administered by the standards body that
   administers the rest of the IP network.
NEW
   other challenges relate to the fact that the
   802.11 standard is not administered by the same standards body
   as IP networking standards.

The IETF does not administer any IP networks.

-  1.1.  Related work (Editorial)

   o  [RFC2475] defines a DiffServ architecture

a -> the

Overall, the inconsistent use of verbs in section 1.1. is a problem - I
counted 7 (specifies, defines, details, etc.).  This should be reduced
to 2 or 3.

   In turn, the relevant standard for wireless QoS is IEEE 802.11, which
   is being progressively updated; the current version of which (at the
   time of writing) is IEEE 802.11-2012.

Add a citation of [IEEE.802-11.2012] at the end of the sentence.

- 1.3.  Applicability Statement

   This document primarily applies to wired IP networks that have
   wireless access points at their edges, but can also be applied to Wi-
   Fi backhaul, wireless mesh solutions or any other type of AP-to-AP
   wireless network that serves to extend the IP network infrastructure.

"serves to extend" -> "interconnects with"

These are peer networks at the IP level.

- Section 2.  Comparison and Default Interoperation ...

In this section, I prefer "assure" to "guarantee" as the former term is
somewhat looser.

   o  802.11 loosely supports a [RFC3662] Lower PDB service via the
      Background Access Category (AC_BK)

Lower -> Lower Effort
Make this change wherever "Lower PDB" occurs.

- 2.1.  Default DSCP-to-UP Mappings and Conflicts

OLD
   wherein the 3 Most Significant Bits (MSB) of
   the DSCP are transcribed to generate the corresponding L2 markings.
NEW
   wherein the 3 Most Significant Bits (MSB) of
   the DSCP are used as the corresponding L2 marking.

-- 2.2.  Default UP-to-DSCP Mappings and Conflicts

OLD
   Thus, the next sections of this draft seek to address these
   limitations and concerns and reconcile the intents of [RFC4594] and
   IEEE 802.11.
NEW
   The following sections address these  limitations and concerns in
   order to reconcile the[RFC4594] and IEEE 802.11.

Also, add an 802.11 citation to the end of the new sentence.

- 3.  Wireless Device Marking and Mapping Capability Recommendations

    and as such may be overridden by network administrators, as needed.

may -> MAY

- 4.  DSCP-to-UP Mapping Recommendations

   The following section proposes downstream (wired-to-wireless)
   mappings between [RFC4594] Configuration Guidelines for DiffServ
   Service Classes and IEEE 802.11.  As such, this section draws heavily
   from [RFC4594], including traffic class definitions and
   recommendations.

"proposes" -> "specifies"

Also, the role of RFC 4594 should be discussed much earlier - see
issues [3] and [B] above.

- 4.2.2 Signaling

   The Signaling service class is RECOMMENDED for delay-sensitive
   client-server (traditional telephony) and peer-to-peer application
   signaling

Insert "e.g.," before "traditional telephony" within the parentheses.

Thanks, --David
--------------------------------------------------------
David L. Black, Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953     Cell: +1 (978) 394-7754
[email-masked]  <=== NEW ===
--------------------------------------------------------

---

From: "Black, David" <[email-masked]>
Date: Thu, 5 Jan 2017 15:00:53 +0000

> We'll also need to find some more people to
> review the draft, as we like to see more than one WGLC review, and I'm not able
> to review the discussion of how WiFi works.

It's been pointed out that I overlooked Vincent Roca's December 20 review of this
draft, so allow me to apologize, and publicly thank Vincent for that review.

Thanks, --David

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of Black, David
> Sent: Wednesday, January 04, 2017 4:22 PM
> To: [email-masked]
> Subject: [tsvwg] David Black's review of draft-ietf-tsvwg-ieee-802-11-01
> 
> While it's slightly after the end date of WG Last Call, I have done a review of this
> draft, as an individual, although as WG chair, I'll comment that the major issues
> MUST be addressed and the minor issues SHOULD be addressed - a revision of
> the draft will definitely be needed.  We'll also need to find some more people to
> review the draft, as we like to see more than one WGLC review, and I'm not able
> to review the discussion of how WiFi works.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jan 2017 15:47:47 +1300

Good review, David. I have inserted a few comments in line below, tagged [BC]:
> Review of: draft-ietf-tsvwg-ieee-802-11-01

[BC] Exactly. As stated in RFC 2474, in fact:

   The defense against this class of theft- and denial-of-service
   attacks consists of the combination of traffic conditioning at DS
   domain boundaries with security and integrity of the network
   infrastructure within a DS domain.

If the network includes devices that have been maliciously programmed
to set EF on every packet, and if a router implements EF correctly,
the result would be that every packet beyond the capacity allocated to
EF "SHOULD be dropped" according to RFC 3246. So the service would be
significantly worse than best effort. The same therefore applies to any
802.11 marking that is mapped to EF. There could be similar but less
serious effects from spurious CSx or AFxy markings.

You can't trust markings from random devices. Unless devices have been
identified, authenticated and authorized they aren't trustworthy.
Several WGs are expending considerable effort on this problem;
I'm no expert, but draft-ietf-anima-bootstrapping-keyinfra is one
example.

BTW, I noticed that section 5.3 refers to sections 3.1 and 3.2, which
don't exist.

> to call out this exception, but see RFC 2475 for further discussion.

[BC] Correct. Since the QoS characteristics of wired and wireless networks
are quite different, it might in fact be exactly the right place for
a diffserv domain boundary, complete with traffic classification,
re-marking and policing.

> indicate what concepts are repeated from RFC 4594 vs. what is new

[BC] Agreed.

> to the tooth fairy, Santa Claus and the Easter Bunny.  I

[BC] It's also perhaps Quixotic. As I just noted, wired and wireless
QoS are intrinsically different so anything like 1:1 mapping
is probably doomed in advance.

> e.g., BGP here, and the AP is unlikely to be an inter-domain BGP speaker.

[BC] It's dangerous. If somebody has legitimately marked traffic as CS6 or CS7,
we would be arrogant to assume that we know better and the packet can be dropped.
Saying that it should be re-marked, even to CS0, would be reasonable.

RPL (RFC 6550) is absolutely intended to cross wireless/wired boundaries.
I don't know whether RPL deployments apply CS6 but it seems entirely
reasonable that they might. It's apparently been discussed in 6tisch,
which is IEEE 802.15.4.

> Make this change wherever "Lower PDB" occurs.

[BC] Maybe this draft should cite draft-tsvwg-le-phb instead of RFC3662?

Regards
    Brian