From Ted.Lemon@nominum.com Fri Nov 20 11:35:18 2009 Return-Path: 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 1B0CC3A6774 for ; Fri, 20 Nov 2009 11:35:18 -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 y-hPDYnc0YcU for ; Fri, 20 Nov 2009 11:35:17 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id B38393A66B4 for ; Fri, 20 Nov 2009 11:35:16 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSwbvcYkZxeF0t8aTA+3bmod6oh+607Ph@postini.com; Fri, 20 Nov 2009 11:35:14 PST Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 322B61B82D5 for ; Fri, 20 Nov 2009 11:35:13 -0800 (PST) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 20 Nov 2009 11:35:12 -0800 From: Ted Lemon Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Nov 2009 14:35:08 -0500 Message-ID: To: MIME-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-Mailman-Approved-At: Thu, 03 Dec 2009 14:34:04 -0800 Subject: [dna] Review of draft-ietf-dna-simple-11.txt X-BeenThere: dna@ietf.org 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 19:35:18 -0000 Ralph asked participants in the DHC working group to review the draft, = so I gave it a read. I have some comments. I realize that some of = these comments are partially addressed in the summary message Jari sent = to the list recently, but it's difficult to know what to include and = what to leave out, so I just included it all. =46rom section 2.1: o False positives are not acceptable. A host should not conclude that there is no link change when there is one. o False negatives are acceptable. A host can conclude that there is a link change when there is none. This seems backwards, unless there is no cost to a false negative. If a host concludes that there was a link change when there was none, and as a consequence abandons the IP addresses it was using on the previous link, that's going to create a (potentially noticeable) hiccup while it reacquires its address. Depending on the IP stack, it's possible that connections might also be broken, e.g. if a syscall returns EHOSTUNREACH due to a transient routing outage. More, from section 4.3: It SHOULD also set all Neighbor Cache entries for the routers on its Default Router List to STALE. This is done to speed up the acquisition of a new default router when link change has occurred. It's my impression that by default, a stale routing table entry won't be used, so if an application writes to an open tcp connection while the routing table entry is stale, it will get an EHOSTUNREACH, and the connection will be dropped. I have had this exact experience with IPv4 DNA implementations when my WiFi router signal is flaky. This is much worse than taking a long time (500ms isn't really that long) to identify a new link. This would also be a problem in the case where you are on a WiFi network with more than one device advertising the same SSID - when you switch to a new beacon, arguably this is a DNA event, but it would = clearly be a mistake to break existing connections in this case. In section 4.6, the draft seems to be saying that the DHCPv6 client should starty soliciting before it receives an RA. This does actually change the DHCPv6 state machine. In fact, the DHCPv6 protocol has a specific message for checking in the event of a DNA event: the Confirm message. I think Ralph already brought this up; I mention it because it appears to be a problem to me as well. I also think that this section goes into a lot of extra detail that is unnecessary and probably harmful to interoperability, since what it says doesn't really match what RFC3315 says. It would be better to just refer to RFC3315 here. 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. 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. 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. Section 5 provides pseudocode for this process. Thread C of the pseudocode is not asynchronous, and hence not correct. Even if it could be made asynchronous, the protocol spec should be fully descriptive; if it is not, conflicts between the spec and the pseudocode will create interoperability problems, and being sure that the two are the same is an unsolved computer science problem. So section 5 should be deleted. Section 7 doesn't mention what to do in the dual-stack case. Maybe this is too big a can of worms... 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. From mellon@fugue.com Thu Dec 3 15:59:53 2009 Return-Path: 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 D42FC3A684C for ; Thu, 3 Dec 2009 15:59:53 -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 1h7Jhk9rs3qL for ; Thu, 3 Dec 2009 15:59:53 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by core3.amsl.com (Postfix) with ESMTP id 4514B3A6836 for ; Thu, 3 Dec 2009 15:59:53 -0800 (PST) Received: from [IPv6:2001:470:8:11e:226:bbff:fe0c:e5bf] (unknown [IPv6:2001:470:8:11e:226:bbff:fe0c:e5bf]) by toccata.fugue.com (Postfix) with ESMTPSA id 865EF34E43F8; Thu, 3 Dec 2009 17:03:17 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ted Lemon In-Reply-To: Date: Thu, 3 Dec 2009 16:59:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5F019294-2E40-4EBA-82C2-8BE6AA1F27F0@fugue.com> References: To: Ted Lemon X-Mailer: Apple Mail (2.1077) Cc: dna@ietf.org Subject: Re: [dna] Review of draft-ietf-dna-simple-11.txt X-BeenThere: dna@ietf.org 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: Thu, 03 Dec 2009 23:59:53 -0000 On Nov 20, 2009, at 12:35 PM, Ted Lemon wrote: > Ralph asked participants in the DHC working group to review the draft, = so I gave it a read Oops, I accidentally sent this message to the list from an email address = other than the one with which I had subscribed, and consequently had to = resend it. There is no need to read it through again if you already = read it the first time through. Sorry for the duplicate. From erik.nordmark@sun.com Mon Dec 7 06:14:35 2009 Return-Path: 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 0745B3A68B6 for ; Mon, 7 Dec 2009 06:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.701 X-Spam-Level: X-Spam-Status: No, score=-5.701 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 5ZeUnQH-1ytH for ; Mon, 7 Dec 2009 06:14:34 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 35B833A6887 for ; Mon, 7 Dec 2009 06:14:34 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB7EDsDo008715; Mon, 7 Dec 2009 14:14:00 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id nB7EDpuY651800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Dec 2009 06:13:53 -0800 (PST) Message-ID: <4B1D0D9E.3070203@sun.com> Date: Mon, 07 Dec 2009 06:13:50 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.23 (X11/20090929) MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dna@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 14:14:35 -0000 Bernard Aboba wrote: > Ted Lemon said: > > "More, from section 4.3: > > It SHOULD also set all Neighbor > Cache entries for the routers on its Default Router List to STALE. > This is done to speed up the acquisition of a new default router when > link change has occurred. > > It's my impression that by default, a stale routing table entry won't > be used, so if an application writes to an open tcp connection while > the routing table entry is stale, it will get an EHOSTUNREACH, and the > connection will be dropped. I have had this exact experience with > IPv4 DNA implementations when my WiFi router signal is flaky. This is > much worse than taking a long time (500ms isn't really that long) to > identify a new link. > > This would also be a problem in the case where you are on a WiFi > network with more than one device advertising the same SSID - when you > switch to a new beacon, arguably this is a DNA event, but it would clearly > be a mistake to break existing connections in this case. > > [BA] I agree that the paragraph cited does not make sense. RFC 4436 does > not contain equivalent advice. In general, Simple DNAv6 should seek to > minimize connectivity disruption. Perhaps the reference to "STALE" is not clear above? STALE refers to a state in RFC 4861 which implies that the host would trigger NUD sooner rather than later. If it isn't set to STALE then it might take up to 30 seconds more to detect that a router has gone dead. Thus a neighbor cache entry of STALE doesn't have anything to do with a routing table entry (unless the implementation is broken.) Erik From bernard_aboba@hotmail.com Mon Dec 7 08:35:21 2009 Return-Path: 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 F29113A659B for ; Mon, 7 Dec 2009 08:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.432 X-Spam-Level: X-Spam-Status: No, score=-0.432 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_40=-0.185] 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 LMZ5ko3cAsdd for ; Mon, 7 Dec 2009 08:35:20 -0800 (PST) Received: from blu0-omc2-s27.blu0.hotmail.com (blu0-omc2-s27.blu0.hotmail.com [65.55.111.102]) by core3.amsl.com (Postfix) with ESMTP id 05F8A3A68A6 for ; Mon, 7 Dec 2009 08:35:19 -0800 (PST) Received: from BLU137-DS7 ([65.55.111.73]) by blu0-omc2-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 08:35:10 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Erik Nordmark'" References: <4B1D0D9E.3070203@sun.com> In-Reply-To: <4B1D0D9E.3070203@sun.com> Date: Mon, 7 Dec 2009 08:35:27 -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: Acp3R5PTfbtbyxzgTduifDNZWdqJVgAEv2jQ Content-Language: en-us X-OriginalArrivalTime: 07 Dec 2009 16:35:10.0162 (UTC) FILETIME=[3E21EB20:01CA775B] Cc: dna@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 16:35:21 -0000 Erik said: "Perhaps the reference to "STALE" is not clear above? STALE refers to a state in RFC 4861 which implies that the host would trigger NUD sooner rather than later. If it isn't set to STALE then it might take up to 30 seconds more to detect that a router has gone dead. Thus a neighbor cache entry of STALE doesn't have anything to do with a routing table entry (unless the implementation is broken.)" Since simple DNA involves sending out NS and RS packets, if the host has a valid address on the network corresponding to the STALE entry, it will effectively complete NUD as part of DNA. Also, by sending out the RS it will discover whether the router whose entry has been marked STALE is actually there or not. Given this, why would a host take 30 seconds to detect that a router has gone dead? Simple DNA should have completed (with a new default router entry) long before that. From erik.nordmark@sun.com Tue Dec 8 05:52:55 2009 Return-Path: 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 DA58928C12E for ; Tue, 8 Dec 2009 05:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.831 X-Spam-Level: X-Spam-Status: No, score=-5.831 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 QNd-3gUEr7IA for ; Tue, 8 Dec 2009 05:52:54 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 5AC6E3A6857 for ; Tue, 8 Dec 2009 05:52:51 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB8DqUED011578; Tue, 8 Dec 2009 13:52:30 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id nB8DqRh3887796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Dec 2009 05:52:29 -0800 (PST) Message-ID: <4B1E5A19.5020208@sun.com> Date: Tue, 08 Dec 2009 05:52:25 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.23 (X11/20090929) MIME-Version: 1.0 To: Bernard Aboba References: <4B1D0D9E.3070203@sun.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dna@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 13:52:56 -0000 Bernard Aboba wrote: > Erik said: > > "Perhaps the reference to "STALE" is not clear above? > STALE refers to a state in RFC 4861 which implies that the host would > trigger NUD sooner rather than later. If it isn't set to STALE then it > might take up to 30 seconds more to detect that a router has gone dead. > Thus a neighbor cache entry of STALE doesn't have anything to do with a > routing table entry (unless the implementation is broken.)" > > Since simple DNA involves sending out NS and RS packets, if the host > has a valid address on the network corresponding to the STALE entry, > it will effectively complete NUD as part of DNA. Also, by sending > out the RS it will discover whether the router whose entry has > been marked STALE is actually there or not. > > Given this, why would a host take 30 seconds to detect that a router > has gone dead? Simple DNA should have completed (with a new default > router entry) long before that. I was merely responding to Ted's concern, which is unrelated to the use of STALE state. You are asking a different question about the utility of STALE. I have no go over the whole document more carefully, but AFAICT when the host has moved to a new link it needs to make sure old neighbor cache entries don't get in the way. That isn't specified in section 4.8. Marking the NCEs as STALE definitely help with that for the same that the same link-local addresses are in use on the old and new links. Erik From julienl@qualcomm.com Tue Dec 8 09:01:24 2009 Return-Path: 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 7CCE43A68EC for ; Tue, 8 Dec 2009 09:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.604 X-Spam-Level: X-Spam-Status: No, score=-103.604 tagged_above=-999 required=5 tests=[AWL=-1.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 RFwcHpRL8PlH for ; Tue, 8 Dec 2009 09:01:23 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 612833A68E9 for ; Tue, 8 Dec 2009 09:01:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1260291673; x=1291827673; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Erik=20Nordmark=20,=0D=0A =20=20=20=20=20=20=20=20Bernard=20Aboba=0D=0A=09|CC:=20"dna@ietf.org"=20 |Date:=20Tue,=208=20Dec=202009=2009:01:10=20-0800 |Subject:=20RE:=20[dna]=20Review=20of=20draft-ietf-dna-si mple-11|Thread-Topic:=20[dna]=20Review=20of=20draft-ietf- dna-simple-11|Thread-Index:=20Acp4Db/F1Eg+ofiCSdqzVG4hiVZ ogAAGPPMA|Message-ID:=20|References:=20=0D=0A=09=09<4B1D0D9E.30 70203@sun.com>=0D=0A=09=20<4B1E5A19.5020208@sun.com>|In-Reply-To:=20< 4B1E5A19.5020208@sun.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 400,1158,5826"=3B=20a=3D"29378623"; bh=uf6U4rSxyYeQ8Zu56DLqDW8QfFwpslPano/wATsPKrE=; b=FnD5gqGIWlu2tK8+ZAntNRG/u+4ZO3HUbuEl6nt6tkzDj+QdpEkOsHPz M7DvB6EGO/NQ64YPk2n6p8nfusETc/VM/uKySysjFy6NNP7S0xiqvuw1G 949t5nDT15R/h5PoPd5+OrPeKGk7/PkOaOJWt8g9ywljp9MeD2Z3Yeyhp g=; X-IronPort-AV: E=McAfee;i="5400,1158,5826"; a="29378623" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP; 08 Dec 2009 09:01:13 -0800 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB8H1CVK018198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Dec 2009 09:01:13 -0800 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB8H1CdL031407 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 Dec 2009 09:01:12 -0800 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 8 Dec 2009 09:01:12 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Tue, 8 Dec 2009 09:01:12 -0800 From: "Laganier, Julien" To: Erik Nordmark , Bernard Aboba Date: Tue, 8 Dec 2009 09:01:10 -0800 Thread-Topic: [dna] Review of draft-ietf-dna-simple-11 Thread-Index: Acp4Db/F1Eg+ofiCSdqzVG4hiVZogAAGPPMA Message-ID: References: <4B1D0D9E.3070203@sun.com> <4B1E5A19.5020208@sun.com> In-Reply-To: <4B1E5A19.5020208@sun.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dna@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 17:01:24 -0000 Erik Nordmark wrote: >=20 > Bernard Aboba wrote: > > Erik said: > > > > "Perhaps the reference to "STALE" is not clear above? > > STALE refers to a state in RFC 4861 which implies that the host would > > trigger NUD sooner rather than later. If it isn't set to STALE then > > it might take up to 30 seconds more to detect that a router has gone > > dead. Thus a neighbor cache entry of STALE doesn't have anything to=20 > > do with a routing table entry (unless the implementation is broken.)" > > > > Since simple DNA involves sending out NS and RS packets, if the host > > has a valid address on the network corresponding to the STALE entry, > > it will effectively complete NUD as part of DNA. Also, by sending > > out the RS it will discover whether the router whose entry has > > been marked STALE is actually there or not. > > > > Given this, why would a host take 30 seconds to detect that a router > > has gone dead? Simple DNA should have completed (with a new default > > router entry) long before that. >=20 > I was merely responding to Ted's concern, which is unrelated to the use > of STALE state. > You are asking a different question about the utility of STALE. >=20 > I have no go over the whole document more carefully, but AFAICT when > the host has moved to a new link it needs to make sure old neighbor cache > entries don't get in the way. That isn't specified in section 4.8. > Marking the NCEs as STALE definitely help with that for the same that > the same link-local addresses are in use on the old and new links. IIRC marking old NCEs as STALE takes care of a case where the routers on th= e old and new link have the same link-local address. By marking the old NCE= as STALE, one make sure that the new NCE in REACHABLE state will be prefer= red over the old one (the new NCE is in REACHABLE state as a result of rece= iving a solicited RA, or completing NUD with the router.)=20 --julien From suresh.krishnan@ericsson.com Wed Dec 9 16:15:11 2009 Return-Path: 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 6EAA33A68DD; Wed, 9 Dec 2009 16:15:10 -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 9-ZKhCsZ3WiO; Wed, 9 Dec 2009 16:15:06 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 7CF9F3A684F; Wed, 9 Dec 2009 16:15:06 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id nBA0F4C1014318; Wed, 9 Dec 2009 18:15:05 -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 19:14:39 -0500 Message-ID: <4B203D25.5090409@ericsson.com> Date: Wed, 9 Dec 2009 19:13:25 -0500 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Jari Arkko References: <4B0655CB.2040309@piuha.net> In-Reply-To: <4B0655CB.2040309@piuha.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: DNA , "dna@ietf.org" , "draft-ietf-dna-simple@tools.ietf.org" , IESG , Lars Eggert 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 00:15:11 -0000 Hi Jari, Thank you for setting a good way forward with this document and sorry for the delayed response. Please see my responses inline. On 09-11-20 03:39 AM, Jari Arkko wrote: > The IESG reviewed this draft in our meeting yesterday. A number of > issues were brought up, most of it already resolved but some still > remain. Here are the changes that I've entered as RFC Editor notes: > > 1) Updates 4861 issue per Brian Carpenter's review comments: > > Please remove the "Updates 4861" claim from the header. OK. Since a new rev is needed anyway, I will update the draft itself so that the RFC Ed note is not required. > > 2) Unclear specification with respect to what the draft requires about > fast RAs. I believe the current wording referred to draft-ietf-dna-frd. > Some readers thought our specification was requiring a change from the > 4861 rules that dictate a delay before the RS can go out. > > Please remove the following text from Section 2.4: > > As a result, in addition to implementing simple DNA, it is desirable > that routers adopt procedures which allow for fast unicast Router > Advertisement (RA) messages. Will do. > > 3) An additional security consideration issue was brought in secdir review. > > 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 > protection. Will add this text. > > 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. > > Everyone happy with these changes? Also, we have a few remaining issues: Will do. > > 5) Lars asked whether some of the SHOULDs in the document should really > be MUSTs. In my review this is not universally true at least. For > instance, you may give some freedom for implementations to avoid sending > probes if there are too many link up events in a short time period. > However, we'd like you Suresh go through the document and for each > SHOULD think about what the right keyword is. Sometimes it might be a > MUST, sometimes a SHOULD. In some of the cases where its a SHOULD, it > might be good to include a sentence or two about what issues might be > considered when implementing it. I have identified a bunch of SHOULDs that need to be changed to MUSTs. I will try to add explanatory text to the other SHOULDs. > > 6) We need to respond to Ralph Droms' detailed review. (Thank you > Ralph!) I think we can forget the Updates 4861 part of his discuss, but > the rest is relevant. I'm including his Discuss here for completeness sake: I will go over the document and change/remove any text that insinuates that simple dna changes either DHCPv6 or RFC4861 procedures in any way. That should resolve most of the concerns Ralph has raised in this review. Thanks Suresh From bernard_aboba@hotmail.com Wed Dec 9 17:04:37 2009 Return-Path: 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 259B83A684C; Wed, 9 Dec 2009 17:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=0.980, 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 wWFXjjFK8TZJ; Wed, 9 Dec 2009 17:04:36 -0800 (PST) Received: from blu0-omc3-s13.blu0.hotmail.com (blu0-omc3-s13.blu0.hotmail.com [65.55.116.88]) by core3.amsl.com (Postfix) with ESMTP id E4B0A3A6803; Wed, 9 Dec 2009 17:04:35 -0800 (PST) Received: from BLU137-DS1 ([65.55.116.74]) by blu0-omc3-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 17:04:25 -0800 X-Originating-IP: [131.107.0.72] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Suresh Krishnan'" , "'Jari Arkko'" References: <4B0655CB.2040309@piuha.net> <4B203D25.5090409@ericsson.com> In-Reply-To: <4B203D25.5090409@ericsson.com> Date: Wed, 9 Dec 2009 17:04:25 -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: Acp5LdP0gI6yz8TETPelB8CIwuzwvwABk7Kw Content-Language: en-us X-OriginalArrivalTime: 10 Dec 2009 01:04:25.0006 (UTC) FILETIME=[B7109CE0:01CA7934] Cc: 'DNA' , dna@ietf.org, 'Lars Eggert' , 'IESG' , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 01:04:37 -0000 > 3) An additional security consideration issue was brought in secdir review. > > 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 > protection. This text doesn't make sense. In the case where DNA is based on SEND, DNA does provide positive, secure authentication of the router(s) on the network. Also, the document describes how secure address determination, where present, takes precedence over DNA. From erik.nordmark@sun.com Thu Dec 10 03:22:48 2009 Return-Path: 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 2C0213A6AF8 for ; Thu, 10 Dec 2009 03:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[AWL=1.144, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, 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 rTUzkCo0g3lU for ; Thu, 10 Dec 2009 03:22:47 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id F3A023A67E4 for ; Thu, 10 Dec 2009 03:22:46 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nBABMUl7015132; Thu, 10 Dec 2009 11:22:30 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id nBABMQ2t164761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 03:22:29 -0800 (PST) Message-ID: <4B20D9A2.70406@sun.com> Date: Thu, 10 Dec 2009 03:21:06 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.23 (X11/20090929) MIME-Version: 1.0 To: dna@ietf.org, Suresh Krishnan Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dna] Comments on 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 11:22:48 -0000 Bernard's question about STALE made me carefully read the whole document. A few comments and questions. --- Section 2.2 says When a host moves to a completely new link that is previously unknown, the performance of the Simple DNA protocol will be identical to that using standard neighbor discovery procedures [RFC4861]. I don't think this was the intent. The default timers in RFC 4861 means that a host that implements that to the letter will retain the global IPv6 addresses from the old link for 30 days, and retain the old set of default routers 30 minutes. AFAIK the intent is that a DNA host flush information related to the old link when it determines that it has moved to a new link. (Alternatively, flush information learned from a particular router when DNA detects that that router is gone.) In fact, section 4.8 specifies that the addresses in the SDAT must be unconfigured. But we also need to specify what should be done to the default router list, the prefix list, and to Neighbor Cache Entries for link-local addresses (such a addresses might be duplicated between the old and the new link). For the link-local NCEs we can either mark them as STALE or just discarding them. If we do that, then we don't need the STALE text in section 4.3; the state of the NCEs can remain unchanged while the host sends the NS and/or DHCP packets. --- Section 4.1 defines the SDAT and says it contains o Link-local IPv6 address of the router that advertised the prefix. o Link-layer (MAC) address of the router that advertised the prefix. That doesn't specify how things are supposed to work when there is more than one router that advertises the same prefix; a common configuration on LANs. I think it should say "router or routers" above. I wonder if it makes sense to add some more text in section 4.1 to specify that when multiple routers advertise the same prefix a host should independently remove those routers from the SDAT when they stop advertising the prefix. That requires tracking in the SDAT the last time the prefix was heard from each router that advertises it. Related to this is the text in section 4.4 in how the SDAT is used. I suggest that paragraph in 4.4 say something like this: For each of the addresses in the candidate set, the host looks up the SDAT to find out the link-local and MAC addresses of the router or routers that advertised the prefix used to form the address. If multiple routers have advertised the same prefix the host needs to select one router per SDAT; it is RECOMMENDED that it select the router that most recently advertized the prefix. It then sends an unicast Neighbor Solicitations for each candidate SDAT. It is sent to the selected router's link-local address. The host SHOULD NOT send unicast Neighbor Solicitations to a test node corresponding to an IPv6 address that is no longer valid. (BTW: I don't understand what a "test node" is hence I don't understand the last sentence above that I copied from the draft, so I left it alone.) --- We had talked about the SDAT retaining information from previously visited links but the document is rather silent on the whole area of SDAT management; when are things added and deleted from the SDAT? If a host is allowed to retain the SDAT until the prefixes time out (or the default router lifetime times out?) then we should say that somewhere in the document. --- Section 4.7 says before utilizing the configuration associated with the detected network (prefixes, MTU etc.). That wording implies that the host had somehow stopped using the state earlier, but there is no text in the documenting saying it should stop using the state before the probing. I think we can *describe* the same protocol behavior in two different ways: 1. The host stops using all information (prefixes, default routers, NCEs) when it gets the link-up indication. As a result of gathering the results it will reinstate (possibly a subset) of that information. If the host remembers SDAT information from previous links it will reinstate that information when it receives a NA or RA from that router (matching source MAC and source IP address). 2. The host continues as normal while sending the probes. As it gathers the results it might conclude that the information currently used is no longer valid. If it hears from an old router it will reinstate information from that router. The above text in 4.7 seems to assume description #1 (but the "stop using" part is missing from the document) but the text in section 4.8 about removing addresses assume #2. We should use a single way to describe this in the document. --- Section 4.8 has what is either a typo or a fundamental misunderstanding. It says o The host SHOULD select a default router as described in [RFC4861]. But RFC 4861 doesn't talk about selecting *a* default router; it specifies that hosts maintain a default router list. Thus I don't know what the above bullet is trying to convey. Can it be removed? --- Question on this text in 4.7: When the host receives an advertisement containing only prefixes which are disjoint from known advertised prefixes, the host MUST determine whether the solicited advertisement corresponds to any of the routers probed via NS. If it does, then the host SHOULD conclude that the IPv6 addresses corresponding to that router are no longer valid. Since any NS probes to that router will no longer provide useful information, further probing of that router SHOULD be aborted. Thus the last sentence imply that the (now incorrect) information for that router should be removed from the SDAT? --- Question: How does a host tell that a RA is sent in response to a a particular host's RS? Section 4.7 says When the host receives a Router Advertisement in reply to the Router Solicitation it sent, ... The only possibility I can think of is when the RA is unicast. If that is the case then it would make sense to add "unicast" to the above text. --- Erik From erik.nordmark@sun.com Thu Dec 10 07:44:04 2009 Return-Path: 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 5BE3F3A6A81 for ; Thu, 10 Dec 2009 07:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.99 X-Spam-Level: X-Spam-Status: No, score=-5.99 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 qvphzcyieK2b for ; Thu, 10 Dec 2009 07:44:03 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 55FB13A6A82 for ; Thu, 10 Dec 2009 07:44:03 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBAFho0S015236; Thu, 10 Dec 2009 15:43:50 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id nBAFhkIa190862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 07:43:48 -0800 (PST) Message-ID: <4B211731.2000003@sun.com> Date: Thu, 10 Dec 2009 07:43:45 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.23 (X11/20090929) MIME-Version: 1.0 To: Greg Daley Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dna@ietf.org Subject: [dna] Comments on draft-ietf-dna-tentative-04 X-BeenThere: dna@ietf.org 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: Thu, 10 Dec 2009 15:44:04 -0000 I read this document as well, and I have some editorial comments to make it more clear. FWIW I found this paragraph hard to understand: The proposed IPv6 Duplicate Address Detection (DAD) Optimization "Optimistic DAD" defines a set of recoverable procedures which allow a node to make use of an address before DAD completes. Essentially, Optimistic DAD forbids usage of certain Neighbour Discovery options which could pollute active neighbour cache entries, while an address is tentative. It reads as as if the name of this proposal/document is "Optimistic DAD", but that is a reference to RFC 4429, right? That is an RFC and not just something that is proposed. Is the intent to say: The "Optimistic DAD" protocol [RFC4429] defines a set of recoverable procedures which allow a node to make use of an address before DAD completes. Optimistic DAD forbids usage of certain Neighbour Discovery options which could pollute active neighbour cache entries, while an address is tentative. I'd suggest replacing: Length The length of the option (including the type and length fields) in units of 8 octets. With: Length 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. The value 0 is invalid. Nodes MUST silently discard an ND packet that contains an option with length zero. In section 2.2 we have The differing neighbour cache entry MUST NOT be affected by the reception of the Tentative Option. This ensures that tentative addresses are unable to modify legitimate neighbour cache entries. Thus this MUST NOT mean that a NCE can not be created? Or does "differing" imply that only the MUST NOT only talks about the case when a NCE already exists for the Source IPv6 address? The preceeding sentence already says the latter, so we don't need to repeat it with more difficult to understand wording. Nit: "unable to" in passive voice reads a bit oddly. Can we say "cannot be added" instead? Then we have For these messages, no Neighbour Cache entry may be created, although response messages may be directed to a particular unicast address. which is more words but less clarity. The document needs to explicitly say, for the case when no NCE exists for the Source IPv6 address, whether or not an NCE can be created based on the TO option. Section 4 answers that question, but I still think section 2.2 should be made more concise. Section 4.1 has this In the case that a cache entry is unable to be created or updated due to existence of a conflicting neighbour cache entry, it MUST NOT update the neighbour cache entry. which reads as a tautology; if must not be updated, in the case that it wasn't updated. I suspect there there might be a desire to say When a node receives a ND message with a TO option, and a Neighbor Cache entry already exists with a different link-layer address than what is in the TO option, then the receiver MUST NOT perform any changes to the Neighbor Cache. Basically not only must not the address be updated, but the state etc must not be updated either. Was that the intended meaning of the text? I suspect section 4.1 can be made more clear with less use of passive voice. Also, section 4.1 and 4.2 seems to have overlapping text. Should 4.1 just be about message validation, and 4.2 the processing of a received NS/RS with TO? Finally two non-editorial questions: Is an implementation allowed to use the TO option to send a reply to a NS or RS in the case that a differing NCE exists? The document doesn't talk about that and it might be a useful optimization in some cases. Is an implementation allowed to include TO in NS/RS messages that have an unspecified source address? The second question is answered in an appendix. That constraint should be made part of the main text. Erik From jari.arkko@piuha.net Thu Dec 10 08:52:12 2009 Return-Path: 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 8142D3A6AA2; Thu, 10 Dec 2009 08:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 wSY5d8u8PqJK; Thu, 10 Dec 2009 08:52:11 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 48C743A6A94; Thu, 10 Dec 2009 08:52:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 97767D4988; Thu, 10 Dec 2009 18:51:59 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blkfGyvk3nJt; Thu, 10 Dec 2009 18:51:59 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id F11D4D4974; Thu, 10 Dec 2009 18:51:58 +0200 (EET) Message-ID: <4B21272D.7060605@piuha.net> Date: Thu, 10 Dec 2009 18:51:57 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Bernard Aboba References: <4B0655CB.2040309@piuha.net> <4B203D25.5090409@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: 'DNA' , dna@ietf.org, draft-ietf-dna-simple@tools.ietf.org, 'IESG' , 'Lars Eggert' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 16:52:12 -0000 Bernard, >> 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. >> > > This text doesn't make sense. In the case where DNA is based on SEND, DNA > does provide positive, > secure authentication of the router(s) on the network. Also, the document > describes how > secure address determination, where present, takes precedence over DNA. > Ok. How about this: "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 it has rejoined a network known to be physically secure, and proceed to abandon cryptographic protection." Jari From bernard_aboba@hotmail.com Thu Dec 10 08:58:01 2009 Return-Path: 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 43D1628C126; Thu, 10 Dec 2009 08:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.654 X-Spam-Level: X-Spam-Status: No, score=-1.654 tagged_above=-999 required=5 tests=[AWL=0.944, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 g927t8Plri8q; Thu, 10 Dec 2009 08:58:00 -0800 (PST) Received: from blu0-omc2-s7.blu0.hotmail.com (blu0-omc2-s7.blu0.hotmail.com [65.55.111.82]) by core3.amsl.com (Postfix) with ESMTP id 6EE9B28C116; Thu, 10 Dec 2009 08:58:00 -0800 (PST) Received: from BLU137-W21 ([65.55.111.72]) by blu0-omc2-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 08:57:49 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_d96913d7-ff5d-4333-b777-cb72b285eb17_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Jari Arkko Date: Thu, 10 Dec 2009 08:57:48 -0800 Importance: Normal In-Reply-To: <4B21272D.7060605@piuha.net> References: <4B0655CB.2040309@piuha.net> <4B203D25.5090409@ericsson.com> , <4B21272D.7060605@piuha.net> MIME-Version: 1.0 X-OriginalArrivalTime: 10 Dec 2009 16:57:49.0358 (UTC) FILETIME=[E78404E0:01CA79B9] Cc: Lars, Dna , dna@ietf.org, draft-ietf-dna-simple@tools.ietf.org, "iesg@ietf.org" , Eggert 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 16:58:01 -0000 --_d96913d7-ff5d-4333-b777-cb72b285eb17_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is fine. > Ok. How about this: >=20 > "Unless SEND or other form of secure address configuration is used=2C the= =20 > DNA procedure does not in itself provide positive=2C secure authenticatio= n=20 > of the router(s) on the network=2C or authentication of the network=20 > itself=2C as e.g. would be provided by mutual authentication at the link= =20 > layer. Therefore when such assurance is not available=2C the host MUST NO= T=20 > make any security-sensitive decisions based on the DNA procedure alone.=20 > In particular=2C it MUST NOT decide it has rejoined a network known to be= =20 > physically secure=2C and proceed to abandon cryptographic protection." >=20 > Jari >=20 = --_d96913d7-ff5d-4333-b777-cb72b285eb17_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is fine.

