Re: [tsvwg] AD Evaluation comments for draft-ietf-tsvwg-ieee-802-11-07

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

The text that Spencer quoted brings up something else ... I'd suggest some editorial rephrasing of at least the words "SHOULD be considered" in:

   Suffice it to say that
    the security of the devices and networks implementing QoS, including
    QoS mapping between wired and wireless networks, SHOULD be
   considered in actual deployments.

before someone on the IESG notes the relevance of Section 2 of RFC 6919  to that text: 
	https://tools.ietf.org/html/rfc6919#section-2
and notices the publication date of RFC 6919 :-) :-).

Thanks, --David

> -----Original Message-----
> From: Tim Szigeti (szigeti) [mailto:[e-mail]]
> Sent: Friday, September 15, 2017 8:56 PM
> To: Spencer Dawkins at IETF <[e-mail]>; Black, David
> <[e-mail]>
> Cc: Black, David <[e-mail]>; [e-mail]; draft-ietf-tsvwg-
> [e-mail]
> Subject: RE: AD Evaluation comments for draft-ietf-tsvwg-ieee-802-11-07
> 
> Hi Spencer,
> 
> Thank you very much for giving this document a thorough read. We really
> appreciate your feedback and suggestions, all of which have been
> implemented in the latest version (v08) just posted.
> 
> Cheers,
> 
> -tim
> 
> > -----Original Message-----
> > From: Spencer Dawkins at IETF [mailto:[e-mail]]
> > Sent: Tuesday, September 12, 2017 7:56 PM
> > To: David Black
> > Cc: David L. Black; [e-mail]; [e-mail]
> > Subject: AD Evaluation comments for draft-ietf-tsvwg-ieee-802-11-07
> >
> > This was a very dense read, and I found only a few things to ask about, and
> > half of those are nits.
> >
> > Nice work.
> >
> > Please take a look at my evaluation comments, and let me know how you'd
> > like to proceed.
> >
> > Thanks, as always.
> >
> > Spencer
> >
> > Nit, but it's in the Abstract ...
> >
> >    This document specifies a set Differentiated
> >    Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings
> >
> > should this be "... set of Differentiated Services Code Point ..."?
> >
> > I'm looking at this text,
> >
> >    There is also a recommendation from the Global System for Mobile
> >    Communications Association (GSMA), specifically their Mapping Quality
> >    of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN
> >    [RFC7561] specification.  This GSMA specification was developed
> >    without reference to existing IETF specifications for various
> >    services, referenced in Section 1.1.
> >
> > and I'm not quite sure how an IETF-stream Informational RFC produced by
> a
> > working group becomes "a recommendation from GSMA" and "a GSMA
> > specification". I recognize the names of the RFC 7561 authors, and I see the
> > connection, but I would have thought that the reference would have been
> to
> > something more obviously tied to GSMA. Is there any reference that could
> > be cited, to help people who didn't sit two desks away from one of the
> > authors see the connection?
> >
> > In this text,
> >
> >    This document assumes and RECOMMENDS that all wireless access points
> >    (as the bridges between wired-and-wireless networks) support the
> >    ability to:
> >
> > is "bridges" the right word here? I would read that as saying that wireless
> > access points are a layer two-layer two bridge. If you have readers who are
> > familiar with IEEE 802.1 bridging, they may be more confused than I was.
> >
> > A nit - "unusued" -> "unused"
> >
> > I really appreciate the inclusion of Section 6, as an overview of IEEE 802.11
> > QoS. I'd suggest that this not be titled as "Appendix" - which
> > https://www.rfc-editor.org/rfc/pdfrfc/rfc7322.txt.pdf doesn't think is part
> of
> > an RFC body, so at a minimum they would move it behind the security
> > considerations, but I'd be OK if you left it as a normal Section in the body.
> > Alternatively, if you're happier with this material as an Appendix, it's
> probably
> > better to slide it to the back material.
> >
> > A nit - "oftheir" -> "of their"
> >
> > I'm looking at the last paragraph of the Security Considerations, and I'm
> > thinking that
> >
> >    Finally, it should be noted that the recommendations put forward in
> >    this document are not intended to address all attack vectors
> >    leveraging QoS marking abuse.  Mechanisms that may further help
> >    mitigate security risks include strong device- and/or user-
> >    authentication, access-control, rate limiting, control-plane
> >    policing, encryption and other techniques; however, the
> >    implementation recommendations for such mechanisms are beyond the
> >    scope of this document to address in detail.  Suffice it to say that
> >    the security of the devices and networks implementing QoS, including
> >    QoS mapping between wired and wireless networks, SHOULD be
> > considered
> >    in actual deployments.
> >
> > is missing the (perhaps obvious) point that the mechanisms you list under
> > "further help" aren't specific to wireless networks, but should be
> considered
> > for any network that implements QoS. That might be covered in the last
> > sentence, but that's not what I'm getting out of the last sentence.