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

["Tim Szigeti (szigeti)" <[e-mail]>]

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)