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

[Spencer Dawkins at IETF <[e-mail]>]

Dear All,

On Mon, Sep 18, 2017 at 12:26 PM, Black, David <[e-mail]> wrote:

> 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.
>

I'm good to go with v08, but please let me know if anything will change in
response to David's previous e-mail in this thread, so we don't start Last
Call with comments that should be addressed.

Thanks,

Spencer

>
> > 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]; draft-ietf-tsvwg-ieee-802-11@
> ietf.org
> > > 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.
>