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

Donald Eastlake <d3e3e3@gmail.com> Wed, 04 January 2017 03:50 UTC

Return-Path: <d3e3e3@gmail.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 58CCD129BA0; Tue, 3 Jan 2017 19:50:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 nhJlrgoSsc2X; Tue, 3 Jan 2017 19:50:09 -0800 (PST)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7440129B8E; Tue, 3 Jan 2017 19:50:08 -0800 (PST)
Received: by mail-io0-x22f.google.com with SMTP id p42so446175161ioo.1; Tue, 03 Jan 2017 19:50:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=r3mK+prKqxz33CO87frISxTfBN/isdKIcHgNY7rg288=; b=fkHkdkGZmio+BCwhYH+U2EW6kDOy1tgFOyJDlXPHjl7hpGCSdmbcSABMFQKi+I9JOK ZVfosBf6jvkBmpT/Whm4KsLJ0C35eKErt9mTt4x7JzJZtFJV1CA2a2G4QVwVYegNErxA bj/D0IhictRfiDuCD6d9luEV5yaQBcpi+Krr0fykv6WHjazyCxkZvwtn4Ar8CEi8nJWZ Zvf/cqvDjlhBsZ6CrRGnidXi1qwuyVkCZq2qCfwnSD3sqAG+i3j9/CIkZRQv8V/mQ4pp hxJLPltU2Fy7+4KkiyBdrItXmW/srTmEtzdjVgBKAD5E1DSUoHRa/ZS5JN0HBto1u5se 8jNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=r3mK+prKqxz33CO87frISxTfBN/isdKIcHgNY7rg288=; b=eH/PW15Y603CG04laTU47bRzT3LZURHW5iYBwHv75qvL76g6Yg3bF0PyIYc9RBFcxT 6d0qFbjeb908psRyqkhKZDEzP0XPmmYRTARAhJac4/nrdof17R6wQCm6hWoOXGlHpSDB a67DKV7TogsxFg2FiqTCvrBppxCGEQS6AHw5VO70wGJ990ct27Ayk9x72UcjlEehLWxl Wg/QecXoEoeAWkupDF/b3rUDAQUNLsIzJIOmR/ijLwGKUamj+YqY+F8oT8nTRzdBefRe yYu6YdBc0tlE1LXQOYqbL8DIiIh/u/ooQmqQn45aadjBG5eypQBor8/BMfM+BQv8ncba r2Eg==
X-Gm-Message-State: AIkVDXKeLklNPvaFf+9rUJ90f4sAw4r5lqsX26A8S8Of9hS/Zx1sv+g+ReLQMrv9vnhUED76MzXE88I3xeFffA==
X-Received: by 10.107.175.80 with SMTP id y77mr46975240ioe.12.1483501808196; Tue, 03 Jan 2017 19:50:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.41.136 with HTTP; Tue, 3 Jan 2017 19:49:52 -0800 (PST)
In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D57B9C24B@dfweml501-mbb>
References: <CAF4+nEGUcm7h6VUUa-Bsx3c8XnXZvu5Tf5-Oeu5ELsCn6sogYw@mail.gmail.com> <2691CE0099834E4A9C5044EEC662BB9D57B9C24B@dfweml501-mbb>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Tue, 03 Jan 2017 22:49:52 -0500
Message-ID: <CAF4+nEH5dUDHanKK56wTVeMidx3Loi5Xs8DD_ayV4XqOZHpq9Q@mail.gmail.com>
To: Lucy yong <lucy.yong@huawei.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/zJRiGB_rVxjEa-guL0E_VwhPjzY>
Cc: "draft-ietf-nvo3-use-case.all@ietf.org" <draft-ietf-nvo3-use-case.all@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "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: Wed, 04 Jan 2017 03:50:10 -0000

Hi Lucy,

On Tue, Jan 3, 2017 at 3:48 PM, Lucy yong <lucy.yong@huawei.com> wrote:
> 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.

OK.

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

OK.

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

OK.

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

I would say that you should not update the draft while the IETF Last
Call is running. So you should at least wait until after January 11th.
And in general, after that, you should check with the document
Shepherd (Matthew Bocci) or the AD (Alia Atlas).

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

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