Re: [secdir] Discussion from the Security Directorate

Joel Jaeggli <joelja@bogus.com> Mon, 27 July 2009 12:10 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DEED28C180 for <secdir@core3.amsl.com>; Mon, 27 Jul 2009 05:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ls2cBA95m+BN for <secdir@core3.amsl.com>; Mon, 27 Jul 2009 05:10:46 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id F3AE728C150 for <secdir@ietf.org>; Mon, 27 Jul 2009 05:10:45 -0700 (PDT)
Received: from [130.129.22.14] (dhcp-160e.meeting.ietf.org [130.129.22.14]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n6RC95rL084300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Jul 2009 12:10:04 GMT (envelope-from joelja@bogus.com)
Message-ID: <4A6D98AC.4060100@bogus.com>
Date: Mon, 27 Jul 2009 14:08:12 +0200
From: Joel Jaeggli <joelja@bogus.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090710)
MIME-Version: 1.0
To: Fred Baker <fred@cisco.com>
References: <EDC652A26FB23C4EB6384A4584434A04018CF83B@307622ANEX5.global.avaya.com> <B40EE4C2-93AE-45A3-89AA-8601BFC76346@huawei.com> <633E561F-48D1-42DE-A310-9E77DB0A87F1@cisco.com>
In-Reply-To: <633E561F-48D1-42DE-A310-9E77DB0A87F1@cisco.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Mon, 27 Jul 2009 12:10:15 +0000 (UTC)
X-Mailman-Approved-At: Mon, 27 Jul 2009 05:24:29 -0700
Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man-ads@tools.ietf.org, secdir@ietf.org, Kurt Erik Lindqvist <kurtis@kurtis.pp.se>, Joe Abley <jabley@ca.afilias.info>, Softwire Chairs <softwire-chairs@tools.ietf.org>, v6ops-ads@tools.ietf.org, softwire-ads@tools.ietf.org, Tina TSOU <tena@huawei.com>, behave-ads@tools.ietf.org, Behave Chairs <behave-chairs@tools.ietf.org>
Subject: Re: [secdir] Discussion from the Security Directorate
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Mon, 27 Jul 2009 12:10:47 -0000

I'd probably tune the slides a bit still:

	Security problems show up in deployment and use, these cannot be
	thought out at all when designing the protocols

Is an assertion you'll get pushback on. we have signficant operational
experience with variations on many of the proposed or deployed
transition mechanisms. necessarily that experience informs both our
current thinking and the desirability of any particular approach.

bump in the wire type transition technologies certainly are an area
potential concern for opsec

Fred Baker wrote:
> Thanks, Tina. I will add this to the IPv6 Operations agenda, probably
> during our second session Tuesday.
> 
> You will note that I am copying the chairs and ADs from several working
> groups. The reason is that the primary thrust of the comments you are
> making apply to work being done in those working groups. Slide 5
> specifically requests a threat analysis, security assessment, and
> "function recommendation" on each transition technology; these are in
> fact being done in behave and softwires. I mention 6man because
> marketing blather from the IPv6 form makes security claims for IPv6,
> which it would be good if that working group clarified.
> 
> I do have to ask specifically what the Security Directorate hopes to
> find in the three documents that have been requested for each of these
> various technologies. What, specifically, is a "function
> recommendation"? A threat analysis is a statement that there exist a set
> of possible threats. Is a security assessment a statement about how
> those threats are responded to? What, if the WGs don't produce it, is
> going to leave the Security Directorate feeling ill-used?
> 
> On Jul 27, 2009, at 12:56 PM, Tina TSOU wrote:
> 
>>
>> B. R.
>> ">http://tinatsou.weebly.com/contact.html
> 
>> Begin forwarded message:
>>
>>> From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
>>> Date: July 27, 2009 7:52:20 AM GMT+02:00
>>> To: Ron Bonica <rbonica@juniper.net>
>>> Cc: Tina TSOU <tena@huawei.com>
>>> Subject: FW: [OPS-DIR] Reminder: OPS-DIR working lunch
>>>
>>> Ron,
>>>
>>> This looks more like an opsec (who are not meeting this time) or v6ops
>>> subject.
>>>
>>> Dan
>>>
>>>
>>> -----Original Message-----
>>> From: Tina TSOU [mailto:tena@huawei.com]
>>> Sent: Monday, July 27, 2009 12:02 AM
>>> To: Romascanu, Dan (Dan)
>>> Subject: Re: [OPS-DIR] Reminder: OPS-DIR working lunch
>>>
>>> Hi Dan,
>>> Could this be discussed at OPS-DIR working lunch?
>> <Recommendation of IPv6 Security work--on the flight-2.ppt>
>> <ATT4180184.txt>
>>