Re: [secdir] SecDir review of draft-ietf-dna-simple-11

Suresh Krishnan <suresh.krishnan@ericsson.com> Wed, 09 December 2009 23:36 UTC

Return-Path: <suresh.krishnan@ericsson.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 C4AD93A6782; Wed, 9 Dec 2009 15:36:11 -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 WglBJHbIcRFv; Wed, 9 Dec 2009 15:36:11 -0800 (PST)
Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id E856A3A63EB; Wed, 9 Dec 2009 15:36:10 -0800 (PST)
Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id nB9Na7nD002856; Wed, 9 Dec 2009 17:36:16 -0600
Received: from [142.133.10.113] (147.117.20.212) by eusaamw0712.eamcs.ericsson.se (147.117.20.182) with Microsoft SMTP Server id 8.1.375.2; Wed, 9 Dec 2009 18:35:47 -0500
Message-ID: <4B203408.7090805@ericsson.com>
Date: Wed, 9 Dec 2009 18:34:32 -0500
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Yaron Sheffer <yaronf@checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888AD7B@il-ex01.ad.checkpoint.com>
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888AD7B@il-ex01.ad.checkpoint.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "draft-ietf-dna-simple.all@tools.ietf.org" <draft-ietf-dna-simple.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, secdir <secdir@ietf.org>
Subject: Re: [secdir] SecDir review of draft-ietf-dna-simple-11
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: Wed, 09 Dec 2009 23:36:11 -0000

Hi Yaron,
     Thanks for your detailed review. Sorry for the delayed response.

On 09-11-18 12:56 PM, Yaron Sheffer wrote:
> The Security Considerations are focused on one specific aspect, namely 
> the use of SEND. I think we should make clear here that none of the DNA 
> operations by themselves add any measure of security, unless SEND is 
> actually used. Specifically, I suggest to add the text: “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. In 
> particular, it MUST NOT decide it has rejoined a network known to be 
> physically secure, and proceed to abandon cryptographic protection.”

Sounds good. Will add the text into the Security considerations.

> 
>  
> 
> Other Comments
> 
>  
> 
> 4.1: DUID - is this the host’s DUID or the router's? Per RFC 3315, both 
> have such a value.

The client's DUID. This section probably needs a rework anyway to add a 
few more fields. I will clarify this in the next rev.


> 
> 4.3: "all currently configured IP addresses" - but only for this 
> physical interface, right?

Yes. Propose rewording to

"After the indication is received on an interface, the host considers 
all  (non-tentative) IP addresses currently configured on this interface 
to be deprecated until the change detection process completes."


> 
> 4.8: why is no DAD performed? Someone else might have joined the network 
> while I was disconnected, and has a duplicate of my address.

One reason is that this issue can already occur in current networks due 
to network partioning and merging, DAD packet loss etc. We attempted to 
quantify the conditions under which DAD should or should not be 
performed but there was strong working group consensus against doing so 
and strong consensus for adding this current text.

Thanks
Suresh