Subject: [nvo3] Stephen Farrell's No Objection on draft-ietf-nvo3-arch-07: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 15 Sep 2016 04:09:11 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-nvo3-arch-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nvo3-arch/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- (This comment is just a generic remark, offered in the hope
that future IPR declarations might be more tightly targeted,
so there's no need to respond to it.) It's not clear to me
how an architecture with 2 RAND-with-fee IPR declarations
amounts to a win here.  Well, unless the IPR is rubbish maybe
- I did take a look at those and do have an opinion, but I'll
leave you to guess what that is:-) But the IPR declarations
seem like they were timely, and the last call did mention
them, so I guess it is what it is.  Generally though, I think
it'd be way better if IPR declarations were attached to
specific protocol documents that the IPR holders consider
relevant and not to architecture documents or similar. I can
understand that making an IPR declaration on a document like
this might be seen as getting the declaration out earlier (a
good thing), but one has to wonder how anything here
represents a credible invention. If that's the case I'd note
that IPR declarations can be made that don't point at an
Internet-draft which might be a better way to provide earlier
notification to a WG. And declarations can be updated later
to be associated with specific drafts if/when that's needed.

- Generally this was pretty well written, thanks.

- abstract/intro: "work with other components with no changes
to other components" isn't great, suggest re-wording.

- 4.2: ToR could do with an expansion on 1st use

- 4.2.1: TS - I assume that's "tenant system" (from 7635) but
you should say as it's used a good bit (and 7635 also defines
"tenant separation" making TS potentially ambiguous). Mostly,
uses of TS seem clear from context, but I think it'd be good
to fix this and to check over where TS is used in this draft
as there could be some subtlety there, e.g.  whether or not a
TSI is part of a TS or not (and is somehow architecturally
"beside" a TS) could affect some later protocol work.

- section 16: I think it might be worth noting here that
meta-data and operational data could be unexpectedly
sensitive, for example performance statistics could be used
to infer what's being done in a VM or VN. So in addition to
encrypting data in transit or storage, one might also want to
consider minimising the types of data that NVEs/NVAs collect.
That could have an impact on protocols defined later so may
well be worth noting here too. If you do add text on that you
may also want to recognise the tension between such data
minimisation and the operational need to detect misbehaviours
or errors happening within VNs.

---

From: "Black, David" <[email-masked]>
Date: Tue, 20 Sep 2016 01:06:43 +0000

Stephen,

> - Generally this was pretty well written, thanks.

Thanks for the careful review.

> - 4.2: ToR could do with an expansion on 1st use

Editorial improvements made for both of the above.

> "beside" a TS) could affect some later protocol work.

Checked, expanded some uses of TS.   It's always Tenant System,
and the acronym usage is generally clear.

> consider minimising the types of data that NVEs/NVAs collect.

I believe that's generally the case for operational data, e.g.,
performance stats.  If you or the OPS ADs have a reference
to suggest, I'd be happy to cite it on this concern, but would

> or errors happening within VNs.

is likely to entail a discussion of trust models between a network
operator (landlord) and tenants using that network infrastructure.
I suspect that discussion will be neither simple nor short, and
moreover, it has much broader IETF applicability than just NVO3.

Thanks, --David

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Thursday, September 15, 2016 7:09 AM
> To: The IESG
> Cc: [email-masked]; Matthew Bocci; [email-masked];
> [email-masked]; [email-masked]
> Subject: Stephen Farrell's No Objection on draft-ietf-nvo3-arch-07: (with
> COMMENT)
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 20 Sep 2016 07:17:12 +0100

Hi David,

Just on this point...

> moreover, it has much broader IETF applicability than just NVO3.

I do understand your reluctance to open cans of worms, however
the topic does seem quite relevant to this architecture document,
even if there is a generic concern as you note, so I'd say it
would be right to ack the issue here, so that those doing later
protocol development work don't trip over it at the end of their
work.

I don't have a great reference though - this issue is noted in
RFC7258 of course, but without any real detail. RFC 6973 is also
relevant I guess.

Anyway, if it works, I'd suggest adding something simple like:

"NVEs and NVAs need to collect performance and other data in
order to carry out their functions. This data can sometimes be
unexpectedly sensitive, for example, allowing non-obvious
inferences as to activity within a VM. This provides a reason
to minimise the data collected so as to be cautious not to
create such potential vulnerabilities. As noted briefly in
RFC6973 and RFC7258 there is an inevitable tension between
being privacy sensitive and network operations that needs to
be taken into account in nvo3 protocol development."

Of course that's offered modulo whatever wordsmithing
makes sense.

Cheers,
S.

---

From: "Black, David" <[email-masked]>
Date: Tue, 20 Sep 2016 14:47:10 +0000

Hi Stephen,

> Of course that's offered modulo whatever wordsmithing

I can work with that text, with wordsmithing applied to one sentence:

OLD
   This provides a reason to minimise the data collected
   so as to be cautious not to create such potential vulnerabilities.
NEW
   This provides a reason to minimise the data collected in some
   environments in order to limit potential exposure of sensitive
   information.

I want to add "in some environments" as there are environments
in which this is not a concern, e.g., a data center environment in
which all the tenants, the data center operator and the network
operator are one and the same organization/entity.

Determination of which environments should minimize data
collection would be left as an exercise for the reader.

Beyond that, the word "vulnerabilities" seems susceptible to
misreading - "exposure of sensitive information" is the risk to
be managed.

Thanks, --David

> Sent: Tuesday, September 20, 2016 2:17 AM
> To: Black, David; The IESG
> Subject: Re: Stephen Farrell's No Objection on draft-ietf-nvo3-arch-07: (with
> COMMENT)
> 
> 
> Hi David,
> 
> Just on this point...
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 20 Sep 2016 15:52:59 +0100

Hi David,

That all looks fine to me.

Cheers,
S.