Re: [secdir] Secdir review of draft-ietf-nvo3-arch-06

"Takeshi Takahashi" <takeshi_takahashi@nict.go.jp> Sat, 13 August 2016 00:10 UTC

Return-Path: <takeshi_takahashi@nict.go.jp>
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 92BF212D92C; Fri, 12 Aug 2016 17:10:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.447
X-Spam-Level:
X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, 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 LixavmMx0A2D; Fri, 12 Aug 2016 17:10:22 -0700 (PDT)
Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id D886612D8B1; Fri, 12 Aug 2016 17:10:21 -0700 (PDT)
Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id u7D0AHAv014103; Sat, 13 Aug 2016 09:10:17 +0900 (JST)
Received: from DESKTOP2JPR8KD (ssh1.nict.go.jp [133.243.3.49]) by gw1.nict.go.jp with ESMTP id u7D0AHTC013909; Sat, 13 Aug 2016 09:10:17 +0900 (JST)
From: Takeshi Takahashi <takeshi_takahashi@nict.go.jp>
To: "'Black, David'" <david.black@emc.com>, draft-ietf-nvo3-arch.all@ietf.org
References: <225101d1f4ab$be76d9a0$3b648ce0$@nict.go.jp> <CE03DB3D7B45C245BCA0D243277949362F63B90F@MX307CL04.corp.emc.com>
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949362F63B90F@MX307CL04.corp.emc.com>
Date: Sat, 13 Aug 2016 09:10:17 +0900
Message-ID: <14afb01d1f4f7$1275e230$3761a690$@nict.go.jp>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_14AFC_01D1F542.825D8A30"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJVc9ShE0j+FVnLpFrAsWqfActl/gEaTFovnzYytfA=
Content-Language: ja
X-Virus-Scanned: clamav-milter 0.98.7 at zenith1
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/TS-_6f8jTEXDhj-lfHIg2Qp-nwY>
Cc: nvo3@ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-nvo3-arch-06
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: Sat, 13 Aug 2016 00:10:24 -0000

Hello David-san,

 

Thank you for reflecting my comments. I like the revised sentences.

I hope this draft will be published as an RFC soon.

 

Best regards,

Take

 

From: Black, David [mailto:david.black@emc.com] 
Sent: Saturday, August 13, 2016 12:51 AM
To: Takeshi Takahashi <takeshi_takahashi@nict.go.jp>;
draft-ietf-nvo3-arch.all@ietf.org
Cc: iesg@ietf.org; secdir@ietf.org; nvo3@ietf.org; Black, David
<david.black@emc.com>
Subject: RE: Secdir review of draft-ietf-nvo3-arch-06

 

Take-san,

 

Thank you for the review.   I've made changes to address all of your
comments in my working copy of this draft that will be posted as the -07
version next week.

 

The minor comment on information leakage affects both the data plane and
control plane and hence I've made changes to address it in two paragraphs in
the Security Considerations section.  Here are the revised versions of both
paragraphs:

 

For the data plane, tunneled application traffic may need protection against
being misdelivered, modified, or having its content exposed to an
inappropriate third party. In all cases, encryption between authenticated
tunnel endpoints and enforcing policies that control which endpoints and VNs
are permitted to exchange traffic can be used to mitigate risks.

 

[...]

 

Leakage of sensitive information about users or other entities associated
with VMs whose traffic is virtualized can also be covered by using
encryption for the control plane protocols and enforcing policies that
control which NVO3 components are permitted to exchange control plane
traffic.

 

Thanks, --David

 

From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] 
Sent: Friday, August 12, 2016 11:11 AM
To: draft-ietf-nvo3-arch.all@ietf.org
<mailto:draft-ietf-nvo3-arch.all@ietf.org> 
Cc: iesg@ietf.org <mailto:iesg@ietf.org> ; secdir@ietf.org
<mailto:secdir@ietf.org> ; nvo3@ietf.org <mailto:nvo3@ietf.org> 
Subject: Secdir review of draft-ietf-nvo3-arch-06

 

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.

These comments were written primarily for the benefit of the security area
directors.

Document editors and WG chairs should treat these comments just like any
other last call comments.

 

[General summary]

This document is ready.

 

[Topic of this draft]

This informational document describes a high-level overview architecture for
building data center network viatualization overlay (NVO3) networks.

It breaks down the architecture and defines several components needed for
realizing the architecture, such as Network Virtualization Edge (NVE) and
Network Virtualization Authority (NVA).

 

[Minor Comment]

In Section 16 "Security Considerations", you could consider addressing the
policy enforcement issue you've discussed in Section 5.4.

The sentence starting with "Leakage of sensitive information" could be, for
instance, changed from "...by using encryption" to "...by using encryption
and ensuring policy enforcement".

 

[Editorial Comment]

In Page 9, there is a sentence "NVAs provide a service, and NVEs access that
service via an NVE-to-NVA protocol as discussed in Section 4.3."

This current sentence is fine, but referring Section 8 "NVE-to-NVA Protocol"
(instead of Section 4.3 "NVE State") could be better.

 

In Section 2, definition of "VLAN": "are used in this document denote a
C-VLAN", could be "are used in this document to denote a C-VLAN".

 

I enjoyed reading the draft.

 

Thank you.

Take