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

"Bernard Aboba" <> Fri, 20 November 2009 13:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C17D03A6AC6 for <>; Fri, 20 Nov 2009 05:30:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.326
X-Spam-Status: No, score=-0.326 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_20=-0.74]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j3L-dQ2y17Tq for <>; Fri, 20 Nov 2009 05:30:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 397FD3A68EF for <>; Fri, 20 Nov 2009 05:30:04 -0800 (PST)
Received: from BLU137-DS3 ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 05:30:01 -0800
X-Originating-IP: []
X-Originating-Email: []
Message-ID: <BLU137-DS30C25B4F36BCE5F1D5C4593A10@phx.gbl>
From: "Bernard Aboba" <>
To: "'Jari Arkko'" <>, "'Suresh Krishnan \(QB/EMC\)'" <>, <>, "'Ralph Droms'" <>, "'Lars Eggert'" <>
References: <>
In-Reply-To: <>
Date: Fri, 20 Nov 2009 05:30:13 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcppvQLJ7ItJirIBTUaGOr1PTwr3RgAJZBYg
Content-Language: en-us
X-OriginalArrivalTime: 20 Nov 2009 13:30:01.0757 (UTC) FILETIME=[8FFC14D0:01CA69E5]
Cc: 'DNA' <>,
Subject: Re: [dna] next steps on draft-ietf-dna-simple
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNA working group mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Nov 2009 13:30:06 -0000

Jari said:

  Please add the following text to the end of the security
  considerations section:

  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

[BA] Where SEND is in use, DNA *does* provide positive, secure
authentication of the router(s) on the network.  Also, the procedures
of Section 4.7.1 ensure that DNA does not override secure mechanisms
available on a network, such as DHCPv6 security or SEND.   Therefore,
DNA provides security equivalent to existing procedures. While it's 
true that a host should not make security decisions based on insecure
mechanisms (e.g. insecure DHCPv6 or RS/RA), that advice is not unique
to simple DNA. 

4) Lars Eggert was happy that the draft included retransmission rules, 
but noted that the draft should also set an upper limit on how many 
previous routers are probed.

  Please add the following text to end of Section 4.4:

  A Simple DNA implementation SHOULD limit probing to at most
  six previously seen routers.

[BA] This is fine; existing implementations typically have such a limit.