Subject: [tsvwg] TSVWG Working Group Last Call (WGLC) on draft-ietf-tsvwg-ieee-802-11 - David Black's comments

From: "Black, David" <[email-masked]>
Date: Sat, 15 Jul 2017 16:40:19 +0000

In general, the -04 draft is much improved from the -01 draft.  All of my remaining major concerns involve uses of the word "trust" that 

-- Major

Section 3:

   This document assumes and RECOMMENDS that all wireless access points
   (as the bridges between wired-and-wireless networks) support the
   ability to:

[... snip ...] 

   o  trust DSCP markings set by wireless endpoint devices

This instance of "trust" appears to have been overlooked.   I suggest changing "trust" to "process."

Section 5:

   o  DSCP-Trust at the wireless access point (effectively a 1:1 DSCP-
      to-DSCP mapping)

Aha, the dreaded T-word again.  Suggest: DSCP-Trust -> DSCP-Passthrough,  as that not only removes the T-word, but is also more descriptive.   This also affects Section 5.3 ...

Section 5.3:

Change DSCP-Trust -> DSCP-Passthrough in section title.

   It is generally NOT RECOMMENDED to trust DSCP markings from
   unauthenticated and unauthorized devices, as these are typically
   considered untrusted sources.

to trust DSCP markings -> to pass through DSCP markings

   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:

I don't understand what a "trust function" is, so this looks like a circular statement.  Once "trust function" is clarified, change "RECOMMENDED to trust DSCP" to "RECOMMENDED to pass through DSCP" ... but the details of this clarification are crucial as this text is a potentially serious security hole as currently written.

A related minor issue turns up in Section 8.1 - see below.

Finally, Gorry noted:

   (4) I suspect the security section may benefit from a better definition 
   of the case where the 802.11 network forms the edge of a DS domain. I 
   suspect other people will suggest text on this.

I suspect that some of the changes suggested in this review towards less use of the word "trust" will help with this concern, so I suggest that Gorry and I both take a look at the resulting text to see whether it suffices.   That said, it would help to add a reference from the security considerations text on CS6 and CS7 back to section 5.4, which discusses this "edge of a DS domain" case.

-- Minor

Section 2.1:

   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.

Needs specific examples and/or forward references to what changes with AP position.

Sections 5.2, 5.3 and 5.4:

These sections are effectively discussing alternatives for access point Diffserv functionality.  That structure (do one of these three) is not clear in the draft.

Section 8.1:

      Additionally, Section 5.3 made it clear
      that it is generally NOT RECOMMENDED to trust DSCP markings from
      unauthorized and/or unauthenticated devices, as these are
      typically considered untrusted sources. This is especially
      relevant for IoT deployments, where tens-of-billions of devices
      are being connected to IP networks, many of which have little or
      no security.

In the first sentence: "trust" -> "pass through"

In the second sentence as written, "many of which" refers to "IP networks" - I suspect that was not intended, e.g., "tens-of-billions of devices that may have little or no security are being connected to IP networks" may be closer to what was intended.

      Setting a trust boundary reflective of business objectives and
      policy, such that traffic from authorized users and/or
      applications and/or endpoints will be accepted by the network;
      otherwise packet markings will be "bleached" (i.e. remarked to
      DSCP DF and/or UP 0).

I have some idea of what a "trust boundary" is, but suspect that "traffic conditioning policy" may be clearer and closer to what was intended.

Section 8.2:

Every paragraph in this section is bidirectional in scope, applying to both wired->wireless and wireless-> wired traffic, except for this paragraph:

   If such marking/mapping were not controlled, then, for example, a
   malicious user could cause WLAN DoS by flooding traffic marked CS7
   DSCP downstream.  This codepoint would map by default to UP 7 and
   would be assigned to the Voice Access Category (AC_VO).  Such a flood
   could cause Denial-of-Service to not only wireless voice
   applications, but also to all other traffic classes.

I suggest making this paragraph bidirectional by providing the example in both directions and then making it clear that the following paragraph:

   Therefore, to mitigate such an attack, it is RECOMMENDED that all
   packets marked to Diffserv Codepoints not in use over the wireless
   network be mapped to UP 0.

applies to both access points and wireless device operating systems.

-- Editorial

Section 1.1:

   Note: [RFC4594] is intended to be viewed as a set of "project plans"
   for building all the (diffserv) furniture that one might want.  Thus,
   it describes different types of traffic expected in IP networks and
   provides guidance as to what DSCP marking(s) should be associated
   with each traffic type.  As such, this document draws heavily on
   [RFC4594], [RFC5127], and [RFC8100].

The first sentence seems a bit too informal, suggest:

OLD
   Note: [RFC4594] is intended to be viewed as a set of "project plans"
   for building all the (diffserv) furniture that one might want.  
NEW
   Note: [RFC4594] is intended to be viewed as a framework and guidelines
   for supporting Diffserv in any network, including wireless networks.

