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.
- Re: [dna] Review of draft-ietf-dna-simple-11 Laganier, Julien
- [dna] Review of draft-ietf-dna-simple-11 Ted Lemon
- Re: [dna] Review of draft-ietf-dna-simple-11 Bernard Aboba
- Re: [dna] Review of draft-ietf-dna-simple-11 Bernard Aboba
- Re: [dna] Review of draft-ietf-dna-simple-11 Bernard Aboba
- Re: [dna] Review of draft-ietf-dna-simple-11 Bernard Aboba
- Re: [dna] Review of draft-ietf-dna-simple-11 Thomas Narten
- Re: [dna] Review of draft-ietf-dna-simple-11 Bernard Aboba
- Re: [dna] Review of draft-ietf-dna-simple-11 Ted Lemon
- Re: [dna] Review of draft-ietf-dna-simple-11 Erik Nordmark
- Re: [dna] Review of draft-ietf-dna-simple-11 Bernard Aboba
- Re: [dna] Review of draft-ietf-dna-simple-11 Erik Nordmark