Re: [dna] Review of draft-ietf-dna-simple-11

"Bernard Aboba" <bernard_aboba@hotmail.com> Tue, 24 November 2009 18:36 UTC

Return-Path: <bernard_aboba@hotmail.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 A86C528C145 for <dna@core3.amsl.com>; Tue, 24 Nov 2009 10:36:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.689
X-Spam-Level:
X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_00=-2.599]
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 C6PCv9r3xw+D for <dna@core3.amsl.com>; Tue, 24 Nov 2009 10:36:25 -0800 (PST)
Received: from blu0-omc4-s8.blu0.hotmail.com (blu0-omc4-s8.blu0.hotmail.com [65.55.111.147]) by core3.amsl.com (Postfix) with ESMTP id BD3E23A67C1 for <dna@ietf.org>; Tue, 24 Nov 2009 10:36:25 -0800 (PST)
Received: from BLU137-DS7 ([65.55.111.137]) by blu0-omc4-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 10:36:21 -0800
X-Originating-IP: [24.19.160.219]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU137-DS7D8F2D05AFDEC9B1F1531939D0@phx.gbl>
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: 'Ted Lemon' <mellon@fugue.com>, dna@ietf.org
References: <B3D250DF-D059-48D3-8867-CB1645038382@fugue.com>
In-Reply-To: <B3D250DF-D059-48D3-8867-CB1645038382@fugue.com>
Date: Tue, 24 Nov 2009 10:36:32 -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: AcptLuTq2KBG1odbSZW5OOLQvFqBIQABFTrA
Content-Language: en-us
X-OriginalArrivalTime: 24 Nov 2009 18:36:21.0234 (UTC) FILETIME=[04A8B520:01CA6D35]
Subject: Re: [dna] Review of draft-ietf-dna-simple-11
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: Tue, 24 Nov 2009 18:36:26 -0000

Ted Lemon said:

"Section 4.7.1 also seems to have a problem in that in this case we
have started the Confirm process before we receive an RA.  If the RA
conflicts with the address we are attempting to confirm, we may know
this to be the case before we get a reply (or no reply) from a DHCPv6
server.  This could be because the RA comes before the DHCPv6 Reply
message, or it could be because the link has in fact changed, and
there is no DHCPv6 server on the new link.  In either case, there is
no need to wait for the response from the DHCPv6 server."

[BA] I agree that there is no need to wait.  As Ralph noted, 
simple DNAv6 shouldn't be suggesting that a DHCPv6 exchange be 
initiated prior to the RS/RA exchange.  Rather, it should just 
co-exist with whatever the implementation already does.  

Ted Lemon also said:

"Also, 4.7.1 doesn't talk about what to do if the NS and RS results
differ, and the NA is secure whereas the RA is not.  In that case it
seems to me that it would make sense to trust the NA rather than the
RA (presumably in that case a trustworthy RA would eventually follow,
since the router that responded to the NS with a secure NA will
presumably send a secure RA in response to the RS).  But there's a
window of opportunity here for a rogue RA to unseat a secure router.

There's a similar problem in section 4.7 because section 4.7 instructs
the implementor to test whether an NA comes from the same router as an
RA, but doesn't talk about what to do if the security of the two
messages differs.  So this is another opportunity for an attacker to
get in a quick DoS.
"

[BA] I agree that a secure NA should take precedence over an insecure RA. 

The same problem exists in section 4.9, where receipt of an NA, RA or
DHCP Reply will terminate other DNA operations, without regard to the
security level of the response that terminates the other state
machines.

[BA] Completion of Simple DNAv6 should not terminate the other state
machines. 
My understanding was that the text in Section 4.9 was only supposed to refer
to termination of the NS/NA probing.  Since Simple DNAv6 isn't supposed to
change the behavior of RS/RA or DHCPv6, terminating other state machines 
isn't appropriate -- and can lead to false positives and negatives in
contradiction to the goals stated in the beginning of the document. 


Section 7 doesn't mention what to do in the dual-stack case.  Maybe
this is too big a can of worms...

[BA] Is there any reason why DNAv4 and DNAv6 can't operate independently? 

I see that some of the issues I mention above are addressed in the
security considerations section.  This is the wrong place for this -
the handling of SEND needs to be wrapped into the spec in section 4.
Security Considerations is the wrong place to put more of the protocol
spec.

[BA] I agree.