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

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

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)