Re: [dna] next steps on draft-ietf-dna-simple

Suresh Krishnan <suresh.krishnan@ericsson.com> Thu, 10 December 2009 20:43 UTC

Return-Path: <suresh.krishnan@ericsson.com>
X-Original-To: dna@core3.amsl.com
Delivered-To: dna@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B92193A6A4E; Thu, 10 Dec 2009 12:43:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 P0nR+uNx0QUa; Thu, 10 Dec 2009 12:43:24 -0800 (PST)
Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id BD09928C0F8; Thu, 10 Dec 2009 12:43:24 -0800 (PST)
Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id nBAKhTBJ008601; Thu, 10 Dec 2009 14:43:29 -0600
Received: from [142.133.10.113] (147.117.20.212) by eusaamw0707.eamcs.ericsson.se (147.117.20.92) with Microsoft SMTP Server id 8.1.375.2; Thu, 10 Dec 2009 15:43:01 -0500
Message-ID: <4B215D08.4090603@ericsson.com>
Date: Thu, 10 Dec 2009 15:41:44 -0500
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Jari Arkko <jari.arkko@piuha.net>
References: <4B0655CB.2040309@piuha.net> <4B203D25.5090409@ericsson.com> <BLU137-DS1F32A2E3E81C6B537AB94938D0@phx.gbl> <4B21272D.7060605@piuha.net> <79625CA2-73A1-487A-B156-EA36A3C8FFCB@fugue.com> <2974_1260465028_4B212B84_2974_10463418_1_4B212B6C.9020404@piuha.net>
In-Reply-To: <2974_1260465028_4B212B84_2974_10463418_1_4B212B6C.9020404@piuha.net>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "dna@ietf.org" <dna@ietf.org>, IESG <iesg@ietf.org>, "draft-ietf-dna-simple@tools.ietf.org" <draft-ietf-dna-simple@tools.ietf.org>
Subject: Re: [dna] next steps on draft-ietf-dna-simple
X-BeenThere: dna@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNA working group mailing list <dna.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dna>, <mailto:dna-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dna>
List-Post: <mailto:dna@ietf.org>
List-Help: <mailto:dna-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dna>, <mailto:dna-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Dec 2009 20:43:25 -0000

Hi Jari/Ted/Bernard,
  Sounds good. I will add the following text to the security 
considerations section.

Unless SEND or other form of secure address configuration is used, the
DNA procedure does not in itself provide positive, secure authentication
of the router(s) on the network, or authentication of the network
itself, as e.g. would be provided by mutual authentication at the link
layer. Therefore when such assurance is not available, the host MUST NOT
make any security-sensitive decisions based on the DNA procedure alone.
In particular, it MUST NOT decide that it has moved from an untrusted to 
a trusted network, and MUST NOT make any security decisions that depend 
on the determination that such a transition has occurred.

Thanks
Suresh

On 09-12-10 12:10 PM, Jari Arkko wrote:
> Thanks. This is better. Suresh, more text for you to include...
> 
> Jari
> 
> Ted Lemon wrote:
>> On Dec 10, 2009, at 10:51 AM, Jari Arkko wrote:
>>   
>>> In particular, it MUST NOT decide it has rejoined a network known to be physically secure, and proceed to abandon cryptographic protection.
>>>     
>> I really don't like this language, because it implies that there is such a thing as a network that's physically secure, and because it suggests that there are networks on which secure protocols need not be run.   Recent history would suggest otherwise (see yesterday's articles about penetration of ATM networks, for instance).
>>
>> I would rather see something like this:
>>
>> In particular, it MUST NOT decide that it has moved from an untrusted to a trusted network, and MUST NOT make any security decisions that depend on the determination that such a transition has occurred.
>>
>> _______________________________________________
>> dna mailing list
>> dna@ietf.org
>> https://www.ietf.org/mailman/listinfo/dna
>>
>>   
>