Re: [nvo3] FW: New Version Notification for draft-wei-nvo3-security-framework-01.txt

Melinda Shore <melinda.shore@gmail.com> Tue, 17 July 2012 20:09 UTC

Return-Path: <melinda.shore@gmail.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4832E21F8627 for <nvo3@ietfa.amsl.com>; Tue, 17 Jul 2012 13:09:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.549
X-Spam-Level:
X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnJh2vheMsoC for <nvo3@ietfa.amsl.com>; Tue, 17 Jul 2012 13:09:08 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B5B7121F8624 for <nvo3@ietf.org>; Tue, 17 Jul 2012 13:09:08 -0700 (PDT)
Received: by yhq56 with SMTP id 56so940415yhq.31 for <nvo3@ietf.org>; Tue, 17 Jul 2012 13:09:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=dcPyb5dsSH5MhgYnnoMJCccoNvnWOEUGBSPEDvFsGWI=; b=GO+/2XPuz566s7OpetQGM1PyRWoWACXcDQSzN1RST+ez0J0LDoIW0DFh8gSzwv+f9y bYAkzA4x02IwNGHcvVl7dyTTeYhn7V4O+JnzJWaRQFApKeSk4g/CunaR0AJ/MpyWHdeZ TQdN+zTCgdolC/BnGfIEWjq5tIxXTMDTqPA3vB0xSp28EuX8FKcjaND5/1Dx2aMU98Ie 4Xrs1367pYGSQAXUYDqs/f/m9J7EFS98Ge/2PmVCYdArN1sH9qgPOnj8h/xV13u10Otd MocgdBZjjB4I3ZsLoTn5fILc4mbGQ92sIdkg9AnAgFGHsSSd1wGZWH+6i1emN8t/9dkK S53Q==
Received: by 10.68.222.163 with SMTP id qn3mr1883440pbc.135.1342555796280; Tue, 17 Jul 2012 13:09:56 -0700 (PDT)
Received: from spandex.local (216-67-41-146-rb1.fai.dsl.dynamic.acsalaska.net. [216.67.41.146]) by mx.google.com with ESMTPS id ru10sm14622046pbc.50.2012.07.17.13.09.54 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Jul 2012 13:09:55 -0700 (PDT)
Message-ID: <5005C691.206@gmail.com>
Date: Tue, 17 Jul 2012 12:09:53 -0800
From: Melinda Shore <melinda.shore@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: "Luyuan Fang (lufang)" <lufang@cisco.com>
References: <0DB8F45437AB844CBB5102F807A0AD9301E4F4@xmb-rcd-x03.cisco.com> <5005B7D0.6030103@gmail.com> <0DB8F45437AB844CBB5102F807A0AD9301E5C4@xmb-rcd-x03.cisco.com>
In-Reply-To: <0DB8F45437AB844CBB5102F807A0AD9301E5C4@xmb-rcd-x03.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "nvo3@ietf.org" <nvo3@ietf.org>
Subject: Re: [nvo3] FW: New Version Notification for draft-wei-nvo3-security-framework-01.txt
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "L2 \"Network Virtualization Over L3\" overlay discussion list \(nvo3\)" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nvo3>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jul 2012 20:09:09 -0000

On 7/17/12 11:58 AM, Luyuan Fang (lufang) wrote:
> About the 'trusted', 'untrusted', they are not new. The terms are
> used in IETF RFCs/drafts all the time. I think it helps to first
> establish the reference points from which direction/zone the security
> threat are coming from, then talk about threads and requirements.

They are, but to be honest I don't think I've seen them used like
this, anywhere.  It was certainly the case that, for example,
rserpool tried to make similar assumptions about the security of
so-called "trusted networks" and was, uh, gently corrected.

And as I mentioned the last time around, and was not answered,
there's a question of scoping here:  do you really want this
draft only to be applicable to cases when there's a high degree
of "trust" of all devices connected to a given overlay?

Melinda