Section 2.1:

   It is important to recognize that the wired-to-wireless edge may or
   may not equate to the edge of the Diffserv domain.

equate to the edge of the Diffserv domain -> function as an edge of a Diffserv domain or a domain boundary.

Section 8:

Initial paragraph seems overly defensive, suggest:

OLD
   The recommendations put forward in this document do not present any
   additional security concerns that do not already exist in wired and
   wireless devices.  In fact, several of the recommendations made in
   this document serve to mitigate and protect wired and wireless
   networks from potential abuse arising from existing vulnerabilities.
NEW
   The recommendations in this document concern existing wired and wireless
   network functionality, and for that reason do not add significant security
   concerns.   Some of the recommendations help protect wired and wireless
   networks from potential abuse, e.g., as discussed further in this section.

Section 8.2:

   It should be strongly noted that in the wireless deployment model

I suggest deleting "It should be strongly noted that" 

Thanks, --David

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of G Fairhurst
> Sent: Thursday, July 6, 2017 3:11 AM
> To: tsvwg WG <[email-masked]>
> Subject: [tsvwg] TSVWG Working Group Last Call (WGLC) on draft-ietf-tsvwg-
> ieee-802-11-01 to conclude 10th Jul 2017
> 
> This email announces a second TSVWG Working Group Last Call (WGLC) on:
> 
>              DiffServ to IEEE 802.11 Mapping
>              draft-ietf-tsvwg-ieee-802-11-01
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11-01
> 
> This WGLC will last for about 2 weeks weeks. The purpose of this call is
> to provide further feedback (if required) on changes made since the
> first WGLC concluded.
> 
> Comments should be sent to [email-masked]
> <mailto:[email-masked]>list, although purely
> editorial comments may be sent directly to the authors. Please cc: the
> WG chairs [email-masked] <mailto:[email-masked]>  if you
> would like the chairs to
> track such editorial comments as part of the WGLC process.
> 
> No IPR disclosures have been submitted directly on
> draft-ietf-tsvwg-ieee-802-11-01
> 
> Thanks,
> Gorry
> (TSVWG Co-Chair)

---

From: "Tim Szigeti (szigeti)" <[email-masked]>
Date: Thu, 27 Jul 2017 22:35:07 +0000

Hi David,

Thank you again for taking the time to do another round of review.

All changes you've suggested below have been made to the latest version of the draft.

Thank you again for helping us find the right balance on security vs. functionality.

-tim

> From: tsvwg [mailto:[email-masked]] On Behalf Of Black, David
> Sent: Saturday, July 15, 2017 9:40 AM
> To: G Fairhurst; tsvwg WG
> ieee-802-11 - David Black's comments
> 
> In general, the -04 draft is much improved from the -01 draft.  All of my
> remaining major concerns involve uses of the word "trust" that
> 
> -- Major
> 
> Section 3:
> 
> Aha, the dreaded T-word again.  Suggest: DSCP-Trust -> DSCP-Passthrough,
> as that not only removes the T-word, but is also more descriptive.   This also
> affects Section 5.3 ...
> 
> Section 5.3:
> 
> I don't understand what a "trust function" is, so this looks like a circular
> statement.  Once "trust function" is clarified, change "RECOMMENDED to
> trust DSCP" to "RECOMMENDED to pass through DSCP" ... but the details of
> this clarification are crucial as this text is a potentially serious security hole as
> currently written.
> 
> I suspect that some of the changes suggested in this review towards less use
> of the word "trust" will help with this concern, so I suggest that Gorry and I
> both take a look at the resulting text to see whether it suffices.   That said, it
> would help to add a reference from the security considerations text on CS6
> and CS7 back to section 5.4, which discusses this "edge of a DS domain" case.
> 
> -- Minor
> 
> Section 2.1:
> 
> These sections are effectively discussing alternatives for access point Diffserv
> functionality.  That structure (do one of these three) is not clear in the draft.
> 
> Section 8.1:
> 
> In the second sentence as written, "many of which" refers to "IP networks" -
> I suspect that was not intended, e.g., "tens-of-billions of devices that may
> have little or no security are being connected to IP networks" may be closer
> to what was intended.
> 
> I have some idea of what a "trust boundary" is, but suspect that "traffic
> conditioning policy" may be clearer and closer to what was intended.
> 
> Section 8.2:
> 
> Every paragraph in this section is bidirectional in scope, applying to both
> wired->wireless and wireless-> wired traffic, except for this paragraph:
> 
> I suggest making this paragraph bidirectional by providing the example in
> both directions and then making it clear that the following paragraph:
> 
> > This WGLC will last for about 2 weeks weeks. The purpose of this call
> > is to provide further feedback (if required) on changes made since the
> > first WGLC concluded.
> >
> > <mailto:[email-masked]>list, although purely editorial comments may be
> > sent directly to the authors. Please cc: the WG chairs
> > [email-masked] <mailto:[email-masked]>  if you would
> > like the chairs to track such editorial comments as part of the WGLC
> > process.
> >