Re: [secdir] secdir review of draft-ietf-tsvwg-diffserv-intercon-09

[Benjamin Kaduk <[e-mail]>]

Hi David,

On Wed, 21 Sep 2016, Black, David wrote:

> Hi Ben,
>
> Thanks for the review.
>
> > However, I do think it's worth giving a little bit of new thought to the
> > potential privacy considerations -- a new way of marking traffic, in
> > abstract, has the potential to leak classification information about the
> > traffic in question (e.g., is this IP address doing telephony?).  That
> > said, the classification added by this document is something that could be
> > done by any party with access to the raw network traffic, so I don't think
> > there are actually any new considerations in play; it's just something to
> > keep in mind.
>
> On balance, it seems like a good idea to add a sentence or two to point out
> that additional traffic classification information is exposed at network
> interconnections by comparison to DSCP remarking to zero - if that traffic
> classification info is sensitive, remarking DSCPs to zero to hide the classification
> is the countermeasure, at the cost of loss of QoS info and traffic handling
> on the interconnect.

Thanks.  I think the document would be fine without such a sentence, but
am happy to see one added.

>  Also, here are a few comments on your editorial suggestions:
>
> > Top of page 3, last sentence of first paragraph ("This draft assumes that
> > latter approach by defining additional DSCPs that are known and expected
> > at network interconnection interfaces.") -- I think maybe "subsumes" is a
> > better verb than "assumes", as it is true that unknown/unexpected DSCPs
> > are remarked to zero, but there is additional functionality in the
> > known/expected DSCPs that are preserved.
>
> Well, "subsumes" isn't quite right either.   Here's a longer rewrite that I hope
> makes things clearer:
>
> OLD
>    This draft assumes that latter approach by defining additional DSCPs
>    that are known and expected at network interconnection interfaces.
> NEW
>    This draft is based on the latter approach, and defines additional DSCPs
>    that are known and expected at network interconnection interfaces in
>    order to reduce the amount of traffic whose DSCPs are remarked to zero.

The transition to "and defines additional" could probably be tweaked a bit
more, but this is definitely an improvement -- thanks.

> > Across the page 3/page 4 boundary, the part after the semicolon is a
> > sentence fragment ... I can't even tell what it's trying to say.  Maybe,
> > "remarking to zero is performed in the absence of [...]" (but put a comma
> > before "for").
>
> Yes, it's a fragment - here's a suggested rewrite:
>
> OLD
>    remarking in the absence of
>    additional agreement(s) when the MPLS Short Pipe model is used for
>    reasons explained in this document.
> NEW
>    use of the MPLS Short Pipe model favors remarking unexpected DSCPs
>    to zero in the absence of additional agreement(s), as explained further
>    in this document.

Makes sense.

> > Section 1.1, first paragraph, is this work really intended to *complement*
> > RFC 5160?  It seems to me that rather it is building upon 5160, or
> > implementing its suggestions, or something like that.
>
> The activities are independent, so "complement" is a  reasonable summary.

I'll have to take your word for it, since my understanding seems to be
incomplete.  Sorry for the noise, then.

-Ben