Re: [secdir] draft-ietf-nvo3-use-case-15 SECDIR review

Lucy yong <lucy.yong@huawei.com> Tue, 03 January 2017 20:48 UTC

Return-Path: <lucy.yong@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06366129412; Tue, 3 Jan 2017 12:48:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.32
X-Spam-Level:
X-Spam-Status: No, score=-7.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGLxTlgDSnz6; Tue, 3 Jan 2017 12:48:52 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACDEA129456; Tue, 3 Jan 2017 12:48:51 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYE82698; Tue, 03 Jan 2017 20:48:49 +0000 (GMT)
Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 3 Jan 2017 20:48:48 +0000
Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0301.000; Tue, 3 Jan 2017 12:48:47 -0800
From: Lucy yong <lucy.yong@huawei.com>
To: Donald Eastlake <d3e3e3@gmail.com>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-nvo3-use-case.all@ietf.org" <draft-ietf-nvo3-use-case.all@ietf.org>
Thread-Topic: draft-ietf-nvo3-use-case-15 SECDIR review
Thread-Index: AQHSZdyt7iX3NRyJR0eGUIv7lCweNKEnLhBQ
Date: Tue, 03 Jan 2017 20:48:47 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D57B9C24B@dfweml501-mbb>
References: <CAF4+nEGUcm7h6VUUa-Bsx3c8XnXZvu5Tf5-Oeu5ELsCn6sogYw@mail.gmail.com>
In-Reply-To: <CAF4+nEGUcm7h6VUUa-Bsx3c8XnXZvu5Tf5-Oeu5ELsCn6sogYw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.148.214]
Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D57B9C24Bdfweml501mbb_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.586C0E32.0028, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 3e6330543c6f3144747d1156a7e03124
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/QYd1zq5gVslyPDtcYJwqDNAtC1s>
Cc: "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] draft-ietf-nvo3-use-case-15 SECDIR review
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jan 2017 20:48:55 -0000

Hi Donald,

Thank you for the review.

From: Donald Eastlake [mailto:d3e3e3@gmail.com]
Sent: Tuesday, January 03, 2017 10:15 AM
To: iesg@ietf.org; draft-ietf-nvo3-use-case.all@ietf.org
Cc: secdir@ietf.org
Subject: draft-ietf-nvo3-use-case-15 SECDIR review

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments.

This draft described use cases for network virtualization overlay networks focusing on Data Center use. I think this document is Ready with issues.

Security:

As an Informational use case document, security is not a major focus of this draft. Nevertheless:

The existing Security Considerations section says that Data Center operators need to provide tenants with a virtual network that is "isolated from other tenants' traffic as well as from underlay networks". But I don't think tenants can, in general, be protected from the underlay network. I would say that tenants are vulnerable to observation and data modification/injection by the operator of the underlay and should only use operators they trust.
[Lucy] How about: DC operators need to provide a tenant with a secured virtual network, which means one tenant’s traffic is isolated from other tenants’ traffic and is not leaked to the underlay networks. Tenants are vulnerable to observation and data modification/injection by the operator of the underlay and should only use operators they trust.

The existing Security Considerations section says that tenants need to be isolated from each other but I believe there will always be covert channels, based on resource contention and the like, by which tenants can communicate with each other and the best that can be done is to limit the bandwidth of such communications.
[Lucy] suggested text is taken.

Minor:

"BUM" and "ASBR" used without definition or expansion.
[Lucy] ack. Fix some others too.


Wording: I think the wording is off in some places for a reader for whom English is their native language. See attached for suggestions. I probably haven't caught all the wording glitches.
[Lucy] thank very much for the correction.  Should I upload the updated version or wait the feedback from other areas?

Thanks,
Lucy


Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com<mailto:d3e3e3@gmail.com>