>=3B Ok. How about this:
>=3B
>=3B "Unles= s SEND or other form of secure address configuration is used=2C the
>= =3B DNA procedure does not in itself provide positive=2C secure authenticat= ion
>=3B of the router(s) on the network=2C or authentication of the = network
>=3B itself=2C as e.g. would be provided by mutual authentica= tion at the link
>=3B layer. Therefore when such assurance is not ava= ilable=2C the host MUST NOT
>=3B make any security-sensitive decision= s based on the DNA procedure alone.
>=3B In particular=2C it MUST NOT= decide it has rejoined a network known to be
>=3B physically secure= =2C and proceed to abandon cryptographic protection."
>=3B
>=3B = Jari
>=3B
= --_d96913d7-ff5d-4333-b777-cb72b285eb17_-- From jari.arkko@piuha.net Thu Dec 10 09:08:16 2009 Return-Path: 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 C5DA03A6B14; Thu, 10 Dec 2009 09:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 INx2pCnvfII4; Thu, 10 Dec 2009 09:08:16 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id EC6D23A6ACF; Thu, 10 Dec 2009 09:08:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1D681D4946; Thu, 10 Dec 2009 19:08:04 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXeLzktAeK7v; Thu, 10 Dec 2009 19:08:03 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 761DED4930; Thu, 10 Dec 2009 19:08:03 +0200 (EET) Message-ID: <4B212AF2.6080201@piuha.net> Date: Thu, 10 Dec 2009 19:08:02 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Bernard Aboba References: <4B0655CB.2040309@piuha.net> <4B203D25.5090409@ericsson.com> , <4B21272D.7060605@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dna , dna@ietf.org, draft-ietf-dna-simple@tools.ietf.org, "iesg@ietf.org" , Lars Eggert 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 17:08:17 -0000 Ok. Suresh, can you make this a part of the new version? Thanks. Jari Bernard Aboba wrote: > This is fine. > > > Ok. How about this: > > > > "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 it has rejoined a network known to be > > physically secure, and proceed to abandon cryptographic protection." > > > > Jari > > From mellon@fugue.com Thu Dec 10 09:08:46 2009 Return-Path: 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 DCAF03A6B21; Thu, 10 Dec 2009 09:08:45 -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 biNLAtO02Bkr; Thu, 10 Dec 2009 09:08:45 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by core3.amsl.com (Postfix) with ESMTP id CB4EE3A6ACF; Thu, 10 Dec 2009 09:08:44 -0800 (PST) Received: from [10.0.1.106] (cpe-24-28-83-184.austin.res.rr.com [24.28.83.184]) by toccata.fugue.com (Postfix) with ESMTPSA id 3C8CE34E4417; Thu, 10 Dec 2009 10:12:25 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ted Lemon In-Reply-To: <4B21272D.7060605@piuha.net> Date: Thu, 10 Dec 2009 11:08:31 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <79625CA2-73A1-487A-B156-EA36A3C8FFCB@fugue.com> References: <4B0655CB.2040309@piuha.net> <4B203D25.5090409@ericsson.com> <4B21272D.7060605@piuha.net> To: DNA X-Mailer: Apple Mail (2.1077) Cc: dna@ietf.org, IESG , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 17:08:46 -0000 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. From jari.arkko@piuha.net Thu Dec 10 09:10:22 2009 Return-Path: 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 7CDA03A6891; Thu, 10 Dec 2009 09:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 1ZFOeeWQl96L; Thu, 10 Dec 2009 09:10:18 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id EEFAF3A6801; Thu, 10 Dec 2009 09:10:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 585D4D498A; Thu, 10 Dec 2009 19:10:06 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YZVogSrXPGq; Thu, 10 Dec 2009 19:10:05 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 70C1ED4989; Thu, 10 Dec 2009 19:10:05 +0200 (EET) Message-ID: <4B212B6C.9020404@piuha.net> Date: Thu, 10 Dec 2009 19:10:04 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ted Lemon References: <4B0655CB.2040309@piuha.net> <4B203D25.5090409@ericsson.com> <4B21272D.7060605@piuha.net> <79625CA2-73A1-487A-B156-EA36A3C8FFCB@fugue.com> In-Reply-To: <79625CA2-73A1-487A-B156-EA36A3C8FFCB@fugue.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: DNA , dna@ietf.org, IESG , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 17:10:22 -0000 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 > > From suresh.krishnan@ericsson.com Thu Dec 10 12:43:25 2009 Return-Path: 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 User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Jari Arkko References: <4B0655CB.2040309@piuha.net> <4B203D25.5090409@ericsson.com> <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" , IESG , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 >> >> > From jari.arkko@piuha.net Thu Dec 10 23:51:19 2009 Return-Path: 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 703403A683F; Thu, 10 Dec 2009 23:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 G+CsKF8xyx10; Thu, 10 Dec 2009 23:51:18 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 0024E3A67D1; Thu, 10 Dec 2009 23:51:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 02B9CD498B; Fri, 11 Dec 2009 09:51:06 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLTIRH06eMyt; Fri, 11 Dec 2009 09:51:05 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 1F390D4930; Fri, 11 Dec 2009 09:51:05 +0200 (EET) Message-ID: <4B21F9E8.9060009@piuha.net> Date: Fri, 11 Dec 2009 09:51:04 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Suresh Krishnan References: <4B0655CB.2040309@piuha.net> <4B203D25.5090409@ericsson.com> In-Reply-To: <4B203D25.5090409@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DNA , "dna@ietf.org" , IESG , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 07:51:19 -0000 Your plans sound good, Suresh. Thanks. Jari Suresh Krishnan wrote: > Hi Jari, > Thank you for setting a good way forward with this document and > sorry for the delayed response. Please see my responses inline. > > On 09-11-20 03:39 AM, Jari Arkko wrote: >> The IESG reviewed this draft in our meeting yesterday. A number of >> issues were brought up, most of it already resolved but some still >> remain. Here are the changes that I've entered as RFC Editor notes: >> >> 1) Updates 4861 issue per Brian Carpenter's review comments: >> >> Please remove the "Updates 4861" claim from the header. > > OK. Since a new rev is needed anyway, I will update the draft itself > so that the RFC Ed note is not required. > >> >> 2) Unclear specification with respect to what the draft requires >> about fast RAs. I believe the current wording referred to >> draft-ietf-dna-frd. Some readers thought our specification was >> requiring a change from the 4861 rules that dictate a delay before >> the RS can go out. >> >> Please remove the following text from Section 2.4: >> >> As a result, in addition to implementing simple DNA, it is desirable >> that routers adopt procedures which allow for fast unicast Router >> Advertisement (RA) messages. > > Will do. > >> >> 3) An additional security consideration issue was brought in secdir >> review. >> >> 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 >> protection. > > Will add this text. > >> >> 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. >> >> Everyone happy with these changes? Also, we have a few remaining issues: > > Will do. > >> >> 5) Lars asked whether some of the SHOULDs in the document should >> really be MUSTs. In my review this is not universally true at least. >> For instance, you may give some freedom for implementations to avoid >> sending probes if there are too many link up events in a short time >> period. However, we'd like you Suresh go through the document and for >> each SHOULD think about what the right keyword is. Sometimes it might >> be a MUST, sometimes a SHOULD. In some of the cases where its a >> SHOULD, it might be good to include a sentence or two about what >> issues might be considered when implementing it. > > I have identified a bunch of SHOULDs that need to be changed to MUSTs. > I will try to add explanatory text to the other SHOULDs. > >> >> 6) We need to respond to Ralph Droms' detailed review. (Thank you >> Ralph!) I think we can forget the Updates 4861 part of his discuss, >> but the rest is relevant. I'm including his Discuss here for >> completeness sake: > > I will go over the document and change/remove any text that insinuates > that simple dna changes either DHCPv6 or RFC4861 procedures in any > way. That should resolve most of the concerns Ralph has raised in this > review. > > Thanks > Suresh > > From suresh.krishnan@ericsson.com Mon Dec 14 15:25:23 2009 Return-Path: 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 ECEE63A67F5 for ; Mon, 14 Dec 2009 15:25:22 -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=[AWL=0.000, 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 8NbKwU0ZF7tu for ; Mon, 14 Dec 2009 15:25:21 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id D8D753A63EC for ; Mon, 14 Dec 2009 15:25:20 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id nBENPjh3030411; Mon, 14 Dec 2009 17:25:45 -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; Mon, 14 Dec 2009 18:25:06 -0500 Message-ID: <4B26C8FB.2000808@ericsson.com> Date: Mon, 14 Dec 2009 18:23:39 -0500 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ted Lemon References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "dna@ietf.org" Subject: Re: [dna] Review of draft-ietf-dna-simple-11.txt X-BeenThere: dna@ietf.org 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: Mon, 14 Dec 2009 23:25:23 -0000 Hi Ted, Thanks for your comments. I will do a new revision of this document this week to try to resolve several issues raised by Ralph, Bernard, Erik and you. I would appreciate it if you can look it over after it becomes available. Thanks Suresh Ted Lemon wrote: > Ralph asked participants in the DHC working group to review the draft, so I gave it a read. I have some comments. I realize that some of these comments are partially addressed in the summary message Jari sent to the list recently, but it's difficult to know what to include and what to leave out, so I just included it all. > > From section 2.1: > > o False positives are not acceptable. A host should not conclude > that there is no link change when there is one. > > o False negatives are acceptable. A host can conclude that there is > a link change when there is none. > > This seems backwards, unless there is no cost to a false negative. If > a host concludes that there was a link change when there was none, and > as a consequence abandons the IP addresses it was using on the > previous link, that's going to create a (potentially noticeable) > hiccup while it reacquires its address. Depending on the IP stack, > it's possible that connections might also be broken, e.g. if a syscall > returns EHOSTUNREACH due to a transient routing outage. > > More, from section 4.3: > > It SHOULD also set all Neighbor > Cache entries for the routers on its Default Router List to STALE. > This is done to speed up the acquisition of a new default router when > link change has occurred. > > It's my impression that by default, a stale routing table entry won't > be used, so if an application writes to an open tcp connection while > the routing table entry is stale, it will get an EHOSTUNREACH, and the > connection will be dropped. I have had this exact experience with > IPv4 DNA implementations when my WiFi router signal is flaky. This is > much worse than taking a long time (500ms isn't really that long) to > identify a new link. > > This would also be a problem in the case where you are on a WiFi > network with more than one device advertising the same SSID - when you > switch to a new beacon, arguably this is a DNA event, but it would clearly > be a mistake to break existing connections in this case. > > In section 4.6, the draft seems to be saying that the DHCPv6 client > should starty soliciting before it receives an RA. This does actually > change the DHCPv6 state machine. In fact, the DHCPv6 protocol has a > specific message for checking in the event of a DNA event: the Confirm > message. I think Ralph already brought this up; I mention it because > it appears to be a problem to me as well. > > I also think that this section goes into a lot of extra detail that is > unnecessary and probably harmful to interoperability, since what it > says doesn't really match what RFC3315 says. It would be better to > just refer to RFC3315 here. > > 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. > > 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. > > 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. > > Section 5 provides pseudocode for this process. Thread C of the > pseudocode is not asynchronous, and hence not correct. Even if it > could be made asynchronous, the protocol spec should be fully > descriptive; if it is not, conflicts between the spec and the > pseudocode will create interoperability problems, and being sure that > the two are the same is an unsolved computer science problem. So > section 5 should be deleted. > > Section 7 doesn't mention what to do in the dual-stack case. Maybe > this is too big a can of worms... > > 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. > > > _______________________________________________ > dna mailing list > dna@ietf.org > https://www.ietf.org/mailman/listinfo/dna