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

["Black, David" <[e-mail]>]

Tim and authors,

This does suffice, as indicated by the change in WG draft state to WG Consensus: Waiting for Write-Up that I just made.

The next step is for me to produce a shepherd write-up for this draft, which should happen next week, as I'm traveling this week.

Thanks, --David

> -----Original Message-----
> From: Tim Szigeti (szigeti) [mailto:[e-mail]]
> Sent: Wednesday, August 16, 2017 2:17 PM
> To: Black, David <[e-mail]>; G Fairhurst
> <[e-mail]>; tsvwg WG <[e-mail]>
> Cc: Jerome Henry (jerhenry) <[e-mail]>; Fred Baker
> <[e-mail]>
> Subject: RE: TSVWG Working Group Last Call (WGLC) on draft-ietf-tsvwg-ieee-
> 802-11 - David Black's comments
> 
> Thank you David for catching even these subtle points.
> 
> I've made the changes exactly as you've recommended below and have
> uploaded a new draft.
> 
> Please confirm if this allows us to proceed to the next step.
> 
> TIA.
> 
> -tim
> 
> > -----Original Message-----
> > From: Black, David [mailto:[e-mail]]
> > Sent: Monday, August 07, 2017 6:24 PM
> > To: Tim Szigeti (szigeti); G Fairhurst; tsvwg WG
> > Cc: Jerome Henry (jerhenry); Fred Baker
> > Subject: RE: TSVWG Working Group Last Call (WGLC) on draft-ietf-tsvwg-
> > ieee-802-11 - David Black's comments
> >
> > Hi Tim,
> >
> > Many thanks for your continued efforts on this draft, and sorry for the
> > delayed response.   The changes generally look good - there were two areas
> > where I wanted to re-check the revised text:
> >
> > A) On Section 5.3, I wrote:
> >
> > > > 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.
> >
> > The revised text removes the use of the term "trust function" and is much
> > clearer as a result.
> >
> > B)
> >
> > > > 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.
> > > >
> >
> > Beyond removal of most uses of the word "trust," the security
> > considerations text on CS6 and CS7 was expanded, which obviates the need
> > for a backpointer, however .... this text in Section 5.4 is now  subtly
> > inconsistent with at least the security considerations text:
> >
> >    When business requirements and/or technical constraints and/or
> >    administrative policies require QoS markings to be passed through at
> >    the wireless edge, then it is RECOMMENDED to pass through Layer 3
> >    DSCP markings (over Layer 2 [IEEE.802.11-2016] UP markings) in the
> >    upstream direction, for the following reasons:
> >
> > CS6 and CS7 are exceptions to this "RECOMMENDED" requirement for the
> > security reasons discussed in section 8, and because they should not be
> > generated by hosts for the reasons discussed in section 5.1.   I have a couple
> > of suggested changes.
> >
> > 1) Insert "with the exception of CS6 and CS7" after "in the upstream
> > direction" in the above text.
> >
> > 2) Add a paragraph after the itemized list to explain (mostly by citing the two
> > relevant sections):
> >
> >    CS6 and CS7 are exceptions to this pass through recommendation because
> >    wireless hosts SHOULD NOT use them (see Section 5.1) and traffic with
> >    those two markings poses a threat to operation of the wired network (see
> >    Section 8.2).  CS6 and CS7 SHOULD NOT be passed through to the wired
> >    network in the upstream direction unless the access point  has been
> >    specifically configured to do that by a network administrator or operator.
> >
> > Does that sound reasonable?
> >
> > Thanks, --David
> >
> > > -----Original Message-----
> > > From: Tim Szigeti (szigeti) [mailto:[e-mail]]
> > > Sent: Thursday, July 27, 2017 6:35 PM
> > > To: Black, David <[e-mail]>; G Fairhurst
> > > <[e-mail]>; tsvwg WG <[e-mail]>
> > > Cc: Jerome Henry (jerhenry) <[e-mail]>; Fred Baker
> > > <[e-mail]>
> > > Subject: RE: TSVWG Working Group Last Call (WGLC) on
> > > draft-ietf-tsvwg-ieee-
> > > 802-11 - David Black's comments
> > >
> > > 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
> > >
> > > > -----Original Message-----
> > > > From: tsvwg [mailto:[e-mail]] On Behalf Of Black,
> > > > David
> > > > Sent: Saturday, July 15, 2017 9:40 AM
> > > > To: G Fairhurst; tsvwg WG
> > > > Subject: [tsvwg] TSVWG Working Group Last Call (WGLC) on
> > > > draft-ietf-tsvwg-
> > > > 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:
> > > >
> > > >    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:[e-mail]] On Behalf Of G
> > > > > Fairhurst
> > > > > Sent: Thursday, July 6, 2017 3:11 AM
> > > > > To: tsvwg WG <[e-mail]>
> > > > > 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 [e-mail]
> > > > > <mailto:[e-mail]>list, although purely editorial comments
> > > > > may be sent directly to the authors. Please cc: the WG chairs
> > > > > [e-mail] <mailto:[e-mail]>  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)