From jari.arkko@lmf.ericsson.se Mon Mar 1 01:13:40 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08328 for ; Mon, 1 Mar 2004 01:13:39 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i216DcqY001922 for ; Mon, 1 Mar 2004 07:13:39 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Mar 2004 07:13:38 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYFN4062; Mon, 1 Mar 2004 07:14:11 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i216DNwg013378; Mon, 1 Mar 2004 07:13:23 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i216CQIt020394; Mon, 1 Mar 2004 07:12:26 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i216CQKU020393; Mon, 1 Mar 2004 07:12:26 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i216CNIt020389 for ; Mon, 1 Mar 2004 07:12:24 +0100 (MET) Message-ID: <032701c3ff54$3a811660$3e6015ac@dclkempt40> From: "James Kempf" To: "Nick 'Sharkey' Moore" , Cc: References: <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> <20040227075924.GA28029@zoic.org> <017401c3ff24$628a6b50$3e6015ac@dclkempt40> <02c401c3ff49$31f1ede0$3e6015ac@dclkempt40> <20040301055112.GA20621@zoic.org> Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275] DAD text inconsistencies) Date: Sun, 29 Feb 2004 22:12:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 01 Mar 2004 06:13:38.0771 (UTC) FILETIME=[565BFA30:01C3FF54] Content-Transfer-Encoding: 7bit > My assumption is that SEND WG will adapt to the changes that RFC2462bis > will make. So if we tweak 2462 to require configuration of a link-local > address per suffix, SEND-CGA nodes will do this. This will then prevent > (well, detect) collision as discussed above. > SEND doesn't use a common suffix, so I am not sure how this applies to them. Basically, SEND will DAD all addresses. Could you clarify? > Why not just specify this in SEND then? Well, because it's a DAD > issue which applies to other protocols which would like to configure > one or more arbitrary suffixes, eg: privacy addressing. > SEND doesn't make changes in the basic DAD algorithm, so it will conform to whatever 2462bis specifies. Since the SEND spec is about to be sent to the IESG, the SEND WG needs to know if any changes are needed in the SEND spec right now. So far, I don't see any. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Mon Mar 1 03:14:12 2004 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00874 for ; Mon, 1 Mar 2004 03:14:11 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i218EAYG001214 for ; Mon, 1 Mar 2004 09:14:11 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Mar 2004 09:14:08 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYFR2PVH; Mon, 1 Mar 2004 09:14:34 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i218Dtwg017991; Mon, 1 Mar 2004 09:13:55 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i218BuIt017286; Mon, 1 Mar 2004 09:11:56 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i218BuYw017285; Mon, 1 Mar 2004 09:11:56 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i218BrIt017279 for ; Mon, 1 Mar 2004 09:11:54 +0100 (MET) Message-ID: <03a901c3ff64$e76f0110$3e6015ac@dclkempt40> From: "James Kempf" To: "Pekka Nikander" , "Nick 'Sharkey' Moore" Cc: , References: <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> <20040227075924.GA28029@zoic.org> <017401c3ff24$628a6b50$3e6015ac@dclkempt40> <02c401c3ff49$31f1ede0$3e6015ac@dclkempt40> <20040301055112.GA20621@zoic.org> Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275] DAD text inconsistencies) Date: Mon, 1 Mar 2004 00:12:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 01 Mar 2004 08:14:08.0955 (UTC) FILETIME=[2BE280B0:01C3FF65] Content-Transfer-Encoding: 7bit > Putting that aside, a SEND node could well *defend* the address > fe80::A for DAD/DIID purposes, but it would never actually use it. > I think that's the issue. Should a SEND or 3041 node be required to defend LL addresses that use suffixes configured for their global unicast addresses even though they will never use the LL addresses? Since it's a backward compatibility issue, I think it would depend on how widely implemented DIID is. If it's not widely implemented, then there's no point in doing it. My personal feeling is that it is an extra bit of signaling that is unnecessary unless there is a widely deployed IPv6 capable OS out there that does DIID. In any event, the SEND spec doesn't need to change, because this behavior would have to be specified in RFC 2462bis since it would apply to 3041 nodes too or for that matter any node that used a different algorithm for configuring its suffix. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Mon Mar 1 04:29:20 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04825 for ; Mon, 1 Mar 2004 04:29:20 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i219TJqY024675 for ; Mon, 1 Mar 2004 10:29:19 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Mar 2004 10:29:19 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYF7GLWB; Mon, 1 Mar 2004 10:29:18 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i219TAwg021759; Mon, 1 Mar 2004 10:29:10 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i219SHIt003405; Mon, 1 Mar 2004 10:28:17 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i219SHbw003403; Mon, 1 Mar 2004 10:28:17 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i219SEIt003399 for ; Mon, 1 Mar 2004 10:28:15 +0100 (MET) Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 9BBF015210; Mon, 1 Mar 2004 18:28:12 +0900 (JST) Date: Mon, 01 Mar 2004 18:28:25 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "James Kempf" Cc: "Pekka Nikander" , "Nick 'Sharkey' Moore" , , Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275] DAD text inconsistencies) In-Reply-To: <03a901c3ff64$e76f0110$3e6015ac@dclkempt40> References: <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> <20040227075924.GA28029@zoic.org> <017401c3ff24$628a6b50$3e6015ac@dclkempt40> <02c401c3ff49$31f1ede0$3e6015ac@dclkempt40> <20040301055112.GA20621@zoic.org> <03a901c3ff64$e76f0110$3e6015ac@dclkempt40> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 01 Mar 2004 09:29:19.0044 (UTC) FILETIME=[AC1B7840:01C3FF6F] >>>>> On Mon, 1 Mar 2004 00:12:11 -0800, >>>>> "James Kempf" said: >> Putting that aside, a SEND node could well *defend* the address >> fe80::A for DAD/DIID purposes, but it would never actually use it. > I think that's the issue. Should a SEND or 3041 node be required to defend > LL addresses that use suffixes configured for their global unicast addresses > even though they will never use the LL addresses? > Since it's a backward compatibility issue, I think it would depend on how > widely implemented DIID is. If it's not widely implemented, then there's no > point in doing it. My personal feeling is that it is an extra bit of > signaling that is unnecessary unless there is a widely deployed IPv6 capable > OS out there that does DIID. > In any event, the SEND spec doesn't need to change, because this behavior > would have to be specified in RFC 2462bis since it would apply to 3041 nodes > too or for that matter any node that used a different algorithm for > configuring its suffix. I agree on all the points. And my conclusion still does not change: I don't see the need for any change on this in rfc2462bis. I don't know the deployment status of the DIID implementation, and we should be careful not to underestimate it. However, I think we should also consider the reality of the problematic case from an operational point of view. Recall the scenario I described again. The problem occurs when the DIID node *happens to* configure fe80::A and P::A. But can this really occur in a practical sense? In this particular case, "A" is a CGA identifier, so it cannot equal to a normal EUI-64 identifier. Also, "A" would look like a non-readable, random 64-bit number, so it should be very unlikely (in a practical sense) for the DIID node's administrator to use it as a manually assigned interface identifier. A similar argument should apply to the case of RFC3041. Meanwhile, if we agree on the proposed change in rfc2462bis (MUST do always DAD for each unicast address), new implementations will simply follow the requirement. Also, existing DIID implementations will gradually migrate to rfc2462bis. So, the actual odds to have the problem will get smaller and smaller (starting with very small odds). It should also be noted that one of the key motivations of the proposed change in rfc2462bis is to simplify the specification and implementation. If we introduce an additional defence algorithm to avoid the "compatibility" issue, the resulting specification will relatively complicated, degrading the effort to simply it. To summarize the points, I'd propose to do nothing on this in rfc2462bis because: - the actual odds of the problem in the real world should be very low, even in the current status. - if we take the proposed change in rfc2462bis, the odds will be getting lower and lower. - if we add something for this to rfc2462bis, the protocol will become complicated, degrading one of the motivations of this clarification. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Mon Mar 1 05:07:37 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06616 for ; Mon, 1 Mar 2004 05:07:37 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i21A7YAh000391 for ; Mon, 1 Mar 2004 11:07:37 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Mar 2004 11:07:34 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYFNW5RT; Mon, 1 Mar 2004 11:08:07 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i21A7Xwg023824; Mon, 1 Mar 2004 11:07:33 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i21A70It012481; Mon, 1 Mar 2004 11:07:00 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i21A70od012479; Mon, 1 Mar 2004 11:07:00 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i21A6xIt012472 for ; Mon, 1 Mar 2004 11:06:59 +0100 (MET) Received: from [IPv6:::1] (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 5B1BA8; Mon, 1 Mar 2004 12:19:36 +0200 (EET) In-Reply-To: References: <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> <20040227075924.GA28029@zoic.org> <017401c3ff24$628a6b50$3e6015ac@dclkempt40> <02c401c3ff49$31f1ede0$3e6015ac@dclkempt40> <20040301055112.GA20621@zoic.org> <03a901c3ff64$e76f0110$3e6015ac@dclkempt40> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2A469A53-6B68-11D8-8A26-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: "Nick 'Sharkey' Moore" , , , "James Kempf" From: Pekka Nikander Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275] DAD text inconsistencies) Date: Mon, 1 Mar 2004 19:06:53 +0900 To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= X-Mailer: Apple Mail (2.612) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 01 Mar 2004 10:07:34.0418 (UTC) FILETIME=[0441BF20:01C3FF75] Content-Transfer-Encoding: 7bit > To summarize the points, I'd propose to do nothing on this in > rfc2462bis because: > > - the actual odds of the problem in the real world should be very low, > even in the current status. > - if we take the proposed change in rfc2462bis, the odds will be > getting lower and lower. > - if we add something for this to rfc2462bis, the protocol will become > complicated, degrading one of the motivations of this clarification. From the SEND point of view, looks good. --Pekka Nikander -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Mon Mar 1 05:47:51 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08798 for ; Mon, 1 Mar 2004 05:47:50 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i21AlpqY019845 for ; Mon, 1 Mar 2004 11:47:51 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Mar 2004 11:47:50 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYFNXF71; Mon, 1 Mar 2004 11:48:20 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i21AljXA003123; Mon, 1 Mar 2004 11:47:45 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i21Al0It021325; Mon, 1 Mar 2004 11:47:00 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i21Al0bA021316; Mon, 1 Mar 2004 11:47:00 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i21AkwIt021300 for ; Mon, 1 Mar 2004 11:46:59 +0100 (MET) Message-ID: <03f301c3ff7a$90214ba0$3e6015ac@dclkempt40> From: "James Kempf" To: Cc: , "IPV6 WG" , "Nick 'Sharkey' Moore" , "Pekka Nikander" References: <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> <20040227075924.GA28029@zoic.org> <017401c3ff24$628a6b50$3e6015ac@dclkempt40> <02c401c3ff49$31f1ede0$3e6015ac@dclkempt40> <20040301055112.GA20621@zoic.org> <03a901c3ff64$e76f0110$3e6015ac@dclkempt40> Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275] DAD text inconsistencies) Date: Mon, 1 Mar 2004 02:47:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 01 Mar 2004 10:47:50.0600 (UTC) FILETIME=[A469DC80:01C3FF7A] Content-Transfer-Encoding: 8bit I agree. jak ----- Original Message ----- From: )> To: "James Kempf" Cc: "Pekka Nikander" ; "Nick 'Sharkey' Moore" ; ; Sent: Monday, March 01, 2004 1:28 AM Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275] DAD text inconsistencies) > >>>>> On Mon, 1 Mar 2004 00:12:11 -0800, > >>>>> "James Kempf" said: > > >> Putting that aside, a SEND node could well *defend* the address > >> fe80::A for DAD/DIID purposes, but it would never actually use it. > > > I think that's the issue. Should a SEND or 3041 node be required to defend > > LL addresses that use suffixes configured for their global unicast addresses > > even though they will never use the LL addresses? > > > Since it's a backward compatibility issue, I think it would depend on how > > widely implemented DIID is. If it's not widely implemented, then there's no > > point in doing it. My personal feeling is that it is an extra bit of > > signaling that is unnecessary unless there is a widely deployed IPv6 capable > > OS out there that does DIID. > > > In any event, the SEND spec doesn't need to change, because this behavior > > would have to be specified in RFC 2462bis since it would apply to 3041 nodes > > too or for that matter any node that used a different algorithm for > > configuring its suffix. > > I agree on all the points. And my conclusion still does not change: > I don't see the need for any change on this in rfc2462bis. > > I don't know the deployment status of the DIID implementation, and we > should be careful not to underestimate it. However, I think we should > also consider the reality of the problematic case from an operational > point of view. > > Recall the scenario I described again. The problem occurs when the > DIID node *happens to* configure fe80::A and P::A. But can this > really occur in a practical sense? In this particular case, "A" is a > CGA identifier, so it cannot equal to a normal EUI-64 identifier. > Also, "A" would look like a non-readable, random 64-bit number, so it > should be very unlikely (in a practical sense) for the DIID node's > administrator to use it as a manually assigned interface identifier. > > A similar argument should apply to the case of RFC3041. > > Meanwhile, if we agree on the proposed change in rfc2462bis (MUST do > always DAD for each unicast address), new implementations will simply > follow the requirement. Also, existing DIID implementations will > gradually migrate to rfc2462bis. So, the actual odds to have the > problem will get smaller and smaller (starting with very small odds). > > It should also be noted that one of the key motivations of the > proposed change in rfc2462bis is to simplify the specification and > implementation. If we introduce an additional defence algorithm to > avoid the "compatibility" issue, the resulting specification will > relatively complicated, degrading the effort to simply it. > > To summarize the points, I'd propose to do nothing on this in > rfc2462bis because: > > - the actual odds of the problem in the real world should be very low, > even in the current status. > - if we take the proposed change in rfc2462bis, the odds will be > getting lower and lower. > - if we add something for this to rfc2462bis, the protocol will become > complicated, degrading one of the motivations of this clarification. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Wed Mar 3 19:42:39 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10406 for ; Wed, 3 Mar 2004 19:42:38 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i240gaqY009552 for ; Thu, 4 Mar 2004 01:42:37 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 4 Mar 2004 01:42:36 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYFSH14G; Thu, 4 Mar 2004 01:43:10 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i240gRwg002327; Thu, 4 Mar 2004 01:42:27 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i240fKIt019133; Thu, 4 Mar 2004 01:41:20 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i240fKlh019131; Thu, 4 Mar 2004 01:41:20 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i240fIIt019123 for ; Thu, 4 Mar 2004 01:41:18 +0100 (MET) Message-ID: <01fe01c40181$78cebc40$5f6115ac@dclkempt40> From: "James Kempf" To: Cc: Subject: Microsoft Free License for CGA Date: Wed, 3 Mar 2004 16:41:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 04 Mar 2004 00:42:36.0856 (UTC) FILETIME=[96F98380:01C40181] Content-Transfer-Encoding: 7bit There has been some question in the Open Source community about the free license granted by Microsoft for CGA in SEND. In particular, I've heard that some people believe end users must apply for a license rather than just implementors. The attached email from Microsoft should help clear up this confusion. In short, the free license is only required from implementors, as is typically the case, and therefore should not unfairly burden end users. jak ----- Original Message ----- From: "Dawna Hoerle (LCA)" To: "James Kempf" Cc: "Pekka Nikander" ; "Microsoft Standards Inquiries" Sent: Wednesday, March 03, 2004 3:48 PM Subject: RE: Question on Microsoft IETF Patent Disclosure for draft-ietf-send-cga-00.txt > My apologies for the late response. I have transitioned to another job > function at MS, so please send any future inquiries re IETF > specifications to stdsreq@microsoft.com. > > Our disclosure statement and thus agreement to license our essential > claims in the CGA spec apply to implementors of the specification. We > will not require end users to obtain a license to use a product which > includes the implementation of CGA specification. > > I hope this addresses your concern, > Dawna > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Tuesday, January 13, 2004 11:43 AM > To: Dawna Hoerle (LCA) > Cc: Kempf; Pekka Nikander > Subject: Question on Microsoft IETF Patent Disclosure for > draft-ietf-send-cga-00.txt > > I'm the co-chair of the SEND IETF Working Group and I have a question on > the patent disclosure for CGA which is: > > http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-ietf-send-cga.txt > > Concern has been expressed that the free license requirement applies to > all users and not just to implementors of the CGA technology. Can you > clarify? > Typically, licenses of this sort apply only to the implementors, as it > would put users at a great inconvenience if every user of a product with > the technology would have to obtain a license. > > jak > > > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Tue Mar 9 07:06:49 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23077 for ; Tue, 9 Mar 2004 07:06:48 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i29C6hqY007813 for ; Tue, 9 Mar 2004 13:06:47 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 9 Mar 2004 13:06:42 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GSLN4RKT; Tue, 9 Mar 2004 13:06:42 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i29C6bwg010214; Tue, 9 Mar 2004 13:06:37 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i29C5IIt022282; Tue, 9 Mar 2004 13:05:18 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i29C5IkL022281; Tue, 9 Mar 2004 13:05:18 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i29C5HIt022277 for ; Tue, 9 Mar 2004 13:05:17 +0100 (MET) Received: from [IPv6:::1] (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 498448; Tue, 9 Mar 2004 14:17:57 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0697D895-71C2-11D8-A780-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: Tuomas Aura From: Pekka Nikander Subject: IESG comments on CGA draft: Summary Date: Tue, 9 Mar 2004 07:05:15 -0500 To: SEND WG X-Mailer: Apple Mail (2.612) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 09 Mar 2004 12:06:42.0821 (UTC) FILETIME=[FC577B50:01C405CE] Content-Transfer-Encoding: 7bit The CGA draft was discussed a couple of weeks ago at the IESG telechat. There were two Comments and one Discuss item. In practise, this means that we have to address the Discuss item but we may either ignore or incorporate the comments; Comments are not blocking. Once we've resolved the Discuss item and Comments at the mailing list, Tuomas should issue a new ID version, which will then advance towards the RFC Editor Queue. The comments are by: 1. Ted Hardie, suggesting some strengthening of wording in text concerning other applications. 2. Thomas Narten, requesting a clarification The Discuss item is by: 3. Russ Housley, requesting a text change and a reference change towards RFC3279 and some other changes. I will send separate mails about these later on; in the mean while, they are available in the Draft Tracker at https://datatracker.ietf.org/public/pidtracker.cgi? command=print_ballot&ballot_id=1205&filename=draft-ietf-send-cga In addition to the IESG comments, we have one typo, recorded by JINMEI earlier: >> More specifically, there are two cases when a node creates neighbor >> cache entries upon receiving Soliciations: >> ... >> 2. During Duplicate Address Detection (DAD), if a node receives a >> Neighbor Solicitation for the same address it is soliciting >> for, >> the situation is considered a collision, and the node must >> cease >> to solicit for the said address. > > "Soliciations should be Solicitations in the first sentence --Pekka Nikander -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Thu Mar 11 12:56:42 2004 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13765 for ; Thu, 11 Mar 2004 12:56:42 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2BHufYG025930 for ; Thu, 11 Mar 2004 18:56:41 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 11 Mar 2004 18:56:40 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id G4AYW7TJ; Thu, 11 Mar 2004 18:57:53 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2BHudXA009696; Thu, 11 Mar 2004 18:56:39 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2BHtdIt028255; Thu, 11 Mar 2004 18:55:39 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2BHtd4b028254; Thu, 11 Mar 2004 18:55:39 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2BHtbIt028250 for ; Thu, 11 Mar 2004 18:55:38 +0100 (MET) Message-ID: <015d01c40792$21f7e3d0$366115ac@dcml.docomolabsusa.com> From: "James Kempf" To: Subject: Resolving Remaining Issues on draft-ietf-send-ndopt-04.txt Date: Thu, 11 Mar 2004 09:56:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 11 Mar 2004 17:56:40.0984 (UTC) FILETIME=[350C6180:01C40792] Content-Transfer-Encoding: 7bit Two issues coming out of WG Last Call need to be resolved prior to sending draft-ietf-send-ndopt-04.txt to the IESG. For reference, the issues can be found at: http://users.piuha.net/jarkko/publications/send/issues/issue68.txt http://users.piuha.net/jarkko/publications/send/issues/issue67.txt Issue 68: Explicit padding length field v.s. implicit padding length as a result of message and field length. Suggested resolution: The draft currently has an explicit padding length, so remain with that. Issue 67: Possible implementation variability when nonce omitted from RA. Suggested resolution: Add following text to paragraph 2, Section 5.3.3, to guide implementation: "Omitting the nonce value may, however, cause the host to ignore the router's advertisement, unless the clocks in these nodes are sufficiently synchronized so that timestamps can be relied on." Please send any comments to the list prior to Tues., March 16. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Fri Mar 12 03:41:40 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08348 for ; Fri, 12 Mar 2004 03:41:39 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2C8fdqY007004 for ; Fri, 12 Mar 2004 09:41:39 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 12 Mar 2004 09:41:38 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GX1GP6GC; Fri, 12 Mar 2004 09:41:38 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2C8fWwg003470; Fri, 12 Mar 2004 09:41:32 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2C8eiIt020862; Fri, 12 Mar 2004 09:40:44 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2C8eijN020861; Fri, 12 Mar 2004 09:40:44 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2C8ehIt020857 for ; Fri, 12 Mar 2004 09:40:43 +0100 (MET) Received: from [IPv6:::1] (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id ECE0A8; Fri, 12 Mar 2004 10:53:22 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Russ Housley , Tuomas Aura From: Pekka Nikander Subject: IESG discuss item on CGA: RSA key encoding details, random number generator, key lifetime Date: Fri, 12 Mar 2004 10:40:43 +0200 To: SEND WG X-Mailer: Apple Mail (2.612) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 12 Mar 2004 08:41:38.0652 (UTC) FILETIME=[D5B989C0:01C4080D] Content-Transfer-Encoding: 7bit Folks, As I wrote before, we have one discuss item from the IESG on the CGA draft. The purpose of this message is to start discussion on this, in order to reach WG consensus on the required changes as soon as possible, preferably before the end of this month. Russ Housley writes: > The first paragraph of section 3 says: > > > > ... For SEND, the public > > key SHOULD be an RSA encryption key with the object identifier > > rsaEncryption (i.e., "1.2.840.113549.1.1.1") and the subject public > > key field SHOULD be formatted as an ASN.1 data structure of the > type > > RSAEncryptionKey defined in [PKCS.1.2002]. ... > > > PKCS #1 v2.1 (14 June 2002) does not specify a type of > RSAEncryptionKey. > I suspect that a type of RSAPublicKey is intended. This type and > the associated object identifier can be found in RFC 3279 (as well as > in PKCS #1 v2.1). The community will be able to easily locate RFC > 3279. > Please refer to section 2.3.1 of RFC 3279. I see the reference to RFC3279 as a detail and I see no problem in fixing this. > Further, the use of SHOULD bothers me. The use of RSA can be > SHOULD, but > the format of fields when RSA is selected ought to be a MUST. I > suggest: > > SEND SHOULD use an RSA public/private key pair. When RSA > is used, the algorithm identifier must be rsaEncryption, which > is 1.2.840.113549.1.1.1, and the RSA public key MUST be formatted > using RSAPublicKey type as specified in section 2.3.1 of RFC 3279. To me this looks fine. It leaves it open what format to use if RSA is not used, which sounds fine to me. At the same time, it is very specific of the format for RSA keys, which also seems fine to me. > In the 1st full paragraph on page 9, Section 4 says: > > > > ... The quality of the random number generator does not affect the > > strength of the binding between the address and the public key. ... > > > This kind of statement will encourage implementors to use a constant, > which is a problem. A SHA-1 hash of the time of day would be okay. Apparently we need some new wording here. Tuomas, could you please suggest some wording? > Section 7.3 ought to reference RFC 1750. 1750 is "Randomness Recommendations for Security". This seems to be a clear case. It looks like that the best place for the reference is after the first paragraph in 7.3. > The security considerations ought to say something about the lifetime > of the public/private key pair. The one brief statement in section > 7.3 > is not sufficient for an implementor to know how often the key pair > needs to be changed. This seems to require some more consideration, as there may be conflicting goals. Some nodes prefer stable addresses. Some nodes prefer relative anonymity. But we seem to require some new text. Tuomas, can you suggest a wording? --Pekka -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Fri Mar 12 05:07:27 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11396 for ; Fri, 12 Mar 2004 05:07:26 -0500 (EST) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2CA7RAh028818 for ; Fri, 12 Mar 2004 11:07:27 +0100 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 12 Mar 2004 11:07:27 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYF4VNCG; Fri, 12 Mar 2004 11:08:25 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2CA7PXA017675; Fri, 12 Mar 2004 11:07:25 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2CA6hIt009705; Fri, 12 Mar 2004 11:06:43 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2CA6hu5009704; Fri, 12 Mar 2004 11:06:43 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2CA6fIt009700 for ; Fri, 12 Mar 2004 11:06:41 +0100 (MET) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2CA6Q003549; Fri, 12 Mar 2004 12:06:26 +0200 Date: Fri, 12 Mar 2004 12:06:26 +0200 (EET) From: Pekka Savola To: James Kempf cc: ietf-send@standards.ericsson.net Subject: Re: Resolving Remaining Issues on draft-ietf-send-ndopt-04.txt In-Reply-To: <015d01c40792$21f7e3d0$366115ac@dcml.docomolabsusa.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 12 Mar 2004 10:07:27.0064 (UTC) FILETIME=[D26ADD80:01C40819] On Thu, 11 Mar 2004, James Kempf wrote: > Two issues coming out of WG Last Call need to be resolved prior to sending > draft-ietf-send-ndopt-04.txt to the IESG. For reference, the issues can be > found at: > > http://users.piuha.net/jarkko/publications/send/issues/issue68.txt > http://users.piuha.net/jarkko/publications/send/issues/issue67.txt > > Issue 68: Explicit padding length field v.s. implicit padding length as a > result of message and field length. > > Suggested resolution: The draft currently has an explicit padding length, so > remain with that. Well, having raised the issue, I'm again repeating that it seems obvious to use implicit padding length. This is what AFAIR all ND-related specifications use, and is very common case to deal with padding as well. Quite simply "Pad Length" seems to be redundant information, and any unnecessary information complicates the specification. (We could change it to an "MBZ" Reserved field, and reuse it later on if needed.) But if there's strong consensus otherwise, I can live with explicit padding as well. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Fri Mar 12 05:16:10 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11643 for ; Fri, 12 Mar 2004 05:16:09 -0500 (EST) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2CAGAqY005330 for ; Fri, 12 Mar 2004 11:16:10 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 12 Mar 2004 11:16:09 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYF0V6N3; Fri, 12 Mar 2004 11:16:08 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2CAG8XA017846; Fri, 12 Mar 2004 11:16:08 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2CAFvIt012065; Fri, 12 Mar 2004 11:15:57 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2CAFvMp012064; Fri, 12 Mar 2004 11:15:57 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2CAFuIt012060 for ; Fri, 12 Mar 2004 11:15:56 +0100 (MET) Received: from [IPv6:::1] (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 33D028; Fri, 12 Mar 2004 12:28:36 +0200 (EET) In-Reply-To: <015d01c40792$21f7e3d0$366115ac@dcml.docomolabsusa.com> References: <015d01c40792$21f7e3d0$366115ac@dcml.docomolabsusa.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4060F104-740E-11D8-A780-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: Jonathan Wood From: Pekka Nikander Subject: Re: Resolving Remaining Issues on draft-ietf-send-ndopt-04.txt Date: Fri, 12 Mar 2004 12:15:56 +0200 To: SEND WG X-Mailer: Apple Mail (2.612) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 12 Mar 2004 10:16:09.0055 (UTC) FILETIME=[098C5EF0:01C4081B] Content-Transfer-Encoding: 7bit > http://users.piuha.net/jarkko/publications/send/issues/issue68.txt > > Issue 68: Explicit padding length field v.s. implicit padding length > as a > result of message and field length. > > Suggested resolution: The draft currently has an explicit padding > length, so > remain with that. If we had a comment from an implementor (Jon?), that would be great. I'm willing to go either way, and this seems mostly like an issue of which way is easier to implement. > Issue 67: Possible implementation variability when nonce omitted from > RA. > > Suggested resolution: Add following text to paragraph 2, Section > 5.3.3, to > guide implementation: > > "Omitting the nonce value may, however, cause > the host to ignore the router's advertisement, unless the clocks in > these nodes are sufficiently synchronized so that timestamps can be > relied on." Ok to me. --Pekka -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Fri Mar 12 13:43:54 2004 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10090 for ; Fri, 12 Mar 2004 13:43:53 -0500 (EST) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2CIhrYG028656 for ; Fri, 12 Mar 2004 19:43:53 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 12 Mar 2004 19:43:52 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYF0ZHST; Fri, 12 Mar 2004 19:43:51 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2CIhoXA027531; Fri, 12 Mar 2004 19:43:50 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2CIh2It000906; Fri, 12 Mar 2004 19:43:02 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2CIh2QY000905; Fri, 12 Mar 2004 19:43:02 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2CIh0It000858 for ; Fri, 12 Mar 2004 19:43:00 +0100 (MET) Received: (qmail 11115 invoked from network); 12 Mar 2004 18:42:58 -0000 Received: from dsl093-135-225.sfo4.dsl.speakeasy.net (HELO [192.168.0.3]) ([66.93.135.225]) (envelope-sender ) by mail2.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 12 Mar 2004 18:42:58 -0000 In-Reply-To: <4060F104-740E-11D8-A780-000393CE1E8C@nomadiclab.com> References: <015d01c40792$21f7e3d0$366115ac@dcml.docomolabsusa.com> <4060F104-740E-11D8-A780-000393CE1E8C@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <14F6B8A3-7455-11D8-B009-0003930D291E@speakeasy.net> Content-Transfer-Encoding: 7bit Cc: SEND WG From: Jonathan Wood Subject: Re: Resolving Remaining Issues on draft-ietf-send-ndopt-04.txt Date: Fri, 12 Mar 2004 10:42:58 -0800 To: Pekka Nikander X-Mailer: Apple Mail (2.612) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 12 Mar 2004 18:43:52.0180 (UTC) FILETIME=[F6FC5B40:01C40861] Content-Transfer-Encoding: 7bit On Mar 12, 2004, at 2:15 AM, Pekka Nikander wrote: >> http://users.piuha.net/jarkko/publications/send/issues/issue68.txt >> >> Issue 68: Explicit padding length field v.s. implicit padding length >> as a >> result of message and field length. >> >> Suggested resolution: The draft currently has an explicit padding >> length, so >> remain with that. > > If we had a comment from an implementor (Jon?), that would be great. > I'm willing to go either way, and this seems mostly like an issue > of which way is easier to implement. > I found that I never used explicit pad lengths (and since I implemented draft-arkko-send-ndopt-00 only the certificate option had a pad length). ASN.1 encoded data proved easy enough to parse with just the length information in the encoding. The signature length was a bit trickier - OpenSSL has a function that provides the signature length based on the key. However, if this function cannot be applied to all key types, then perhaps the pad length (or an explicit signature length) field might be needed. A crypto expert can address this better than I. When the trust anchor name type is 1 (DER Encoded X.501 Name), the length is in the DER encoding. However, this is not true for FQDNs. Processing FQDNs without an explicit pad or length field is harder, since if the name does not end on an 8 byte boundary, the receiver will need to walk though the padding to find the end of the name. This would also be an (unusual) instance of requiring a receiver to interpret pad values (since it would need to find a non-zero value to infer the boundary between the end of the name and the start of the padding). Perhaps it would be better to go back to an explicit name length for this option... Jon -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Mon Mar 15 04:46:11 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17667 for ; Mon, 15 Mar 2004 04:46:10 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2F9kBqY027579 for ; Mon, 15 Mar 2004 10:46:11 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 15 Mar 2004 10:46:10 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GX1HCFS9; Mon, 15 Mar 2004 10:46:10 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2F9k0wg028074; Mon, 15 Mar 2004 10:46:00 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2F9inIt014271; Mon, 15 Mar 2004 10:44:49 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2F9invM014270; Mon, 15 Mar 2004 10:44:49 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2F9ilIt014266 for ; Mon, 15 Mar 2004 10:44:48 +0100 (MET) Received: from [IPv6:::1] (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id E79018; Mon, 15 Mar 2004 11:57:26 +0200 (EET) In-Reply-To: <14F6B8A3-7455-11D8-B009-0003930D291E@speakeasy.net> References: <015d01c40792$21f7e3d0$366115ac@dcml.docomolabsusa.com> <4060F104-740E-11D8-A780-000393CE1E8C@nomadiclab.com> <14F6B8A3-7455-11D8-B009-0003930D291E@speakeasy.net> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6776A5EB-7665-11D8-9995-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: SEND WG From: Pekka Nikander Subject: Re: Resolving Remaining Issues on draft-ietf-send-ndopt-04.txt Date: Mon, 15 Mar 2004 11:44:50 +0200 To: Jonathan Wood X-Mailer: Apple Mail (2.612) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 15 Mar 2004 09:46:10.0243 (UTC) FILETIME=[589CB130:01C40A72] Content-Transfer-Encoding: 7bit Jon, >>> http://users.piuha.net/jarkko/publications/send/issues/issue68.txt >>> >>> Issue 68: Explicit padding length field v.s. implicit padding length >>> as a >>> result of message and field length. >>> >>> Suggested resolution: The draft currently has an explicit padding >>> length, so >>> remain with that. >>> > ASN.1 encoded data proved easy enough to parse with just the > length information in the encoding.... > > ... Perhaps it would be better to go back to an explicit name length > for [FQDN names]... Do I read this correctly if I assume that you prefer the current explicit padding length? That is, even though it is not strictly needed for DER encoded ANS.1, you see other cases where it would be useful? --Pekka -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Mon Mar 15 13:14:22 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14290 for ; Mon, 15 Mar 2004 13:14:20 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2FIEHqY029247 for ; Mon, 15 Mar 2004 19:14:18 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 15 Mar 2004 19:14:17 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id G4AZQY4Y; Mon, 15 Mar 2004 19:15:44 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2FIEFXA012804; Mon, 15 Mar 2004 19:14:15 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2FIDNIt005478; Mon, 15 Mar 2004 19:13:23 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2FIDNCg005477; Mon, 15 Mar 2004 19:13:23 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2FIDKIt005458 for ; Mon, 15 Mar 2004 19:13:21 +0100 (MET) Received: (qmail 21631 invoked from network); 15 Mar 2004 18:13:19 -0000 Received: from dsl093-135-225.sfo4.dsl.speakeasy.net (HELO [192.168.0.3]) ([66.93.135.225]) (envelope-sender ) by mail3.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 15 Mar 2004 18:13:19 -0000 In-Reply-To: <6776A5EB-7665-11D8-9995-000393CE1E8C@nomadiclab.com> References: <015d01c40792$21f7e3d0$366115ac@dcml.docomolabsusa.com> <4060F104-740E-11D8-A780-000393CE1E8C@nomadiclab.com> <14F6B8A3-7455-11D8-B009-0003930D291E@speakeasy.net> <6776A5EB-7665-11D8-9995-000393CE1E8C@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6F691CA5-76AC-11D8-BC1B-0003930D291E@speakeasy.net> Content-Transfer-Encoding: 7bit Cc: SEND WG From: Jonathan Wood Subject: Re: Resolving Remaining Issues on draft-ietf-send-ndopt-04.txt Date: Mon, 15 Mar 2004 10:13:18 -0800 To: Pekka Nikander X-Mailer: Apple Mail (2.612) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 15 Mar 2004 18:14:17.0057 (UTC) FILETIME=[542B5510:01C40AB9] Content-Transfer-Encoding: 7bit On Mar 15, 2004, at 1:44 AM, Pekka Nikander wrote: > Jon, > >>>> http://users.piuha.net/jarkko/publications/send/issues/issue68.txt >>>> >>>> Issue 68: Explicit padding length field v.s. implicit padding >>>> length as a >>>> result of message and field length. >>>> >>>> Suggested resolution: The draft currently has an explicit padding >>>> length, so >>>> remain with that. >>>> >> ASN.1 encoded data proved easy enough to parse with just the >> length information in the encoding.... >> >> ... Perhaps it would be better to go back to an explicit name length >> for [FQDN names]... > > Do I read this correctly if I assume that you prefer the current > explicit padding length? That is, even though it is not strictly > needed for DER encoded ANS.1, you see other cases where it would > be useful? > I think it's necessary only in one case - trust anchor options, for FQDNs. Elsewhere is seems to be useless mechanism. Would is be reasonable to just include a length for trust anchor options? Jon -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Mon Mar 15 14:07:17 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16600 for ; Mon, 15 Mar 2004 14:07:16 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2FJ7GqY005258 for ; Mon, 15 Mar 2004 20:07:16 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 15 Mar 2004 20:07:16 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYFVLHNG; Mon, 15 Mar 2004 20:08:24 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2FJ7FXA013438; Mon, 15 Mar 2004 20:07:15 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2FJ6jIt017161; Mon, 15 Mar 2004 20:06:45 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2FJ6jHt017160; Mon, 15 Mar 2004 20:06:45 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2FJ6hIt017155 for ; Mon, 15 Mar 2004 20:06:44 +0100 (MET) Message-ID: <006c01c40ac0$b3500160$5b6115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Jonathan Wood" , "Pekka Nikander" Cc: "SEND WG" References: <015d01c40792$21f7e3d0$366115ac@dcml.docomolabsusa.com> <4060F104-740E-11D8-A780-000393CE1E8C@nomadiclab.com> <14F6B8A3-7455-11D8-B009-0003930D291E@speakeasy.net> <6776A5EB-7665-11D8-9995-000393CE1E8C@nomadiclab.com> <6F691CA5-76AC-11D8-BC1B-0003930D291E@speakeasy.net> Subject: Re: Resolving Remaining Issues on draft-ietf-send-ndopt-04.txt Date: Mon, 15 Mar 2004 11:07:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 15 Mar 2004 19:07:16.0240 (UTC) FILETIME=[BB1C2900:01C40AC0] Content-Transfer-Encoding: 7bit So based on Jon's input, I'd like to propose the following specific revisions to the current draft text to resolve Issue 68: Section 5.2: Remove Pad Length field from message diagram, make Reserved. Remove Pad Length description in following text. Section 6.2.4: Remove Pad Length field from message diagram, make part of Reserved field. Remove Pad Length description in following text. Comments? jak ----- Original Message ----- From: "Jonathan Wood" To: "Pekka Nikander" Cc: "SEND WG" Sent: Monday, March 15, 2004 10:13 AM Subject: Re: Resolving Remaining Issues on draft-ietf-send-ndopt-04.txt > > On Mar 15, 2004, at 1:44 AM, Pekka Nikander wrote: > > > Jon, > > > >>>> http://users.piuha.net/jarkko/publications/send/issues/issue68.txt > >>>> > >>>> Issue 68: Explicit padding length field v.s. implicit padding > >>>> length as a > >>>> result of message and field length. > >>>> > >>>> Suggested resolution: The draft currently has an explicit padding > >>>> length, so > >>>> remain with that. > >>>> > >> ASN.1 encoded data proved easy enough to parse with just the > >> length information in the encoding.... > >> > >> ... Perhaps it would be better to go back to an explicit name length > >> for [FQDN names]... > > > > Do I read this correctly if I assume that you prefer the current > > explicit padding length? That is, even though it is not strictly > > needed for DER encoded ANS.1, you see other cases where it would > > be useful? > > > > I think it's necessary only in one case - trust anchor options, for > FQDNs. > Elsewhere is seems to be useless mechanism. Would is be reasonable > to just include a length for trust anchor options? > > Jon > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Wed Mar 17 08:12:14 2004 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04877 for ; Wed, 17 Mar 2004 08:12:12 -0500 (EST) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2HDCBYG024440 for ; Wed, 17 Mar 2004 14:12:11 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 17 Mar 2004 14:12:10 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id G4A5B3YM; Wed, 17 Mar 2004 14:13:44 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2HDBuwg019208; Wed, 17 Mar 2004 14:11:56 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2HDAhIt019479; Wed, 17 Mar 2004 14:10:43 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2HDAhAT019478; Wed, 17 Mar 2004 14:10:43 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2HDAfIt019462 for ; Wed, 17 Mar 2004 14:10:41 +0100 (MET) Received: from [IPv6:::1] (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 8EB468; Wed, 17 Mar 2004 15:23:14 +0200 (EET) In-Reply-To: <006c01c40ac0$b3500160$5b6115ac@dcml.docomolabsusa.com> References: <015d01c40792$21f7e3d0$366115ac@dcml.docomolabsusa.com> <4060F104-740E-11D8-A780-000393CE1E8C@nomadiclab.com> <14F6B8A3-7455-11D8-B009-0003930D291E@speakeasy.net> <6776A5EB-7665-11D8-9995-000393CE1E8C@nomadiclab.com> <6F691CA5-76AC-11D8-BC1B-0003930D291E@speakeasy.net> <006c01c40ac0$b3500160$5b6115ac@dcml.docomolabsusa.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7AAC9E17-7814-11D8-8E54-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: "Jonathan Wood" , "SEND WG" From: Pekka Nikander Subject: Re: Resolving Remaining Issues on draft-ietf-send-ndopt-04.txt Date: Wed, 17 Mar 2004 15:10:36 +0200 To: "James Kempf" X-Mailer: Apple Mail (2.612) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 17 Mar 2004 13:12:10.0393 (UTC) FILETIME=[74A96890:01C40C21] Content-Transfer-Encoding: 7bit > So based on Jon's input, I'd like to propose the following specific > revisions to the current draft text to resolve Issue 68: > > Section 5.2: > > Remove Pad Length field from message diagram, make Reserved. > > Remove Pad Length description in following text. > > Section 6.2.4: > > Remove Pad Length field from message diagram, make part of Reserved > field. > > Remove Pad Length description in following text. > > Comments? Ok to me. How about the explicit length for FQDN? Does it require any changes? (Don't have time to check the draft now, sorry about that.) --Pekka -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Wed Mar 17 10:46:46 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13243 for ; Wed, 17 Mar 2004 10:46:46 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2HFklAh016062 for ; Wed, 17 Mar 2004 16:46:47 +0100 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 17 Mar 2004 16:46:47 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GX1HZGJS; Wed, 17 Mar 2004 16:46:46 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2HFkawg000020; Wed, 17 Mar 2004 16:46:36 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2HFjpIt022539; Wed, 17 Mar 2004 16:45:51 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2HFjpaQ022538; Wed, 17 Mar 2004 16:45:51 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2HFjoIt022534 for ; Wed, 17 Mar 2004 16:45:50 +0100 (MET) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2HFjow11275; Wed, 17 Mar 2004 17:45:50 +0200 Date: Wed, 17 Mar 2004 17:45:50 +0200 (EET) From: Pekka Savola To: ietf-send@standards.ericsson.net cc: Erik Nordmark Subject: SEND "triggers": passive vs active use? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 17 Mar 2004 15:46:47.0105 (UTC) FILETIME=[0E035310:01C40C37] Hi, During discussion of ND-proxy applicability w/ send at v6ops, an open issue in SEND came up: what is the deployment model of SEND? Is it practical? That is, I think we'd like the vendors to turn on SEND by default if they implement it, right? But at the same time, it might take quite long before SEND is widely enough deployed that actively using it would make sense. I don't quite remember how it is in the document, but it struck me that one possibility (if an "active model" would not be deemed useful) would be to have a "trigger" of a kind. SEND would be active, but not used -- until some activity triggers it. Such trigger could be e.g., receiving a SEND-enabled router advertisement, or CGA-signed Neighbor Discovery packet. The idea here would be to make sure SEND is enabled and out there, in "passive" mode -- preserving resources and hassle until it's actually needed. These are quite raw thoughts for now, but perhaps this might trigger some discussion on the transition to SEND. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Wed Mar 17 12:23:25 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23344 for ; Wed, 17 Mar 2004 12:23:25 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2HHNQAh001670 for ; Wed, 17 Mar 2004 18:23:27 +0100 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 17 Mar 2004 18:23:26 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYFV965P; Wed, 17 Mar 2004 18:24:40 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2HHNPXA000080; Wed, 17 Mar 2004 18:23:25 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2HHMiIt012875; Wed, 17 Mar 2004 18:22:44 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2HHMiqQ012874; Wed, 17 Mar 2004 18:22:44 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2HHMgIt012870 for ; Wed, 17 Mar 2004 18:22:43 +0100 (MET) Message-ID: <012d01c40c44$88038ce0$366115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Pekka Nikander" Cc: "Jonathan Wood" , "SEND WG" References: <015d01c40792$21f7e3d0$366115ac@dcml.docomolabsusa.com> <4060F104-740E-11D8-A780-000393CE1E8C@nomadiclab.com> <14F6B8A3-7455-11D8-B009-0003930D291E@speakeasy.net> <6776A5EB-7665-11D8-9995-000393CE1E8C@nomadiclab.com> <6F691CA5-76AC-11D8-BC1B-0003930D291E@speakeasy.net> <006c01c40ac0$b3500160$5b6115ac@dcml.docomolabsusa.com> <7AAC9E17-7814-11D8-8E54-000393CE1E8C@nomadiclab.com> Subject: Re: Resolving Remaining Issues on draft-ietf-send-ndopt-04.txt Date: Wed, 17 Mar 2004 09:23:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 17 Mar 2004 17:23:26.0856 (UTC) FILETIME=[8EEF1880:01C40C44] Content-Transfer-Encoding: 7bit John's recommendation if I understand correctly was to keep the pad length for the trust anchor option. Between the pad length, total option length, and fixed field sizes it should be possible to calculate the FQDN size. jak ----- Original Message ----- From: "Pekka Nikander" To: "James Kempf" Cc: "Jonathan Wood" ; "SEND WG" Sent: Wednesday, March 17, 2004 5:10 AM Subject: Re: Resolving Remaining Issues on draft-ietf-send-ndopt-04.txt > > So based on Jon's input, I'd like to propose the following specific > > revisions to the current draft text to resolve Issue 68: > > > > Section 5.2: > > > > Remove Pad Length field from message diagram, make Reserved. > > > > Remove Pad Length description in following text. > > > > Section 6.2.4: > > > > Remove Pad Length field from message diagram, make part of Reserved > > field. > > > > Remove Pad Length description in following text. > > > > Comments? > > Ok to me. How about the explicit length for FQDN? Does it > require any changes? (Don't have time to check the draft now, > sorry about that.) > > --Pekka > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Wed Mar 17 12:34:25 2004 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24311 for ; Wed, 17 Mar 2004 12:34:25 -0500 (EST) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2HHYPYG023686 for ; Wed, 17 Mar 2004 18:34:27 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 17 Mar 2004 18:34:24 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYGBANA4; Wed, 17 Mar 2004 18:34:24 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2HHYNXA000305; Wed, 17 Mar 2004 18:34:23 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2HHXvIt015472; Wed, 17 Mar 2004 18:33:57 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2HHXv3f015471; Wed, 17 Mar 2004 18:33:57 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2HHXtIt015467 for ; Wed, 17 Mar 2004 18:33:56 +0100 (MET) Message-ID: <019901c40c46$1966fb80$366115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Pekka Savola" , Cc: "Erik Nordmark" References: Subject: Re: SEND "triggers": passive vs active use? Date: Wed, 17 Mar 2004 09:34:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 17 Mar 2004 17:34:24.0676 (UTC) FILETIME=[17067640:01C40C46] Content-Transfer-Encoding: 7bit Pekka, For hosts, I think it should be possible to have SEND be on by default, since it has been designed to be completely backward compatible. Section 8 of draft-ietf-send-ndopt-04.txt describes that. For routers, it's a bit more complicated since the router must be configured with a certificate. This requires the network provider to take some action to actually enable SEND for router authentication. This also requires the host to have a suitable certificate for the common trust anchor. Many operating system platforms now have certificate management systems that contain a collection of certificates for various CAs used in SSL, so these can be leveraged without requiring any host configuration, but a certificate closer to the network provider's CA that would require configuration can reduce the size of the certificate exchange and is obviously preferable. Not sure if this answers your question? jak ----- Original Message ----- From: "Pekka Savola" To: Cc: "Erik Nordmark" Sent: Wednesday, March 17, 2004 7:45 AM Subject: SEND "triggers": passive vs active use? > Hi, > > During discussion of ND-proxy applicability w/ send at v6ops, an open > issue in SEND came up: what is the deployment model of SEND? Is it > practical? > > That is, I think we'd like the vendors to turn on SEND by default if > they implement it, right? But at the same time, it might take quite > long before SEND is widely enough deployed that actively using it > would make sense. > > I don't quite remember how it is in the document, but it struck me > that one possibility (if an "active model" would not be deemed useful) > would be to have a "trigger" of a kind. SEND would be active, but not > used -- until some activity triggers it. Such trigger could be e.g., > receiving a SEND-enabled router advertisement, or CGA-signed Neighbor > Discovery packet. > > The idea here would be to make sure SEND is enabled and out there, > in "passive" mode -- preserving resources and hassle until it's > actually needed. > > These are quite raw thoughts for now, but perhaps this might trigger > some discussion on the transition to SEND. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Thu Mar 18 00:22:06 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03214 for ; Thu, 18 Mar 2004 00:22:05 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2I5M7Ah009947 for ; Thu, 18 Mar 2004 06:22:07 +0100 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Mar 2004 06:22:07 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYFWD1CS; Thu, 18 Mar 2004 06:23:22 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2I5M3wg028152; Thu, 18 Mar 2004 06:22:03 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2I5LJIt028893; Thu, 18 Mar 2004 06:21:19 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2I5LJYx028892; Thu, 18 Mar 2004 06:21:19 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2I5LFIt028884 for ; Thu, 18 Mar 2004 06:21:16 +0100 (MET) Received: from localhost ([130.194.13.83]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L7VBCRSY1K8X3XV8@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Thu, 18 Mar 2004 10:37:39 +1100 Received: from splat.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id A33A623C003; Thu, 18 Mar 2004 10:37:36 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by splat.its.monash.edu.au (Postfix) with ESMTP id 8AC22164010; Thu, 18 Mar 2004 10:37:36 +1100 (EST) Date: Thu, 18 Mar 2004 10:37:36 +1100 From: Greg Daley Subject: Re: SEND "triggers": passive vs active use? To: Pekka Savola Cc: ietf-send@standards.ericsson.net, Erik Nordmark Reply-to: greg.daley@eng.monash.edu.au Message-id: <4058E140.4000905@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 18 Mar 2004 05:22:07.0335 (UTC) FILETIME=[F4BE0770:01C40CA8] Content-Transfer-Encoding: 7BIT Hi Pekka, Pekka Savola wrote: > Hi, > > During discussion of ND-proxy applicability w/ send at v6ops, an open > issue in SEND came up: what is the deployment model of SEND? Is it > practical? > > That is, I think we'd like the vendors to turn on SEND by default if > they implement it, right? But at the same time, it might take quite > long before SEND is widely enough deployed that actively using it > would make sense. > > I don't quite remember how it is in the document, but it struck me > that one possibility (if an "active model" would not be deemed useful) > would be to have a "trigger" of a kind. SEND would be active, but not > used -- until some activity triggers it. Such trigger could be e.g., > receiving a SEND-enabled router advertisement, or CGA-signed Neighbor > Discovery packet. > > The idea here would be to make sure SEND is enabled and out there, > in "passive" mode -- preserving resources and hassle until it's > actually needed. > > These are quite raw thoughts for now, but perhaps this might trigger > some discussion on the transition to SEND. As a deployment issue, you're right: there won't be many devices using SEND initially, so there may be a requirement to fall back to ND in the case that no-one is doing SEND. We'll need to be careful that decisions about this don't leave hosts with a mechanism where other devices can cause them to turn off SEND though. I'd guess that when operating within a particular network, it is fairly straightforward: Once you receive an authorized RA with a SEND signature in it, SEND should be run on the host. I'd guess that hosts may wish to use SENDC before then though, for the purpose of mutual authentication with other SEND devices on the link. Also, it may not make sense to delay generation or utilization of CGAs until SEND authorization occurs (especially for link-local). There are also devices which will be moving around between different IP links/subnets, though. These won't have a choice as to whether SEND is turned on for a particular router or subnet. In the case that SEND is on for one router, it doesn't imply that SEND should be used on nearby subnets. We may see a situation where a host has had SEND operation on one subnet, and ignores router advertisements on a new subnet because of that. Checking reachability to the current SEND router may be one mechanism which is useful to ensure that we are still connected to a subnet (so unsecured ND messages can't override SEND messages), but when the host has moved, or the SEND router has died, this may take a long time with existing NUD/SEND Timestamp techniques. So it may also be necessary to "trigger (?)" switching SEND off in some cases. These devices may know about their wireless connectivity (for example upper later (secured?) packet reception halts, Link layer information suggests change...), and would have to reset the ND state, including potentially security. -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Thu Mar 18 05:57:52 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02727 for ; Thu, 18 Mar 2004 05:57:52 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2IAvrqY029709 for ; Thu, 18 Mar 2004 11:57:53 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Mar 2004 11:57:53 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYFWGVHB; Thu, 18 Mar 2004 11:59:02 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2IAvQXA002161; Thu, 18 Mar 2004 11:57:27 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2IAkeIt010286; Thu, 18 Mar 2004 11:46:40 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2IAke8e010277; Thu, 18 Mar 2004 11:46:40 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep20-app.kolumbus.fi (fep20-0.kolumbus.fi [193.229.0.47]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2IAkTIt010211 for ; Thu, 18 Mar 2004 11:46:35 +0100 (MET) Received: from mta.imail.kolumbus.fi ([193.229.5.109]) by fep20-app.kolumbus.fi with ESMTP id <20040318104609.KPZF15980.fep20-app.kolumbus.fi@mta.imail.kolumbus.fi>; Thu, 18 Mar 2004 12:46:09 +0200 X-Mailer: Openwave WebEngine, version 2.8.10 (webedge20-101-191-20030113) From: To: CC: Subject: Re: SEND "triggers": passive vs. active use Date: Thu, 18 Mar 2004 12:46:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20040318104609.KPZF15980.fep20-app.kolumbus.fi@mta.imail.kolumbus.fi> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 18 Mar 2004 10:57:53.0554 (UTC) FILETIME=[DCD31720:01C40CD7] Content-Transfer-Encoding: 7bit Pekka, This is an important issue to discuss, but I believe solutions go beyond simple triggers. Most importantly, SEND already has a built-in backwards compatibility mechanism specifically designed to address at least parts of the issue. Going a bit deeper to the details, I believe the situation is as follows: - Hosts can generally follow the current SEND specification as soon as they have support for it; they will still work in non-SEND environments, and generating addresses via CGA or via EUI-64 IIDs should not have a significant difference to others. - There's two exceptions, however, and the first one is stateful address autoconfig. Currently we do not have a specification for SEND protection of addresses assigned by someone else. So for such addresses, the hosts should continue to use regular ND (even if they use SEND otherwise). I believe our specifications say this too, though I should check to see how clearly it has been said. - The other exception is that to protect the RAs, there is a need to configure a trust root that the hosts can trust. This looks like another "use it when you have it" case. That is, when you don't have a trust root you'll just be using the non-SEND routers or SEND routers with a different root. I may have to check that this is clearly described in Section 8, but this has at least been the intent. - For routers, I think the answer is similar: if you haven't been configured to use SEND yet and have the certs for it, you pretty much cannot do SEND. No big deal, hosts survive even in this case. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Thu Mar 18 09:55:06 2004 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15281 for ; Thu, 18 Mar 2004 09:55:05 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2IEt6YG000154 for ; Thu, 18 Mar 2004 15:55:06 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Mar 2004 15:55:05 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GX1214VL; Thu, 18 Mar 2004 15:55:05 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2IEsuwg013935; Thu, 18 Mar 2004 15:54:56 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2IEs2It003226; Thu, 18 Mar 2004 15:54:02 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2IEs2YB003222; Thu, 18 Mar 2004 15:54:02 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2IEs0It003191 for ; Thu, 18 Mar 2004 15:54:00 +0100 (MET) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2IErxU00387; Thu, 18 Mar 2004 16:54:00 +0200 Date: Thu, 18 Mar 2004 16:53:59 +0200 (EET) From: Pekka Savola To: jari.arkko@kolumbus.fi cc: ietf-send@standards.ericsson.net Subject: Re: SEND "triggers": passive vs. active use In-Reply-To: <20040318104609.KPZF15980.fep20-app.kolumbus.fi@mta.imail.kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 18 Mar 2004 14:55:05.0755 (UTC) FILETIME=[FFE09EB0:01C40CF8] Thanks for replies, all; I'll just respond to one message to reduce list traffic. On Thu, 18 Mar 2004 jari.arkko@kolumbus.fi wrote: > This is an important issue to discuss, but I believe > solutions go beyond simple triggers. Most importantly, > SEND already has a built-in backwards compatibility > mechanism specifically designed to address at least > parts of the issue. Agreed. > Going a bit deeper to the details, I believe the > situation is as follows: > > - Hosts can generally follow the current > SEND specification as soon as they have support > for it; they will still work in non-SEND environments, > and generating addresses via CGA or via EUI-64 IIDs > should not have a significant difference to others. Yes. The critical question, which I was really grasping at, was whether there could be any drawbacks for enabling SEND support immediately. The obvious one is at least the computational overhead but that is probably acceptable. Are there others? One particular issue that triggered this discussion at v6ops was the proposal to use ND-proxy in the unmanaged ("home") environment if the ISP would not give other than just a /64 prefix. This raises a number of questions like: - is SEND applicable in this scope (might be, if the home has non-bridged WLAN router, but the ISP is unlikely to support SEND routing certificates in any case)? - would this break SEND so badly that that might lead to disabling SEND in the OS's deployed at home? We would not want SEND turned off by default (I think) The point here would be either: a) making sure that enabling SEND by default has no problems, and could be done by the supporting implementations, or b) ensuring that sufficient "triggers" or other transition mechanisms are in place so that even if SEND is not active by default, it would at least be "dormant" for the case when it would be needed. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Thu Mar 18 12:02:43 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25240 for ; Thu, 18 Mar 2004 12:02:42 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2IH2iAh013350 for ; Thu, 18 Mar 2004 18:02:44 +0100 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Mar 2004 18:02:44 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HF6JWN8L; Thu, 18 Mar 2004 18:02:44 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2IH2hXA011729; Thu, 18 Mar 2004 18:02:43 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2IH1oIt001266; Thu, 18 Mar 2004 18:01:50 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2IH1nlf001265; Thu, 18 Mar 2004 18:01:49 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2IH1kIt001245 for ; Thu, 18 Mar 2004 18:01:48 +0100 (MET) Message-ID: <01de01c40d0a$bf75f7f0$366115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , "Pekka Savola" Cc: , "Erik Nordmark" References: <4058E140.4000905@eng.monash.edu.au> Subject: Re: SEND "triggers": passive vs active use? Date: Thu, 18 Mar 2004 09:02:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 18 Mar 2004 17:02:44.0236 (UTC) FILETIME=[D4B014C0:01C40D0A] Content-Transfer-Encoding: 7bit Greg, Please read Section 8 of draft-ietf-send-ndopt-04.txt and let the WG know if you see anything there that would require SEND to be turned or "triggered" off on a network where the router or any of the other nodes do not support SEND. The intent of the design is that SEND nodes should "just work" with standard RFC 2461 nodes (including routers). jak ----- Original Message ----- From: "Greg Daley" To: "Pekka Savola" Cc: ; "Erik Nordmark" Sent: Wednesday, March 17, 2004 3:37 PM Subject: Re: SEND "triggers": passive vs active use? > Hi Pekka, > > Pekka Savola wrote: > > Hi, > > > > During discussion of ND-proxy applicability w/ send at v6ops, an open > > issue in SEND came up: what is the deployment model of SEND? Is it > > practical? > > > > That is, I think we'd like the vendors to turn on SEND by default if > > they implement it, right? But at the same time, it might take quite > > long before SEND is widely enough deployed that actively using it > > would make sense. > > > > I don't quite remember how it is in the document, but it struck me > > that one possibility (if an "active model" would not be deemed useful) > > would be to have a "trigger" of a kind. SEND would be active, but not > > used -- until some activity triggers it. Such trigger could be e.g., > > receiving a SEND-enabled router advertisement, or CGA-signed Neighbor > > Discovery packet. > > > > The idea here would be to make sure SEND is enabled and out there, > > in "passive" mode -- preserving resources and hassle until it's > > actually needed. > > > > These are quite raw thoughts for now, but perhaps this might trigger > > some discussion on the transition to SEND. > > As a deployment issue, you're right: there won't be many devices > using SEND initially, so there may be a requirement to fall back to > ND in the case that no-one is doing SEND. We'll need to be careful > that decisions about this don't leave hosts with a mechanism where > other devices can cause them to turn off SEND though. > > I'd guess that when operating within a particular network, it is > fairly straightforward: Once you receive an authorized RA with a > SEND signature in it, SEND should be run on the host. > > I'd guess that hosts may wish to use SENDC before then > though, for the purpose of mutual authentication with other SEND > devices on the link. > > Also, it may not make sense to delay generation or utilization of > CGAs until SEND authorization occurs (especially for link-local). > > There are also devices which will be moving around between different > IP links/subnets, though. These won't have a choice as to whether > SEND is turned on for a particular router or subnet. > > In the case that SEND is on for one router, it doesn't imply that SEND > should be used on nearby subnets. We may see a situation where > a host has had SEND operation on one subnet, and ignores > router advertisements on a new subnet because of that. > > Checking reachability to the current SEND router may be one mechanism > which is useful to ensure that we are still connected to a subnet > (so unsecured ND messages can't override SEND messages), but when > the host has moved, or the SEND router has died, this may take a long > time with existing NUD/SEND Timestamp techniques. > > So it may also be necessary to "trigger (?)" switching SEND off in > some cases. These devices may know about their wireless connectivity > (for example upper later (secured?) packet reception halts, Link layer > information suggests change...), and would have to reset the ND state, > including potentially security. > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Thu Mar 18 12:46:30 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26714 for ; Thu, 18 Mar 2004 12:46:29 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2IHkVAh018798 for ; Thu, 18 Mar 2004 18:46:31 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Mar 2004 18:46:31 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id G4A5PX82; Thu, 18 Mar 2004 18:48:10 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2IHkHwg023569; Thu, 18 Mar 2004 18:46:17 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2IHjbIt010517; Thu, 18 Mar 2004 18:45:37 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2IHjbJF010516; Thu, 18 Mar 2004 18:45:37 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2IHjZIt010493 for ; Thu, 18 Mar 2004 18:45:36 +0100 (MET) Message-ID: <01e301c40d10$e4772d70$366115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Pekka Savola" , Cc: References: Subject: Re: SEND "triggers": passive vs. active use Date: Thu, 18 Mar 2004 09:46:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 18 Mar 2004 17:46:31.0441 (UTC) FILETIME=[F29FC010:01C40D10] Content-Transfer-Encoding: 7bit Pekka, Thanx for bringing up this point. > The critical question, which I was really grasping at, was whether > there could be any drawbacks for enabling SEND support immediately. > The obvious one is at least the computational overhead but that is > probably acceptable. Are there others? > The WG tried hard in the compatibility design to make it possible for SEND and nonSEND nodes to work together on a link without any need for additional configuration on either the nodes or the network, or triggers to require SEND to be turned off. If you or anyone else sees anything that the WG missed please by all means let the WG know soon, since the draft is about to go to the IESG. W.r.t. computational overhead, there is more overhead initially when calculating a CGA address, but the additional per ND operation overhead if the link has no certified router or other SEND nodes should be really minimal, since it should be just RFC 2461 ND with a couple of checks for additional options. > One particular issue that triggered this discussion at v6ops was the > proposal to use ND-proxy in the unmanaged ("home") environment if the > ISP would not give other than just a /64 prefix. This raises a number > of questions like: > > - is SEND applicable in this scope (might be, if the home has > non-bridged WLAN router, but the ISP is unlikely to support SEND > routing certificates in any case)? > If the ISP only gives a /64 prefix, then the ISP's router would need to provide a certificate for router discovery security. But the nodes could use CGA for ND security among themselves, which would not require any action on the part of the ISP. Not sure what your point is about a non-bridged WLAN router. > - would this break SEND so badly that that might lead to disabling > SEND in the OS's deployed at home? We would not want SEND turned > off by default (I think) > Ignoring the issue of ND-proxy for the moment - that is, assuming the home nodes are communicating directly to/from the Internet via the ISP's router - the design is intended to have SEND nodes interoperate with nonSEND nodes, including the router, without any hinderance. > The point here would be either: > > a) making sure that enabling SEND by default has no problems, and > could be done by the supporting implementations, or > This was the intent of Section 8 in draft-ietf-send-ndopt-04.txt. Of course, the real test of whether the design's intent is met is when we hold some interoperability tests and try it out. :-) > b) ensuring that sufficient "triggers" or other transition mechanisms > are in place so that even if SEND is not active by default, it > would at least be "dormant" for the case when it would be needed. > Again, the design is intended to have interoperation work without any triggers or other transition mechanisms. W.r.t. ND-proxy, as brought up in the thread on the IPv6 list during IETF 59, the difficulty is that the current ND-proxy draft in the IPv6 WG assumes the proxy is basically an L2 device, so there is really no way for a "proxy" SEND, should one be designed, to be used, since there is no L3 entity on which to anchor it. A L2 ND-proxy could, of course, strip SEND ND options off of RAs, in which case the RAs would be accepted by the SEND nodes as if they had been sent by a nonSEND router. In any case, the L2 proxy shouldn't affect SEND for nodes performing ND address resolution on the same side of the proxy, and packets to nodes with L2 addresses on the other side of the proxy would have to go through the router anyway because their L2 addresses would not be visible through the proxy, though SEND could presumably be used on packets sent for DAD. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Thu Mar 18 14:35:38 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02741 for ; Thu, 18 Mar 2004 14:35:36 -0500 (EST) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2IJZVAh028952 for ; Thu, 18 Mar 2004 20:35:35 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Mar 2004 20:35:31 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id G4A5QK8B; Thu, 18 Mar 2004 20:37:10 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2IJZLwg028882; Thu, 18 Mar 2004 20:35:21 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2IJYbIt004365; Thu, 18 Mar 2004 20:34:37 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2IJYbm2004364; Thu, 18 Mar 2004 20:34:37 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2IJYaIt004360 for ; Thu, 18 Mar 2004 20:34:36 +0100 (MET) Received: from kolumbus.fi ([62.248.172.111]) by fep06-app.kolumbus.fi with ESMTP id <20040318193436.JZVB12001.fep06-app.kolumbus.fi@kolumbus.fi>; Thu, 18 Mar 2004 21:34:36 +0200 Message-ID: <4059F937.5060900@kolumbus.fi> Date: Thu, 18 Mar 2004 21:32:07 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: ietf-send@standards.ericsson.net Subject: Re: SEND "triggers": passive vs. active use References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 18 Mar 2004 19:35:31.0221 (UTC) FILETIME=[2CA2FC50:01C40D20] Content-Transfer-Encoding: 7bit Pekka, The starting point of the SEND design has been that it should work in a mixed environment, including the case where you are the only node supporting it. The specification does allow you to configure yourself as strictly SEND-only, but the default is required to be the mixed mode. The mixed operation has been described Section 8 of the specification, and is based on individual default router and neighbor cache entries. This means that you will be able to benefit from SEND on a communication with another SEND node while not preventing communications with a non-SEND node that has a different address. Similarly, if you use both stateless and stateful autoconfiguration, you will be able to use both addresses, just that only the ones coming from stateless can benefit from SEND (until we publish an extension for DHCP/home agent/proxy case). This implies that most of what you appear to require should work in the current specification. Take a look at Section 8 and tell us if something is missing. But I'd like to understand your example better to determine what you are worried about. Who is the proxy in this case and where is the router? If there is an ND proxy and you mistakenly configured your hosts to be strictly SEND-only, then you have a problem. But as explained above, this is not recommended. In the default use-SEND-if-possible configuration, the proxy is not an issue for communicating between SEND and non-SEND hosts and routers. Depending a bit on how the proxy is provided, it may or may not have an effect on SEND node to SEND node communications, however. If the proxy just modifies the link layer address in the ND message, this would be seen as an attack, and the message dropped. If the proxy sends its own ND message or strips off the SEND options, this would be seen simply as a non-SEND ND message and communications would be possible, albeit without protected ND. How much current deployment is there for IPv6 capable ND proxies, and what do they do? Draft-thaler-ipv6-ndproxy-01 does not talk about this, nor the use of AH, maybe it should... The only other problematic case that I can think of is a SEND mobile node on a home network, moving off somewhere else, which would cause other nodes on the link to not respect the home agent's claim of ownership. However, this can be dealt with by having the mobile node not use SEND in its home network for its home address (until the extension for the proxy case is available). Perhaps this is something that should be mentioned in the current SEND specification. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Sun Mar 21 09:51:10 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13421 for ; Sun, 21 Mar 2004 09:51:10 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2LEpAAh030138 for ; Sun, 21 Mar 2004 15:51:10 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sun, 21 Mar 2004 15:51:09 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HJS1BG0T; Sun, 21 Mar 2004 15:51:14 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2LEp2wg028940; Sun, 21 Mar 2004 15:51:02 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2LElKIt014074; Sun, 21 Mar 2004 15:47:20 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2LElK4g014073; Sun, 21 Mar 2004 15:47:20 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2LElJIt014069 for ; Sun, 21 Mar 2004 15:47:19 +0100 (MET) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2LElIb32071; Sun, 21 Mar 2004 16:47:18 +0200 Date: Sun, 21 Mar 2004 16:47:18 +0200 (EET) From: Pekka Savola To: Jari Arkko cc: ietf-send@standards.ericsson.net, Dave Thaler Subject: Re: SEND "triggers": passive vs. active use In-Reply-To: <4059F937.5060900@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 21 Mar 2004 14:51:09.0619 (UTC) FILETIME=[F25E6030:01C40F53] Again, just replying to one message, to avoid a message flood. I added Dave Thaler in Cc: just in case. (We're discussing ND-proxy + SEND scenarios..) On Thu, 18 Mar 2004, Jari Arkko wrote: > This implies that most of what you appear to require > should work in the current specification. Take a look > at Section 8 and tell us if something is missing. Right. This appears to be fine. > But I'd like to understand your example better to > determine what you are worried about. Who is the > proxy in this case and where is the router? For example: /-- ND node A /--- SEND node 1 / eth0 /-- SEND node 2 [ISP router] --- p2p link --- [ND-proxy] ---- SEND node 3 \-- ND node B In this case, SEND would work out of the box between SEND nodes 2 and 3. If ND-proxy didn't strip off SEND options (i.e., just modified the L2 information), communication between SEND node 1 and {2,3} would fail without fallback. Communication between any SEND and any ND node would work still. Another case would be: /-- ND node A [WLAN]/--- SEND node 1 / /-- SEND node 2 [ISP router] --- p2p link - [ND-proxy] -- bridge ----- SEND node 3 \-- ND node B [wired eth] .. where the sole purpose of ND-proxy would be to be able to extend a /64 subnet provided by the ISP to the home network when the p2p link and the home network would have dissimilar media that bridging them would be impossible (PPP + Ethernet?). In this scenario, SEND would work inside the network with everyone -- It would not work with the ISP router if it supported SEND though (but in that case, the ISP might probably be offering prefix delegation in any case). > If the proxy just modifies the link layer address in > the ND message, this would be seen as an attack, and > the message dropped. Right. > If the proxy sends its own ND > message or strips off the SEND options, this would > be seen simply as a non-SEND ND message and communications > would be possible, albeit without protected ND. How much > current deployment is there for IPv6 capable ND proxies, > and what do they do? Draft-thaler-ipv6-ndproxy-01 > does not talk about this, nor the use of AH, maybe > it should... Agreed. Stripping off would make the communication work (I think, may need some analysis?) but would disable SEND. So, if ND-proxy and SEND is a concern, maybe this would be a workaround; something to consider for ND-proxy document. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Mon Mar 22 16:39:25 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26227 for ; Mon, 22 Mar 2004 16:39:24 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2MLdPAh019413 for ; Mon, 22 Mar 2004 22:39:25 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 22 Mar 2004 22:39:24 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HJS138MR; Mon, 22 Mar 2004 22:39:17 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2MLd7XA018150; Mon, 22 Mar 2004 22:39:07 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2MLcxIt001417; Mon, 22 Mar 2004 22:38:59 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2MLcxad001416; Mon, 22 Mar 2004 22:38:59 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2MLcvIt001412 for ; Mon, 22 Mar 2004 22:38:58 +0100 (MET) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Mon, 22 Mar 2004 13:38:57 -0800 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 22 Mar 2004 13:38:56 -0800 Received: from RED-MSG-43.redmond.corp.microsoft.com ([157.54.12.203]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 22 Mar 2004 13:38:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: CGA Issue #9: Referencing PKCS#1 (Russ Housley) Date: Mon, 22 Mar 2004 13:36:39 -0800 Message-ID: <64A531765B7C8342BFA260497BE00457019D3C87@RED-MSG-43.redmond.corp.microsoft.com> Thread-Topic: CGA Issue #9: Referencing PKCS#1 (Russ Housley) Thread-Index: AcQQVcJBiPEUwQ8XTRGHQwWzTFMFpg== From: "Tuomas Aura" To: "SEND WG" X-OriginalArrivalTime: 22 Mar 2004 21:38:47.0735 (UTC) FILETIME=[0EF47470:01C41056] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id i2MLcwIt001413 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Russ Housley: Discuss: The first paragraph of section 3 says: > > ... For SEND, the public > key SHOULD be an RSA encryption key with the object identifier > rsaEncryption (i.e., "1.2.840.113549.1.1.1") and the subject public > key field SHOULD be formatted as an ASN.1 data structure of the type > RSAEncryptionKey defined in [PKCS.1.2002]. ... > PKCS #1 v2.1 (14 June 2002) does not specify a type of RSAEncryptionKey. I suspect that a type of RSAPublicKey is intended. This type and the associated object identifier can be found in RFC 3279 (as well as in PKCS #1 v2.1). The community will be able to easily locate RFC 3279. Please refer to section 2.3.1 of RFC 3279. Further, the use of SHOULD bothers me. The use of RSA can be SHOULD, but the format of fields when RSA is selected ought to be a MUST. I suggest: SEND SHOULD use an RSA public/private key pair. When RSA is used, the algorithm identifier must be rsaEncryption, which is 1.2.840.113549.1.1.1, and the RSA public key MUST be formatted using RSAPublicKey type as specified in section 2.3.1 of RFC 3279. --- Tuomas Aura: The above text sounds good to me. -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Mon Mar 22 16:41:17 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26491 for ; Mon, 22 Mar 2004 16:41:16 -0500 (EST) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2MLfHqY027395 for ; Mon, 22 Mar 2004 22:41:17 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 22 Mar 2004 22:41:16 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HJS139FB; Mon, 22 Mar 2004 22:41:23 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2MLfDwg003498; Mon, 22 Mar 2004 22:41:13 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2MLf4It001858; Mon, 22 Mar 2004 22:41:04 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2MLf40j001857; Mon, 22 Mar 2004 22:41:04 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2MLf3It001853 for ; Mon, 22 Mar 2004 22:41:03 +0100 (MET) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 22 Mar 2004 13:40:43 -0800 Received: from 157.54.8.155 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 22 Mar 2004 13:41:02 -0800 Received: from RED-MSG-43.redmond.corp.microsoft.com ([157.54.12.203]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 22 Mar 2004 13:41:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: CGA Issue #10: Generating weak random numbers (Russ Housley) Date: Mon, 22 Mar 2004 13:38:45 -0800 Message-ID: <64A531765B7C8342BFA260497BE00457019D3C8F@RED-MSG-43.redmond.corp.microsoft.com> Thread-Topic: CGA Issue #10: Generating weak random numbers (Russ Housley) Thread-Index: AcQQVc9yE9xC2/2GRLGkzB+u2g57aw== From: "Tuomas Aura" To: "SEND WG" X-OriginalArrivalTime: 22 Mar 2004 21:41:02.0004 (UTC) FILETIME=[5EFC4740:01C41056] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id i2MLf4It001854 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Russ Housley: In the 1st full paragraph on page 9, Section 4 says: > > ... The quality of the random number generator does not affect the > strength of the binding between the address and the public key. ... > This kind of statement will encourage implementors to use a constant, which is a problem. A SHA-1 hash of the time of day would be okay. Section 7.3 ought to reference RFC 1750. --- Tuomas Aura: It is true that using the time of day is much better for privacy than using zero. It is a good idea to suggest a way fo generating weak random numbers. I think using the unhashed time of day directly is just as good for privacy as hashing it. For remote nodes that only see the CGA and not the CGA Parameters, there is no difference because the time of day will be hashed anyway (with the Hash1 function). For local nodes that see the CGA Parameters, there is no real difference because they can do a brute-force reversal of the hash by trying all different time-of-day values. Thus, computing a SHA-1 hash of the time of day is unnecessary. Some implementations may, however require the initial values to be evenly distributed to all parts of the 128-bit modifier value space in order to avoid searching the same number twice. Therefore, some kind of hashing is useful. I suggest the following wording: The quality of the random number generator does not affect the strength of the binding between the address and the public key. Implementations that have no strong random numbers available MAY use a non-cryptographic pseudo-random number generator that is initialized with the current time of day. To Section 7.3, I would add the following: Advice on random number generation can be found in [RFC1750]. -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Mon Mar 22 16:41:47 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26524 for ; Mon, 22 Mar 2004 16:41:47 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2MLflqY027979 for ; Mon, 22 Mar 2004 22:41:48 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 22 Mar 2004 22:41:44 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HJS5S95C; Mon, 22 Mar 2004 22:38:32 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2MLcMwg003441; Mon, 22 Mar 2004 22:38:22 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2MLbkIt001249; Mon, 22 Mar 2004 22:37:46 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2MLbktR001248; Mon, 22 Mar 2004 22:37:46 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2MLbhIt001231 for ; Mon, 22 Mar 2004 22:37:44 +0100 (MET) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 22 Mar 2004 13:37:15 -0800 Received: from 157.54.5.25 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 22 Mar 2004 13:37:42 -0800 Received: from RED-MSG-43.redmond.corp.microsoft.com ([157.54.12.203]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 22 Mar 2004 13:35:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: CGA Issue #8: Extra stuff at the end of CGA parameters (Thomas Narten) Date: Mon, 22 Mar 2004 13:35:25 -0800 Message-ID: <64A531765B7C8342BFA260497BE00457019D3C80@RED-MSG-43.redmond.corp.microsoft.com> Thread-Topic: CGA Issue #8: Extra stuff at the end of CGA parameters (Thomas Narten) Thread-Index: AcQQVZZ3xWGBOehWTRaXBCwQFXML9Q== From: "Tuomas Aura" To: "SEND WG" X-OriginalArrivalTime: 22 Mar 2004 21:35:52.0162 (UTC) FILETIME=[A64E2420:01C41055] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id i2MLbjIt001232 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Thomas Narten: Comment: > SubjectPublicKeyInfo data structure. Future versions of this > specification may add new fields to the end of the CGA Parameters > and the verifier SHOULD ignore any unrecognized data that follows > the encoded public key. I don't understand what this is trying to say. This document defines what gets compared, used, etc. No reading of this spec should be taken to mean that "extra stuff after the end of the defined fields" should somehow be used as part of the SEND computations. Thus, the above would be a MUST (rather than a SHOULD), but I'd really like to understand why this needs mentioning at all? What problem/concern is the above trying to warn about? --- Tuomas Aura: Good point. This sentence is irrelevant and should be deleted. The original reason for including this sentence was to enable compatibility with potential future extensions, such as a second public key. But the NDOPTS draft prevents compatibility with such extensions anyway. -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Mon Mar 22 16:47:29 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26835 for ; Mon, 22 Mar 2004 16:47:28 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2MLlTqY028767 for ; Mon, 22 Mar 2004 22:47:29 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 22 Mar 2004 22:46:08 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HJSDL782; Mon, 22 Mar 2004 22:38:29 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2MLcSwg003450; Mon, 22 Mar 2004 22:38:28 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2MLbWIt001226; Mon, 22 Mar 2004 22:37:32 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2MLbWRV001225; Mon, 22 Mar 2004 22:37:32 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2MLbVIt001209 for ; Mon, 22 Mar 2004 22:37:31 +0100 (MET) Received: from mail6.microsoft.com ([157.54.6.196]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 22 Mar 2004 13:37:11 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 22 Mar 2004 13:37:29 -0800 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 22 Mar 2004 13:37:29 -0800 Received: from RED-MSG-43.redmond.corp.microsoft.com ([157.54.12.203]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 22 Mar 2004 13:37:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: CGA Issue #7: Strengthening Section 7.4 (Ted Hardie) Date: Mon, 22 Mar 2004 13:35:11 -0800 Message-ID: <64A531765B7C8342BFA260497BE00457019D3C7C@RED-MSG-43.redmond.corp.microsoft.com> Thread-Topic: CGA Issue #7: Strengthening Section 7.4 (Ted Hardie) Thread-Index: AcQQVY4MjwigeDixSNGDGT2hCCl89w== From: "Tuomas Aura" To: "SEND WG" X-OriginalArrivalTime: 22 Mar 2004 21:37:29.0492 (UTC) FILETIME=[E0518540:01C41055] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id i2MLbWIt001213 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Ted Hardie: Comment: The following text is fundamentally good: Finally, some cautionary notes should be made about using CGA-based authentication for other purposes than SEND. First, the other protocols should include type tags and the sender address in all signed messages in the same way as SEND does. Because of the possibility of related-protocol attacks, it is advisable to use the public key only for signing and not for encryption. Second, CGA-based authentication is particularly suitable for securing neighbor discovery [RFC2461] and duplicate address detection [RFC2462] because these are network-layer signaling protocols where IPv6 addresses are natural endpoint identifiers. In any protocol that aims to protect higher-layer data, CGA-based authentication alone is not sufficient and there must also be a secure mechanism for mapping higher-layer identifiers, such as DNS names, to IP addresses. In that it discourages folks from using CGA-based authentication alone. I'd suggest strengthing it even further, though. Would something like the following text be acceptable? CGA-based authentication should not be considered for purposes other than SEND and closely related mechanisms. CGA-based authentication is particularly suitable for securing neighbor discovery [RFC2461] and duplicate address detection [RFC2462] because these are network-layer signaling protocols where IPv6 addresses are natural endpoint identifiers. In any protocol that aims to protect higher-layer data, CGA-based authentication alone is not sufficient as there must also be a secure mechanism for mapping higher-layer identifiers, such as DNS names, to IP addresses. Further, using CGA-based authentication for other purposes may weaken the effectiveness of this mechanism for SEND, because of the possibility of related-protocol attacks. If another mechanism needs to re-use CGA-based authentication, it must take care that it include type tags and the sender address in all signed messages in the same way as SEND does and it must use the public key only for signing and not for encryption. --- Tuomas Aura: I suggest the following wording: Finally, a strong cautionary note needs to be made about using CGA-based authentication for other purposes than SEND. First, the other protocols MUST include a type tag and the sender address in all signed messages in the same way as SEND does. Each protocol MUST define its own type tag values as explained in Section 8. Moreover, because of the possibility of related-protocol attacks, the public key can be used only for signing and it MUST NOT be used for encryption. Second, CGA-based authentication is particularly suitable for securing neighbor discovery [RFC2461] and duplicate address detection [RFC2462] because these are network-layer signaling protocols where IPv6 addresses are natural endpoint identifiers. In any protocol that aims to protect higher-layer data, CGA-based authentication alone is not sufficient and there must also be a secure mechanism for mapping higher-layer identifiers, such as DNS names, to IP addresses. If the primary goal is not to authenticate an IPv6 address, CGA-based authentication is probably not the right solution. -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Mon Mar 22 16:54:34 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27299 for ; Mon, 22 Mar 2004 16:54:34 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2MLsZAh021397 for ; Mon, 22 Mar 2004 22:54:35 +0100 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 22 Mar 2004 22:54:35 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HJS5TAWN; Mon, 22 Mar 2004 22:41:49 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2MLfUXA018178; Mon, 22 Mar 2004 22:41:30 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2MLfLIt001900; Mon, 22 Mar 2004 22:41:21 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2MLfLVF001899; Mon, 22 Mar 2004 22:41:21 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2MLfJIt001888 for ; Mon, 22 Mar 2004 22:41:20 +0100 (MET) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 22 Mar 2004 13:41:00 -0800 Received: from 157.54.6.150 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 22 Mar 2004 13:41:18 -0800 Received: from RED-MSG-43.redmond.corp.microsoft.com ([157.54.12.203]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 22 Mar 2004 13:41:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: CGA Issue #11: Key lifetimes (Russ Housley) Date: Mon, 22 Mar 2004 13:39:02 -0800 Message-ID: <64A531765B7C8342BFA260497BE00457019D3C92@RED-MSG-43.redmond.corp.microsoft.com> Thread-Topic: CGA Issue #11: Key lifetimes (Russ Housley) Thread-Index: AcQQVhfNFafN7NDgRDuHTO8WOf8sww== From: "Tuomas Aura" To: "SEND WG" X-OriginalArrivalTime: 22 Mar 2004 21:41:19.0399 (UTC) FILETIME=[695A8B70:01C41056] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id i2MLfLIt001894 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Russ Housley: The security considerations ought to say something about the lifetime of the public/private key pair. The one brief statement in section 7.3 is not sufficient for an implementor to know how often the key pair needs to be changed. --- Tuomas Aura: There isn't any reason for changing the keys, except if the host is compromised and its private keys may have leaked. I suggest adding the following to Section 7.1: The impact of key compromise depends on the application of the CGA-based signatures. In SEND, it is not a major concern. The private signature key is typically stored in the physical node that uses the CGA generated from the corresponding public key. If the private key is compromised, it is likely that the node itself has been compromised. If that is the case, the attacker does not need to spoof SEND messages from the node. When it is discovered that a node has been compromised, a new signature key and a new CGA SHOULD be generated. The address change effectively revokes the old public key. It is not necessary to have any additional key revocation mechanism or to limit the lifetimes of the signature keys. -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Tue Mar 23 04:49:03 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14605 for ; Tue, 23 Mar 2004 04:49:02 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2N9n2qY021881 for ; Tue, 23 Mar 2004 10:49:03 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 23 Mar 2004 10:49:02 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HJSDRWPM; Tue, 23 Mar 2004 10:44:08 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2N9i7XA024386; Tue, 23 Mar 2004 10:44:07 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2N9h4It019944; Tue, 23 Mar 2004 10:43:04 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2N9h4Uj019943; Tue, 23 Mar 2004 10:43:04 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2N9h2It019939 for ; Tue, 23 Mar 2004 10:43:02 +0100 (MET) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 23 Mar 2004 01:44:20 -0800 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 23 Mar 2004 01:43:00 -0800 Received: from RED-MSG-43.redmond.corp.microsoft.com ([157.54.12.203]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 23 Mar 2004 01:44:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: CGA issues list link Date: Tue, 23 Mar 2004 01:40:41 -0800 Message-ID: <64A531765B7C8342BFA260497BE00457019D4155@RED-MSG-43.redmond.corp.microsoft.com> Thread-Topic: CGA issues list link Thread-Index: AcQQuufNMV6jGaQaT2mXrTLsblnvnw== From: "Tuomas Aura" To: "SEND WG" X-OriginalArrivalTime: 23 Mar 2004 09:44:14.0981 (UTC) FILETIME=[67371B50:01C410BB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id i2N9h3It019940 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Reminder: The CGA issues list is at http://research.microsoft.com/users/tuomaura/CGA/CGAIssues.aspx The same text as in my previous emails, all conveniently on one page. Tuomas -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Wed Mar 24 07:06:47 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17290 for ; Wed, 24 Mar 2004 07:06:46 -0500 (EST) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2OC6jqY006846 for ; Wed, 24 Mar 2004 13:06:45 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 24 Mar 2004 13:06:44 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HJS1AF20; Wed, 24 Mar 2004 13:06:44 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2OC6Xwg010455; Wed, 24 Mar 2004 13:06:33 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2OC5XIt016541; Wed, 24 Mar 2004 13:05:33 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2OC5XGC016540; Wed, 24 Mar 2004 13:05:33 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2OC5VIt016524 for ; Wed, 24 Mar 2004 13:05:32 +0100 (MET) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 24 Mar 2004 04:05:46 -0800 Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 24 Mar 2004 04:05:26 -0800 Received: from RED-MSG-43.redmond.corp.microsoft.com ([157.54.12.203]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 24 Mar 2004 04:05:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: CGA issue #12: Upgrade path for crypto algorithms (related to issue #8) Date: Wed, 24 Mar 2004 04:03:09 -0800 Message-ID: <64A531765B7C8342BFA260497BE0045701A1C376@RED-MSG-43.redmond.corp.microsoft.com> Thread-Topic: CGA issue #12: Upgrade path for crypto algorithms (related to issue #8) Thread-Index: AcQRl/k3uWwqMJqPR+yRoGvLExc4Yg== From: "Tuomas Aura" To: "SEND WG" X-OriginalArrivalTime: 24 Mar 2004 12:05:51.0357 (UTC) FILETIME=[59DCF2D0:01C41198] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id i2OC5WIt016537 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit The comment by Thomas Narten (issue #8) triggered me to think about another issue that has been ignored so far: upgrade path to another signature algorithm. My original idea was that the CGA Parameters (the input to Hash1) would be an opaque blob of bytes. The CGA verification algorithm would parse the recognized fields (modifier, subnet prefix, collision count, public key) and return the public key if the verification was successful. The CGA verification algorithm would ignore any unrecognized data at the and of the blob after the public key. This would enable future versions of the specification to add new fields to the end of the CGA Parameters. In particular, the CGA Parameters could include a second public key during transition to a more secure signature algorithm. Implementations that do not understand the second algorithm would include the unrecognized data (the second public key at the end of CGA Parameters) in the hash inputs but ignore it otherwise. Implementations that support the second signature algorithm would use the second public key. Unfortunately, this idea of extendibility does not work with the current NDOPT draft. Instead of treating the CGA Parameters as an opaque block of bytes, as I hoped, the NDOPT draft divides the CGA Parameters into several different fields: Collision Cnt, Modifier and Key Information. The advantages of this are that the packet diagrams look prettier, and that 7 bytes are saved because the subnet prefix need not be repeated. The disadvantage is that it is not possible to pass unrecognized data, such as a second public key, at the end of the CGA Parameters. Thus, the NDOPT implementation is not upward compatible in the way I had hoped. I should have noticed this issue earlier. I ignored the issue because we decided not to include any extensions (such as a second signature algorithm) in the current specs. The options are: (1) Forget about this. Live with the fact that it will be impossible to extend the CGA Parameters data structure without breaking compatibility with the first-generation SEND implementations. (This is the easiest option but we might regret it later if RSA or SHA needs replacing.) (2) Change the CGA draft so that it explicitly allows multiple concatenated public keys in CGA Parameters. Change the NDOPT draft accordingly. (I strongly dislike this option because everyone will want to have their favorite algorithms standardized, implementations will bloat, and interoperability will break.) (3) Change the CGA draft so that it allows unrecognized data at the end of the CGA Parameters, after the public key. The unrecognized fields will be input to Hash1 and Hash2 but will be ignored otherwise. Change the NDOPT draft by replacing the Collision Cnt, Modifier and Key Information fields in the CGA option with a single block of data that has the same format as CGA Parameters in the CGA draft and that can have unrecognized data after the public key. I propose using the third option because it does not over-specify things. If we one day feel that RSA or SHA needs replacing, we can at that time specify an extension to the CGA Parameters format to help the transition. Moreover, it enables other future extensions that we might not have thought about yet. On the other hand, it does not invite people to add their own crypto algorithms unnecessarily, which is bound to happen if we have a well-defined process for adding them. Opinions? Tuomas -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Wed Mar 24 11:48:12 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05717 for ; Wed, 24 Mar 2004 11:48:12 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2OGmCqY022788 for ; Wed, 24 Mar 2004 17:48:12 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 24 Mar 2004 17:48:08 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HJS6LTNN; Wed, 24 Mar 2004 17:48:20 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2OGm7XA019864; Wed, 24 Mar 2004 17:48:07 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2OGlFIt017303; Wed, 24 Mar 2004 17:47:15 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2OGlFn9017302; Wed, 24 Mar 2004 17:47:15 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2OGlDIt017298 for ; Wed, 24 Mar 2004 17:47:13 +0100 (MET) Message-ID: <02cc01c411bf$bbd4d5d0$366115ac@dcml.docomolabsusa.com> From: "James Kempf" To: Subject: Deadline for Resolving Discuss Issues on draft-ietf-send-cga-05.txt Date: Wed, 24 Mar 2004 08:47:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 24 Mar 2004 16:48:08.0062 (UTC) FILETIME=[C8ED09E0:01C411BF] Content-Transfer-Encoding: 7bit Folks, On Monday, Tuomas sent out suggested resolutions for Issues 9, 10, 8, 7, and 11 on draft-ietf-send-cga-05.txt, which arose during IESG review. If possible, I'd like for people to get comments to the list by next Wednesday, March 31. With some amount of luck, we can get the draft back to the IESG by April 5. If you have any comments, please send them to the list. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Wed Mar 24 22:02:28 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09407 for ; Wed, 24 Mar 2004 22:02:27 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2P32QqY008808 for ; Thu, 25 Mar 2004 04:02:27 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 25 Mar 2004 04:02:26 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HSRDFL9M; Thu, 25 Mar 2004 04:02:27 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2P32PXA029450; Thu, 25 Mar 2004 04:02:25 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2P31YIt000638; Thu, 25 Mar 2004 04:01:34 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2P31YE4000636; Thu, 25 Mar 2004 04:01:34 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2P31WIt000627 for ; Thu, 25 Mar 2004 04:01:32 +0100 (MET) Received: from mail5.microsoft.com ([157.54.6.156]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 24 Mar 2004 19:01:50 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Wed, 24 Mar 2004 18:54:38 -0800 Received: from 157.54.8.155 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 24 Mar 2004 18:54:38 -0800 Received: from RED-MSG-43.redmond.corp.microsoft.com ([157.54.12.203]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 24 Mar 2004 18:54:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Detailed text changes to the CGA draft to resolve CGA issue #12 Date: Wed, 24 Mar 2004 18:52:12 -0800 Message-ID: <64A531765B7C8342BFA260497BE0045701A1CF50@RED-MSG-43.redmond.corp.microsoft.com> Thread-Topic: Detailed text changes to the CGA draft to resolve CGA issue #12 Thread-Index: AcQSFCxecsoUIYwNT4+uIOoZyKDuGQ== From: "Tuomas Aura" To: "SEND WG" X-OriginalArrivalTime: 25 Mar 2004 02:54:38.0062 (UTC) FILETIME=[830E60E0:01C41214] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id i2P31XIt000629 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit This is a detailed proposal for resolving CGA issue #12: upgrade path for crypto algorithms. The changes below are to the CGA draft. Corresponding changes needs to be made to the NDOPT draft. Please see my previous email for the motivation. The key changes are to Section 3 where the CGA Parameters data structure is now specified with the help of a diagram, and may have optional extension fields at its end. The entire CGA Parameters data structure should be sent as an opaque block of bytes in the CGA Option (see Section 5.1 of the NDOPT draft). The proposed changes to the CGA draft follow. (CHANGE 1) Rewrite Section 3. CGA Parameters and Hash Values: 3. CGA Parameters and Hash Values Each CGA is associated with a CGA Parameters data structure, which has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Modifier (16 octets) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Subnet Prefix (8 octets) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Collision Count| | +-+-+-+-+-+-+-+-+ | | | ~ Public Key (variable length) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Extension Fields (optional, variable length) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Modifier This field contains an 128-bit unsigned integer , which can be any value. The modifier is used during CGA generation to implement the hash extension and to enhance privacy by adding randomness to the address. Subnet Prefix This field contains the 64-bit subnet prefix of the CGA. Collision Count This is an 8-bit unsigned integer, which MUST be 0, 1 or 2. The collision count is incremented during CGA generation to recover from an address collision detected by duplicate address detection. Public Key This is a variable length field containing the public key of the address owner. The public key MUST be formatted as a DER-encoded [ITU.X690.2002] ASN.1 structure of the type SubjectPublicKeyInfo defined in the Internet X.509 certificate profile [RFC3280]. SEND SHOULD use an RSA public/private key pair. When RSA is used, the algorithm identifier MUST be rsaEncryption, which is 1.2.840.113549.1.1.1, and the RSA public key MUST be formatted using RSAPublicKey type as specified in Section 2.3.1 of RFC 3279 [RFC3279]. The RSA key length SHOULD be at least 384 bits. Other public key types or format SHOULD NOT be used for SEND to avoid incompatibilities [I-D.ietf-send-ndopt] between implementations. The length of the public key is determined by the ASN.1 encoding. Extension Fields This is an optional variable-length field, which is not used in the current specification. Future versions of this specification may use this field for additional data that needs to be included in CGA Parameters data structure. IETF standards action is required to specify the use of the extension fields. Implementations MUST ignore the value of any unrecognized extension fields. The two hash values MUST be computed as follows. The SHA-1 hash algorithm [FIPS.180-1.1995] is applied to the CGA Parameters. When computing Hash1, the input to the SHA-1 algorithm is the CGA Parameters data structure. The 64-bit Hash1 is obtained by taking the leftmost 64 bits of the 160-bit SHA-1 hash value. When computing Hash2, the input is the same CGA Parameters data structure except that the subnet prefix and collision count are set to zero. The 112-bit Hash2 is obtained by taking the leftmost 112 bits of the 160-bit SHA-1 hash value. Note that the hash values are computed over the entire CGA Parameters data structure, including any unrecognized extension fields. (CHANGE 2) Add to the end of Section 4. CGA Generation: Future versions of this specification may specify additional inputs to the CGA generation algorithm, which are concatenated as extension fields to the end of the CGA Parameters data structure. This document does not specify how such data fields are handled during CGA generation. (CHANGE 3) Change 2 sentences in Section 5. CGA Verification: The CGA Parameters consist of the concatenated modifier, subnet prefix, collision count, public key, and optional extension fields. Concatenate from left to right the modifier, 9 zero octets, and the public key, and any extension fields that follow the public key in the CGA Parameters data structure. (CHANGE 4) Add to the end of Section 5. CGA Verification: Implementations of CGA verification MUST ignore the value of any unrecognized extension fields that follow the public key in the CGA Parameters data structure. However, implementations MUST include any such unrecognized data in the hash input when computing Hash1 in step (3) and Hash2 in step (6) of the CGA verification algorithm. This is important to ensure upward compatibility with future extensions. Tuomas -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Thu Mar 25 13:12:11 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12122 for ; Thu, 25 Mar 2004 13:12:11 -0500 (EST) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2PICAAh011955 for ; Thu, 25 Mar 2004 19:12:10 +0100 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 25 Mar 2004 19:12:01 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HJS1PZ1D; Thu, 25 Mar 2004 19:12:01 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2PIC0XA018648; Thu, 25 Mar 2004 19:12:00 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2PIAxIt028025; Thu, 25 Mar 2004 19:10:59 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2PIAxlh028024; Thu, 25 Mar 2004 19:10:59 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2PIAvIt028020 for ; Thu, 25 Mar 2004 19:10:57 +0100 (MET) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 25 Mar 2004 10:11:12 -0800 Received: from 157.54.8.109 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 25 Mar 2004 10:10:50 -0800 Received: from RED-MSG-43.redmond.corp.microsoft.com ([157.54.12.203]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 25 Mar 2004 10:10:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Intermediate version of the CGA draft Date: Thu, 25 Mar 2004 10:08:24 -0800 Message-ID: <64A531765B7C8342BFA260497BE0045701A6B15F@RED-MSG-43.redmond.corp.microsoft.com> Thread-Topic: Intermediate version of the CGA draft Thread-Index: AcQSlCnn3JHwnz2LQYa2xWWtpdKQqw== From: "Tuomas Aura" To: "SEND WG" X-OriginalArrivalTime: 25 Mar 2004 18:10:53.0540 (UTC) FILETIME=[82FE9A40:01C41294] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id i2PIAwIt028021 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit The following intermediate version of the CGA draft now incorporates the proposed solutions to issues #8-#12: http://research.microsoft.com/users/tuomaura/CGA/draft-ietf-send-cga-pre 06.txt If this is ok, then there are no open issues left. Tuomas -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Fri Mar 26 06:22:22 2004 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13654 for ; Fri, 26 Mar 2004 06:22:21 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2QBMDYG010808 for ; Fri, 26 Mar 2004 12:22:17 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 26 Mar 2004 12:22:13 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HV9RBMLB; Fri, 26 Mar 2004 12:22:30 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2QBM3wg012482; Fri, 26 Mar 2004 12:22:03 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2QBL1It022955; Fri, 26 Mar 2004 12:21:01 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2QBL1aa022949; Fri, 26 Mar 2004 12:21:01 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2QBKvIt022926 for ; Fri, 26 Mar 2004 12:20:58 +0100 (MET) Received: from localhost ([130.194.13.85]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L86TAQ4QGU8X458Q@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Fri, 26 Mar 2004 16:10:05 +1100 Received: from broink.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 2D288158002; Fri, 26 Mar 2004 16:10:04 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by broink.its.monash.edu.au (Postfix) with ESMTP id 10811120009; Fri, 26 Mar 2004 16:10:04 +1100 (EST) Date: Fri, 26 Mar 2004 16:10:03 +1100 From: Greg Daley Subject: Re: SEND "triggers": passive vs active use? To: James Kempf Cc: Pekka Savola , ietf-send@standards.ericsson.net, Erik Nordmark Reply-to: greg.daley@eng.monash.edu.au Message-id: <4063BB2B.1080108@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <4058E140.4000905@eng.monash.edu.au> <01de01c40d0a$bf75f7f0$366115ac@dcml.docomolabsusa.com> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 26 Mar 2004 11:22:13.0191 (UTC) FILETIME=[96240570:01C41324] Content-Transfer-Encoding: 7BIT Hi James, It's not text, but here are some ideas about the section. I think that the rules which ae defined in section 8 are basically OK. I'm still unsure whether we believe a SEND router is secure just based on the signature option, since when we arrive on the network, we don't necessarily have a delegation chain for that router. For the first 0-500ms, we has essentially an "unsecured router". The rules in section 8 are sound and don't leave holes in the case that a host moves for non-SEND routers, although it looks like this implies the standard reachability testing from ND (NUD). The second last dot point indicates that we should select reachable SEND routers over reachable non-SEND routers (and there are similar explanations for ND). This is the trigger to switch on SEND for Router Discovery. I'd guess that this implies that we want reachable non-SEND routers over unreachable SEND routers. This may be the switch-off for SEND, but may have to be specified. If we want to talk a bit more about SEND router/neighbour reachability, it may be possible to keep some reachability state for a SEND router until we've checked that it isn't in fact reachable, but allow usage of a non-SEND router in the case we have other reliable information which can be used for change detection (This is starting to sound a little like DNA though). For example this could be our own link-layer telling us about arrival on a new LAN segment. The current non-SEND to SEND transition case needs some checks, since a signed CGA addressed router advertisement may take routing away from a legitimate non-SEND router, without using any authorization information. This is worse than the current state since it occurs without NUD checks for the current router. Perhaps this is one strategy: ?? A host MAY treat unauthorized SEND routers as insecure, but allow temporary adoption of insecure routers (including non-SEND routers) while authorization is being checked. This SHOULD only be done if the host believes there may have been a link or L2 change. This aims to prevent overriding a good SEND config with an unsecured one. Checking authorization in this case is the determination of delegation information for SEND, or the unreachability of the currently configured router (whichever is determined sooner). This may cause a temporary state change of state such as: 1) default router configuration 2) neighbour cache state for the configured router Packets sent to these unsecured routers may be lost or subverted to other addresses or used for man-in-the-middle attacks. Care should be taken to ensure that any routing state changes can be rolled back in the case of current router indicates its reachability. In the case that the unreachability of the current router router is determined, such changes MAY be committed, and a unsecured or non-SEND router adopted as current. Otherwise, only authorized SEND router advertisements can override existing SEND configurations. ?? I'm not sure if this preserves the same security properties in the general case, though. In this case, we'd need two indicators (flags?): one for signed NC messages, and one for router authorization. reception of a signed NC message wouldn't be sufficient to override the (signed, authorized) SEND router. Currently there's only a 'Secured' flag. Which may be misleading. Greg James Kempf wrote: > Greg, > > Please read Section 8 of draft-ietf-send-ndopt-04.txt and let the WG know if > you see anything there that would require SEND to be turned or "triggered" > off on a network where the router or any of the other nodes do not support > SEND. The intent of the design is that SEND nodes should "just work" with > standard RFC 2461 nodes (including routers). > > jak > > ----- Original Message ----- > From: "Greg Daley" > To: "Pekka Savola" > Cc: ; "Erik Nordmark" > > Sent: Wednesday, March 17, 2004 3:37 PM > Subject: Re: SEND "triggers": passive vs active use? > > > >>Hi Pekka, >> >>Pekka Savola wrote: >> >>>Hi, >>> >>>During discussion of ND-proxy applicability w/ send at v6ops, an open >>>issue in SEND came up: what is the deployment model of SEND? Is it >>>practical? >>> >>>That is, I think we'd like the vendors to turn on SEND by default if >>>they implement it, right? But at the same time, it might take quite >>>long before SEND is widely enough deployed that actively using it >>>would make sense. >>> >>>I don't quite remember how it is in the document, but it struck me >>>that one possibility (if an "active model" would not be deemed useful) >>>would be to have a "trigger" of a kind. SEND would be active, but not >>>used -- until some activity triggers it. Such trigger could be e.g., >>>receiving a SEND-enabled router advertisement, or CGA-signed Neighbor >>>Discovery packet. >>> >>>The idea here would be to make sure SEND is enabled and out there, >>>in "passive" mode -- preserving resources and hassle until it's >>>actually needed. >>> >>>These are quite raw thoughts for now, but perhaps this might trigger >>>some discussion on the transition to SEND. >> >>As a deployment issue, you're right: there won't be many devices >>using SEND initially, so there may be a requirement to fall back to >>ND in the case that no-one is doing SEND. We'll need to be careful >>that decisions about this don't leave hosts with a mechanism where >>other devices can cause them to turn off SEND though. >> >>I'd guess that when operating within a particular network, it is >>fairly straightforward: Once you receive an authorized RA with a >>SEND signature in it, SEND should be run on the host. >> >>I'd guess that hosts may wish to use SENDC before then >>though, for the purpose of mutual authentication with other SEND >>devices on the link. >> >>Also, it may not make sense to delay generation or utilization of >>CGAs until SEND authorization occurs (especially for link-local). >> >>There are also devices which will be moving around between different >>IP links/subnets, though. These won't have a choice as to whether >>SEND is turned on for a particular router or subnet. >> >>In the case that SEND is on for one router, it doesn't imply that SEND >>should be used on nearby subnets. We may see a situation where >>a host has had SEND operation on one subnet, and ignores >>router advertisements on a new subnet because of that. >> >>Checking reachability to the current SEND router may be one mechanism >>which is useful to ensure that we are still connected to a subnet >>(so unsecured ND messages can't override SEND messages), but when >>the host has moved, or the SEND router has died, this may take a long >>time with existing NUD/SEND Timestamp techniques. >> >>So it may also be necessary to "trigger (?)" switching SEND off in >>some cases. These devices may know about their wireless connectivity >>(for example upper later (secured?) packet reception halts, Link layer >>information suggests change...), and would have to reset the ND state, >>including potentially security. >> >>-------------------------------------------------------------------- >>To unsubscribe from this list, send email with "UNSUBSCRIBE" in the >>body to . >>Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html >>-------------------------------------------------------------------- >> >>This communication is confidential and intended solely for the > > addressee(s). Any unauthorized review, use, disclosure or distribution is > prohibited. If you believe this message has been sent to you in error, > please notify the sender by replying to this transmission and delete the > message without disclosing it. Thank you. > >>E-mail including attachments is susceptible to data corruption, > > interruption, unauthorized amendment, tampering and viruses, and we only > send and receive e-mails on the basis that we are not liable for any such > corruption, interception, amendment, tampering or viruses or any > consequences thereof. > > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Fri Mar 26 12:08:28 2004 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01792 for ; Fri, 26 Mar 2004 12:08:27 -0500 (EST) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2QH8QYG027877 for ; Fri, 26 Mar 2004 18:08:27 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 26 Mar 2004 18:08:16 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HV03JXPV; Fri, 26 Mar 2004 18:08:17 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2QH85wg003607; Fri, 26 Mar 2004 18:08:05 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2QH7IIt006602; Fri, 26 Mar 2004 18:07:18 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2QH7HRu006601; Fri, 26 Mar 2004 18:07:17 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2QH7FIt006585 for ; Fri, 26 Mar 2004 18:07:16 +0100 (MET) Message-ID: <00ad01c41354$d76b2380$366115ac@dcml.docomolabsusa.com> From: "James Kempf" To: Cc: "Pekka Savola" , , "Erik Nordmark" References: <4058E140.4000905@eng.monash.edu.au> <01de01c40d0a$bf75f7f0$366115ac@dcml.docomolabsusa.com> <4063BB2B.1080108@eng.monash.edu.au> Subject: Re: SEND "triggers": passive vs active use? Date: Fri, 26 Mar 2004 09:07:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 26 Mar 2004 17:08:16.0777 (UTC) FILETIME=[EE33CF90:01C41354] Content-Transfer-Encoding: 7bit Hi Greg, Thanx for taking a look at the draft. > I think that the rules which ae defined in section 8 > are basically OK. > > I'm still unsure whether we believe a SEND router > is secure just based on the signature option, since > when we arrive on the network, we don't necessarily have > a delegation chain for that router. For the first > 0-500ms, we has essentially an "unsecured router". > If speed is not at issue, the node can use DCS/DCA in order to solicit a delegation chain if it doesn't have one. If speed is at issue (as in a handover situation), then the node should obtain the certificate chain prior to moving using something like CARD. Alternatively, as we discussed on this list earlier, the ISP can provision the access network routers with the same certificate, as some Web services do with duplicate servers, with correspondingly more risk in the event of compromise. Then a mobile node would not need to obtain any additional cert chain information unless it moved outside of the access network. I don't see this as any different than any other security protocol, in which there is some time up front in which both sides don't trust each other, then they negotiate via a procedure whereby they prove their trustworthiness. So, in a sense, you are right that for an initial period, the router is not known to the node to be trustworthy, but that is not much different than any other security situation. How long it takes depends on the amount of preconfiguration available. It is true that the node doesn't have the opportunity to do a CRL check prior to accepting the signature, but this is unavoidable, since the node does not, at that time, have a connection to the Internet. The spec says that the node should perform certificate revocation checking as soon as possible afterwards and terminate using the router if the check fails or fails to complete. So there will be some period of time in which the node is using the router but has not yet verified the revocation status of the router's certificate. > The rules in section 8 are sound and don't leave holes in the case > that a host moves for non-SEND routers, although it looks > like this implies the standard reachability testing from ND (NUD). > The SEND spec is not concerned with the basic discovery procedure of 2461. In that sense, it is different from DNA. > The second last dot point indicates that we should select > reachable SEND routers over reachable non-SEND routers (and > there are similar explanations for ND). This is the trigger > to switch on SEND for Router Discovery. > Essentially, yes. > I'd guess that this implies that we want reachable non-SEND > routers over unreachable SEND routers. > This may be the switch-off for SEND, but may have to be > specified. > Doesn't this cover it: o The conceptual sending algorithm is modified so that an insecure router is selected only if there is no reachable SEND router for the prefix. That is, the algorithm for selecting a default router favors reachable SEND routers over reachable non-SEND ones. > If we want to talk a bit more about SEND router/neighbour > reachability, it may be possible to keep some reachability > state for a SEND router until we've checked that it isn't > in fact reachable, but allow usage of a non-SEND router in > the case we have other reliable information which can be used > for change detection (This is starting to sound a little > like DNA though). > For example this could be our own link-layer telling us about > arrival on a new LAN segment. > > The current non-SEND to SEND transition case needs some checks, > since a signed CGA addressed router advertisement may take > routing away from a legitimate non-SEND router, without using > any authorization information. This is worse than the current state > since it occurs without NUD checks for the current router. > > Perhaps this is one strategy: > > ?? > > A host MAY treat unauthorized SEND routers as insecure, > but allow temporary adoption of insecure routers > (including non-SEND routers) while authorization > is being checked. This SHOULD only be done if > the host believes there may have been a link or L2 change. > This aims to prevent overriding a good SEND config > with an unsecured one. > > Checking authorization in this case is the determination > of delegation information for SEND, or the unreachability > of the currently configured router (whichever > is determined sooner). > > This may cause a temporary state change of state > such as: > > 1) default router configuration > > 2) neighbour cache state for the configured router > > Packets sent to these unsecured routers may be lost or subverted > to other addresses or used for man-in-the-middle attacks. > > Care should be taken to ensure that any routing state > changes can be rolled back in the case of current router > indicates its reachability. > > In the case that the unreachability of the current router > router is determined, such changes MAY be committed, > and a unsecured or non-SEND router adopted as current. > > Otherwise, only authorized SEND router advertisements can override > existing SEND configurations. > > How about adding this as a bullet to the list: o A node MAY adopt an insecure router, including a SEND router for which full security checks have not yet been completed, while security checking for the SEND router is underway. Security checks in this case include delegation chain solicitation, certificate verification, CRL checks, and RA signature checks. A node MAY also adopt an insecure router if a SEND router becomes unreachable, but SHOULD attempt to find a SEND router as soon as possible, since the unreachability may be the result of an attack. Note that accepting an insecure router opens the node to possible attacks, and nodes that choose to accept insecure routers do so at their own risk. The node SHOULD in any case prefer the SEND router as soon as a new SEND router appears and security checks are complete I think we should leave out the L2 change part because this might also be useful for fixed hosts. I also don't think we need to delineate the attacks, since they are described elsewhere. > > ?? > > I'm not sure if this preserves the same security > properties in the general case, though. > > In this case, we'd need two indicators (flags?): one for signed > NC messages, and one for router authorization. > reception of a signed NC message wouldn't be sufficient to > override the (signed, authorized) SEND router. > > Currently there's only a 'Secured' flag. Which may be misleading. > > Where would flags be necessary? jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Sun Mar 28 19:33:43 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13950 for ; Sun, 28 Mar 2004 19:33:42 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2T0XeqY013964 for ; Mon, 29 Mar 2004 02:33:40 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 29 Mar 2004 02:33:39 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HWBDVSMJ; Mon, 29 Mar 2004 02:33:38 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2T0XYwg002553; Mon, 29 Mar 2004 02:33:34 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2T0WNIt003528; Mon, 29 Mar 2004 02:32:23 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2T0WNns003527; Mon, 29 Mar 2004 02:32:23 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2T0WJIt003508 for ; Mon, 29 Mar 2004 02:32:20 +0200 (MET DST) Received: from localhost ([130.194.13.81]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L8ANSYW7FQ90D09M@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Mon, 29 Mar 2004 10:16:11 +1000 Received: from kapow.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id CE08C1B000D; Mon, 29 Mar 2004 10:16:08 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id B4DA9124013; Mon, 29 Mar 2004 10:16:08 +1000 (EST) Date: Mon, 29 Mar 2004 10:16:08 +1000 From: Greg Daley Subject: Re: SEND "triggers": passive vs active use? To: James Kempf Cc: Pekka Savola , ietf-send@standards.ericsson.net, Erik Nordmark Reply-to: greg.daley@eng.monash.edu.au Message-id: <40676AC8.4080101@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <4058E140.4000905@eng.monash.edu.au> <01de01c40d0a$bf75f7f0$366115ac@dcml.docomolabsusa.com> <4063BB2B.1080108@eng.monash.edu.au> <00ad01c41354$d76b2380$366115ac@dcml.docomolabsusa.com> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 29 Mar 2004 00:33:39.0334 (UTC) FILETIME=[7AE9EA60:01C41525] Content-Transfer-Encoding: 7BIT Hi James, James Kempf wrote: > Hi Greg, > > Thanx for taking a look at the draft. That's OK. SEND's one of the most interesting technologies around. >>I think that the rules which ae defined in section 8 >>are basically OK. >> >>I'm still unsure whether we believe a SEND router >>is secure just based on the signature option, since >>when we arrive on the network, we don't necessarily have >>a delegation chain for that router. For the first >>0-500ms, we has essentially an "unsecured router". >> > > > If speed is not at issue, the node can use DCS/DCA in order to solicit a > delegation chain if it doesn't have one. If speed is at issue (as in a > handover situation), then the node should obtain the certificate chain prior > to moving using something like CARD. > > Alternatively, as we discussed on this list earlier, the ISP can provision > the access network routers with the same certificate, as some Web services > do with duplicate servers, with correspondingly more risk in the event of > compromise. Then a mobile node would not need to obtain any additional cert > chain information unless it moved outside of the access network. I'd actually be loathe to put this into a specification though. There are better ways to do this. > I don't see this as any different than any other security protocol, in which > there is some time up front in which both sides don't trust each other, then > they negotiate via a procedure whereby they prove their trustworthiness. So, > in a sense, you are right that for an initial period, the router is not > known to the node to be trustworthy, but that is not much different than any > other security situation. How long it takes depends on the amount of > preconfiguration available. > > It is true that the node doesn't have the opportunity to do a CRL check > prior to accepting the signature, but this is unavoidable, since the node > does not, at that time, have a connection to the Internet. The spec says > that the node should perform certificate revocation checking as soon as > possible afterwards and terminate using the router if the check fails or > fails to complete. So there will be some period of time in which the node is > using the router but has not yet verified the revocation status of the > router's certificate. I agree. There's a tradeoff between preconfiguration, speed and trust which may come up. Describing some of these issues may be relevant to do in DNA, though. >>The rules in section 8 are sound and don't leave holes in the case >>that a host moves for non-SEND routers, although it looks >>like this implies the standard reachability testing from ND (NUD). >> > > > The SEND spec is not concerned with the basic discovery procedure of 2461. > In that sense, it is different from DNA. > > >>The second last dot point indicates that we should select >>reachable SEND routers over reachable non-SEND routers (and >>there are similar explanations for ND). This is the trigger >>to switch on SEND for Router Discovery. >> > > > Essentially, yes. > > >>I'd guess that this implies that we want reachable non-SEND >>routers over unreachable SEND routers. >>This may be the switch-off for SEND, but may have to be >>specified. >> > > > Doesn't this cover it: > > o The conceptual sending algorithm is modified so that an insecure > router is selected only if there is no reachable SEND router for > the prefix. That is, the algorithm for selecting a default router > favors reachable SEND routers over reachable non-SEND ones. I think it does, but there the duration to determine unreachability is a lot longer than to determine reachability (for example if we move subnets). In this case, we may have received messages from devices purporting to be routers well before we time-out on our NUD tests. Alternatively, if there was some extra information in a router advertisement which implies the old router's unreachability (like a link identifier) then there may be an indication of unreachability which hasn't been confirmed. Indicating that there may be situations where you'd like to use the unsecured router though makes sense. I think discussions of the timing/tradeoffs are best made elsewhere. > > >>If we want to talk a bit more about SEND router/neighbour >>reachability, it may be possible to keep some reachability >>state for a SEND router until we've checked that it isn't >>in fact reachable, but allow usage of a non-SEND router in >>the case we have other reliable information which can be used >>for change detection (This is starting to sound a little >>like DNA though). >>For example this could be our own link-layer telling us about >>arrival on a new LAN segment. >> >>The current non-SEND to SEND transition case needs some checks, >>since a signed CGA addressed router advertisement may take >>routing away from a legitimate non-SEND router, without using >>any authorization information. This is worse than the current state >>since it occurs without NUD checks for the current router. >> >>Perhaps this is one strategy: >> >>?? >> >>A host MAY treat unauthorized SEND routers as insecure, >>but allow temporary adoption of insecure routers >>(including non-SEND routers) while authorization >>is being checked. This SHOULD only be done if >>the host believes there may have been a link or L2 change. >>This aims to prevent overriding a good SEND config >>with an unsecured one. >> >>Checking authorization in this case is the determination >>of delegation information for SEND, or the unreachability >>of the currently configured router (whichever >>is determined sooner). >> >>This may cause a temporary state change of state >>such as: >> >>1) default router configuration >> >>2) neighbour cache state for the configured router >> >>Packets sent to these unsecured routers may be lost or subverted >>to other addresses or used for man-in-the-middle attacks. >> >>Care should be taken to ensure that any routing state >>changes can be rolled back in the case of current router >>indicates its reachability. >> >>In the case that the unreachability of the current router >>router is determined, such changes MAY be committed, >>and a unsecured or non-SEND router adopted as current. >> >>Otherwise, only authorized SEND router advertisements can override >>existing SEND configurations. >> > > > > How about adding this as a bullet to the list: > > o A node MAY adopt an insecure router, including a SEND > router for which full security checks have not yet been completed, > while security checking for the SEND router is underway. Security > checks in this case include delegation chain solicitation, certificate > verification, CRL checks, and RA signature checks. A node > MAY also adopt an insecure router if a SEND router > becomes unreachable, but SHOULD attempt to find a SEND > router as soon as possible, since the unreachability may be the > result of an attack. Note that accepting an insecure router > opens the node to possible attacks, and nodes that > choose to accept insecure routers do so at their own risk. The node > SHOULD in any case prefer the SEND router as soon as > a new SEND router appears and security checks are complete This looks good. > I think we should leave out the L2 change part because this might also be > useful for fixed hosts. I also don't think we need to delineate the attacks, > since they are described elsewhere. Indeed. > >>?? >> >>I'm not sure if this preserves the same security >>properties in the general case, though. >> >>In this case, we'd need two indicators (flags?): one for signed >>NC messages, and one for router authorization. >>reception of a signed NC message wouldn't be sufficient to >>override the (signed, authorized) SEND router. >> >>Currently there's only a 'Secured' flag. Which may be misleading. >> >> > > > > Where would flags be necessary? Don't worry, I was guessing that the 'secured' indication used prevuiously was just the RA signature check (which is immediately available and didn't include the authorization which isn't). Your new text block clarified that. Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Mon Mar 29 13:27:50 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16207 for ; Mon, 29 Mar 2004 13:27:49 -0500 (EST) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2TIRnAh010542 for ; Mon, 29 Mar 2004 20:27:49 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 29 Mar 2004 20:27:35 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H7N1HM5K; Mon, 29 Mar 2004 20:27:34 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2TIRXXA011148; Mon, 29 Mar 2004 20:27:33 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2TIQwIt006821; Mon, 29 Mar 2004 20:26:58 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2TIQwXx006817; Mon, 29 Mar 2004 20:26:58 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2TIQvIt006804 for ; Mon, 29 Mar 2004 20:26:57 +0200 (MET DST) Received: from [IPv6:::1] (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 2103C8; Mon, 29 Mar 2004 21:39:33 +0300 (EEST) In-Reply-To: <64A531765B7C8342BFA260497BE00457019D3C7C@RED-MSG-43.redmond.corp.microsoft.com> References: <64A531765B7C8342BFA260497BE00457019D3C7C@RED-MSG-43.redmond.corp.microsoft.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <05E98B48-819D-11D8-83AA-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: "SEND WG" From: Pekka Nikander Subject: Re: CGA Issue #7: Strengthening Section 7.4 (Ted Hardie) Date: Mon, 29 Mar 2004 18:20:41 +0200 To: "Tuomas Aura" X-Mailer: Apple Mail (2.612) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 29 Mar 2004 18:27:35.0167 (UTC) FILETIME=[81A9C0F0:01C415BB] Content-Transfer-Encoding: 7bit > I suggest the following wording: > > Finally, a strong cautionary note needs to be made about using > CGA-based authentication for other purposes than SEND. First, the > other protocols MUST include a type tag and the sender address > in all signed messages in the same way as SEND does. Each protocol > MUST define its own type tag values as explained in Section 8. > Moreover, because of the possibility of related-protocol attacks, > the public key can be used only for signing and it MUST NOT be used > for encryption. Second, CGA-based authentication is particularly > suitable for securing neighbor discovery [RFC2461] and duplicate > address detection [RFC2462] because these are network-layer > signaling protocols where IPv6 addresses are natural endpoint > identifiers. In any protocol that aims to protect higher-layer > data, CGA-based authentication alone is not sufficient and there > must also be a secure mechanism for mapping higher-layer > identifiers, > such as DNS names, to IP addresses. If the primary goal is not to > authenticate an IPv6 address, CGA-based authentication is probably > not the right solution. Looks good to me. My only question is whether the expression "to authenticate an IPv6 address" is unambiguous enough? In the past, there has been some confusion about how, exactly, does CGA provide "authentication". But perhaps this has already been discussed elsewhere in the document? --Pekka -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Mon Mar 29 13:36:20 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16692 for ; Mon, 29 Mar 2004 13:36:20 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2TIaKqY019863 for ; Mon, 29 Mar 2004 20:36:20 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 29 Mar 2004 20:27:40 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HV9SF1B7; Mon, 29 Mar 2004 20:28:07 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2TIRdXA011155; Mon, 29 Mar 2004 20:27:39 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2TIQnIt006795; Mon, 29 Mar 2004 20:26:49 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2TIQnUm006794; Mon, 29 Mar 2004 20:26:49 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2TIQmIt006790 for ; Mon, 29 Mar 2004 20:26:48 +0200 (MET DST) Received: from [IPv6:::1] (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id B2B7B8; Mon, 29 Mar 2004 21:39:23 +0300 (EEST) In-Reply-To: <64A531765B7C8342BFA260497BE00457019D3C8F@RED-MSG-43.redmond.corp.microsoft.com> References: <64A531765B7C8342BFA260497BE00457019D3C8F@RED-MSG-43.redmond.corp.microsoft.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "SEND WG" From: Pekka Nikander Subject: Re: CGA Issue #10: Generating weak random numbers (Russ Housley) Date: Mon, 29 Mar 2004 18:32:49 +0200 To: "Tuomas Aura" X-Mailer: Apple Mail (2.612) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 29 Mar 2004 18:27:40.0739 (UTC) FILETIME=[84FBF930:01C415BB] Content-Transfer-Encoding: 7bit > I suggest the following wording: > > The quality of the random number generator does not affect the > strength of the binding between the address and the public key. > Implementations that have no strong random numbers available MAY > use a non-cryptographic pseudo-random number generator that is > initialized with the current time of day. > > To Section 7.3, I would add the following: > > Advice on random number generation can be found in [RFC1750]. This looks ok to me, but Thuomas you need to get an opinion also directly from Russ, I think. But maybe you want to wait until this very lively discussion at the WG mailing list is over :-) --Pekka -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Wed Mar 31 12:52:21 2004 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04005 for ; Wed, 31 Mar 2004 12:52:19 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2VHqHYG029249 for ; Wed, 31 Mar 2004 19:52:18 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 31 Mar 2004 19:52:27 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H8F4M2F6; Wed, 31 Mar 2004 19:52:17 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2VHqAwg003070; Wed, 31 Mar 2004 19:52:10 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2VHp7It017235; Wed, 31 Mar 2004 19:51:07 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2VHp7Z7017234; Wed, 31 Mar 2004 19:51:07 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2VHp6It017230 for ; Wed, 31 Mar 2004 19:51:06 +0200 (MET DST) Received: from kolumbus.fi ([62.248.171.125]) by fep01-app.kolumbus.fi with ESMTP id <20040331175106.TOOQ4029.fep01-app.kolumbus.fi@kolumbus.fi>; Wed, 31 Mar 2004 20:51:06 +0300 Message-ID: <406B0267.7040308@kolumbus.fi> Date: Wed, 31 Mar 2004 20:39:51 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tuomas Aura CC: SEND WG Subject: Re: CGA Issue #11: Key lifetimes (Russ Housley) References: <64A531765B7C8342BFA260497BE00457019D3C92@RED-MSG-43.redmond.corp.microsoft.com> In-Reply-To: <64A531765B7C8342BFA260497BE00457019D3C92@RED-MSG-43.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 31 Mar 2004 17:52:27.0569 (UTC) FILETIME=[EE435210:01C41748] Content-Transfer-Encoding: 7bit Tuomas, I agree with the text you have provided, but what about brute force attacks on RSA keys? I seem to remember that the mandated key length is small, so perhaps with some time on their hands, an attacker could discover the private key without compromising the node. Maybe you should add something about not keeping the keys longer than you believe the keys are cryptographically safe? Or am I missing something obvious? --Jari Tuomas Aura wrote: > Russ Housley: > > The security considerations ought to say something about the lifetime > of the public/private key pair. The one brief statement in section > 7.3 > is not sufficient for an implementor to know how often the key pair > needs to be changed. > > --- > > Tuomas Aura: > > There isn't any reason for changing the keys, except if the > host is compromised and its private keys may have leaked. > > I suggest adding the following to Section 7.1: > > The impact of key compromise depends on the > application of the CGA-based signatures. In SEND, it is not a > major concern. The private signature key is typically stored > in the physical node that uses the CGA generated from the > corresponding public key. If the private key is compromised, it > is likely that the node itself has been compromised. If that is > the case, the attacker does not need to spoof SEND messages > from the node. When it is discovered that a node has > been compromised, a new signature key and a new CGA SHOULD be > generated. The address change effectively revokes the > old public key. It is not necessary to have any additional > key revocation mechanism or to limit the lifetimes of the > signature keys. -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Mar 31 12:52:24 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04030 for ; Wed, 31 Mar 2004 12:52:22 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2VHqLqY012204 for ; Wed, 31 Mar 2004 19:52:21 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 31 Mar 2004 19:52:31 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 2AA7XLDN; Wed, 31 Mar 2004 19:52:20 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2VHqJXA027999; Wed, 31 Mar 2004 19:52:19 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2VHp9It017242; Wed, 31 Mar 2004 19:51:09 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2VHp9bp017241; Wed, 31 Mar 2004 19:51:09 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2VHp8It017237 for ; Wed, 31 Mar 2004 19:51:08 +0200 (MET DST) Received: from kolumbus.fi ([62.248.171.125]) by fep01-app.kolumbus.fi with ESMTP id <20040331175108.TOOU4029.fep01-app.kolumbus.fi@kolumbus.fi>; Wed, 31 Mar 2004 20:51:08 +0300 Message-ID: <406B02D0.3020501@kolumbus.fi> Date: Wed, 31 Mar 2004 20:41:36 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tuomas Aura CC: SEND WG Subject: Re: CGA issue #12: Upgrade path for crypto algorithms (related to issue #8) References: <64A531765B7C8342BFA260497BE0045701A1C376@RED-MSG-43.redmond.corp.microsoft.com> In-Reply-To: <64A531765B7C8342BFA260497BE0045701A1C376@RED-MSG-43.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 31 Mar 2004 17:52:31.0011 (UTC) FILETIME=[F0508730:01C41748] Content-Transfer-Encoding: 7bit I think this issue is important. I'd go for option #3. I'm working on what the implications for the ndopts draft are due to this, and will get back to you as soon as I have a text suggestion... --Jari Tuomas Aura wrote: > The comment by Thomas Narten (issue #8) triggered me to > think about another issue that has been ignored so far: > upgrade path to another signature algorithm. > > My original idea was that the CGA Parameters (the input to > Hash1) would be an opaque blob of bytes. The CGA verification > algorithm would parse the recognized fields (modifier, > subnet prefix, collision count, public key) and return > the public key if the verification was successful. > The CGA verification algorithm would ignore any unrecognized > data at the and of the blob after the public key. > This would enable future versions of the specification to > add new fields to the end of the CGA Parameters. > > In particular, the CGA Parameters could include a second > public key during transition to a more secure signature > algorithm. Implementations that do not understand the > second algorithm would include the unrecognized data (the > second public key at the end of CGA Parameters) in the > hash inputs but ignore it otherwise. Implementations that > support the second signature algorithm would use the > second public key. > > Unfortunately, this idea of extendibility does not work > with the current NDOPT draft. Instead of treating the CGA > Parameters as an opaque block of bytes, as I hoped, the > NDOPT draft divides the CGA Parameters into several different > fields: Collision Cnt, Modifier and Key Information. > The advantages of this are that the packet diagrams look > prettier, and that 7 bytes are saved because the subnet prefix > need not be repeated. The disadvantage is that it is not > possible to pass unrecognized data, such as a second public > key, at the end of the CGA Parameters. Thus, the NDOPT > implementation is not upward compatible in the way I had > hoped. > > I should have noticed this issue earlier. I ignored the > issue because we decided not to include any extensions (such > as a second signature algorithm) in the current specs. > > The options are: > > (1) Forget about this. Live with the fact that it will be > impossible to extend the CGA Parameters data structure > without breaking compatibility with the first-generation > SEND implementations. (This is the easiest option but > we might regret it later if RSA or SHA needs replacing.) > > (2) Change the CGA draft so that it explicitly allows > multiple concatenated public keys in CGA Parameters. > Change the NDOPT draft accordingly. (I strongly dislike > this option because everyone will want to have their favorite > algorithms standardized, implementations will bloat, and > interoperability will break.) > > (3) Change the CGA draft so that it allows unrecognized > data at the end of the CGA Parameters, after the public key. > The unrecognized fields will be input to Hash1 and Hash2 but > will be ignored otherwise. Change the NDOPT draft by replacing > the Collision Cnt, Modifier and Key Information fields in the > CGA option with a single block of data that has the same format > as CGA Parameters in the CGA draft and that can have > unrecognized data after the public key. > > I propose using the third option because it does not over-specify > things. If we one day feel that RSA or SHA needs replacing, > we can at that time specify an extension to the CGA Parameters > format to help the transition. Moreover, it enables other > future extensions that we might not have thought about yet. > On the other hand, it does not invite people to add their > own crypto algorithms unnecessarily, which is bound to happen > if we have a well-defined process for adding them. > > Opinions? > > Tuomas > > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. > > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Mar 31 13:39:10 2004 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06682 for ; Wed, 31 Mar 2004 13:39:10 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2VIdAYG005855 for ; Wed, 31 Mar 2004 20:39:10 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 31 Mar 2004 20:39:09 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 2AA7XVGC; Wed, 31 Mar 2004 20:39:09 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2VId8XA028578; Wed, 31 Mar 2004 20:39:08 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2VIcbIt027803; Wed, 31 Mar 2004 20:38:37 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2VIcbeq027802; Wed, 31 Mar 2004 20:38:37 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2VIcaIt027790 for ; Wed, 31 Mar 2004 20:38:36 +0200 (MET DST) Received: from kolumbus.fi ([62.248.171.125]) by fep01-app.kolumbus.fi with ESMTP id <20040331183836.TYEO4029.fep01-app.kolumbus.fi@kolumbus.fi>; Wed, 31 Mar 2004 21:38:36 +0300 Message-ID: <406B0F8C.3090002@kolumbus.fi> Date: Wed, 31 Mar 2004 21:35:56 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tuomas Aura CC: SEND WG Subject: Re: CGA Issue #9: Referencing PKCS#1 (Russ Housley) References: <64A531765B7C8342BFA260497BE00457019D3C87@RED-MSG-43.redmond.corp.microsoft.com> In-Reply-To: <64A531765B7C8342BFA260497BE00457019D3C87@RED-MSG-43.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 31 Mar 2004 18:39:09.0872 (UTC) FILETIME=[7490D300:01C4174F] Content-Transfer-Encoding: 7bit Tuomas Aura wrote: > SEND SHOULD use an RSA public/private key pair. When RSA > is used, the algorithm identifier must be rsaEncryption, which > is 1.2.840.113549.1.1.1, and the RSA public key MUST be formatted > using RSAPublicKey type as specified in section 2.3.1 of RFC 3279. > > --- > Tuomas Aura: > The above text sounds good to me. Yes. Maybe s/must be/MUST be/ --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Mar 31 13:39:44 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04006 for ; Wed, 31 Mar 2004 12:52:19 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2VHqIAh024160 for ; Wed, 31 Mar 2004 19:52:18 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 31 Mar 2004 19:52:17 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 2AA7XLC7; Wed, 31 Mar 2004 19:52:17 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2VHq4wg003068; Wed, 31 Mar 2004 19:52:04 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2VHp5It017213; Wed, 31 Mar 2004 19:51:05 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2VHp5BG017212; Wed, 31 Mar 2004 19:51:05 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2VHp4It017208 for ; Wed, 31 Mar 2004 19:51:04 +0200 (MET DST) Received: from kolumbus.fi ([62.248.171.125]) by fep01-app.kolumbus.fi with ESMTP id <20040331175103.TOOG4029.fep01-app.kolumbus.fi@kolumbus.fi>; Wed, 31 Mar 2004 20:51:03 +0300 Message-ID: <406B0148.3020807@kolumbus.fi> Date: Wed, 31 Mar 2004 20:35:04 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tuomas Aura CC: SEND WG Subject: Re: CGA Issue #10: Generating weak random numbers (Russ Housley) References: <64A531765B7C8342BFA260497BE00457019D3C8F@RED-MSG-43.redmond.corp.microsoft.com> In-Reply-To: <64A531765B7C8342BFA260497BE00457019D3C8F@RED-MSG-43.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 31 Mar 2004 17:52:17.0535 (UTC) FILETIME=[E84840F0:01C41748] Content-Transfer-Encoding: 7bit Your proposal Tuomas looks good. --Jari Tuomas Aura wrote: > Russ Housley: > > In the 1st full paragraph on page 9, Section 4 says: > > > > ... The quality of the random number generator does not affect the > > strength of the binding between the address and the public key. ... > > > This kind of statement will encourage implementors to use a constant, > which is a problem. A SHA-1 hash of the time of day would be okay. > > Section 7.3 ought to reference RFC 1750. > > --- > > Tuomas Aura: > > It is true that using the time of day is much better for privacy than > using zero. It is a good idea to suggest a way fo generating weak > random numbers. > > I think using the unhashed time of day directly is just as good for > privacy as hashing it. For remote nodes that only see the CGA and not > the CGA Parameters, there is no difference because the time of day will > be hashed anyway (with the Hash1 function). For local nodes that see > the CGA Parameters, there is no real difference because they can do a > brute-force reversal of the hash by trying all different time-of-day > values. Thus, computing a SHA-1 hash of the time of day is unnecessary. > > Some implementations may, however require the initial values to be > evenly distributed to all parts of the 128-bit modifier value space > in order to avoid searching the same number twice. Therefore, some > kind of hashing is useful. > > I suggest the following wording: > > The quality of the random number generator does not affect the > strength of the binding between the address and the public key. > Implementations that have no strong random numbers available MAY > use a non-cryptographic pseudo-random number generator that is > initialized with the current time of day. > > To Section 7.3, I would add the following: > > Advice on random number generation can be found in [RFC1750]. -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Mar 31 13:44:18 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07057 for ; Wed, 31 Mar 2004 13:44:17 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2VIiIqY019618 for ; Wed, 31 Mar 2004 20:44:18 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 31 Mar 2004 20:44:17 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H8F4MVKX; Wed, 31 Mar 2004 20:44:17 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2VIiBwg005452; Wed, 31 Mar 2004 20:44:11 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2VIhxIt028626; Wed, 31 Mar 2004 20:43:59 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2VIhxmO028625; Wed, 31 Mar 2004 20:43:59 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2VIhwIt028621 for ; Wed, 31 Mar 2004 20:43:58 +0200 (MET DST) Received: from kolumbus.fi ([62.248.171.125]) by fep01-app.kolumbus.fi with ESMTP id <20040331184358.TYZU4029.fep01-app.kolumbus.fi@kolumbus.fi>; Wed, 31 Mar 2004 21:43:58 +0300 Message-ID: <406B10CE.3090403@kolumbus.fi> Date: Wed, 31 Mar 2004 21:41:18 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tuomas Aura CC: SEND WG Subject: Re: CGA Issue #7: Strengthening Section 7.4 (Ted Hardie) References: <64A531765B7C8342BFA260497BE00457019D3C7C@RED-MSG-43.redmond.corp.microsoft.com> In-Reply-To: <64A531765B7C8342BFA260497BE00457019D3C7C@RED-MSG-43.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 31 Mar 2004 18:44:17.0465 (UTC) FILETIME=[2BE7CA90:01C41750] Content-Transfer-Encoding: 7bit Tuomas Aura wrote: > Finally, a strong cautionary note needs to be made about using > CGA-based authentication for other purposes than SEND. First, the > other protocols MUST include a type tag and the sender address > in all signed messages in the same way as SEND does. Each protocol > MUST define its own type tag values as explained in Section 8. > Moreover, because of the possibility of related-protocol attacks, > the public key can be used only for signing and it MUST NOT be used > for encryption. Second, CGA-based authentication is particularly > suitable for securing neighbor discovery [RFC2461] and duplicate > address detection [RFC2462] because these are network-layer > signaling protocols where IPv6 addresses are natural endpoint > identifiers. In any protocol that aims to protect higher-layer > data, CGA-based authentication alone is not sufficient and there > must also be a secure mechanism for mapping higher-layer identifiers, > such as DNS names, to IP addresses. If the primary goal is not to > authenticate an IPv6 address, CGA-based authentication is probably > not the right solution. I basically agree with the sugggested text, with one proposed change. The CGA technique, as well as other infrastructureless techniques, is very much tied together with the semantics of the application it protects. This applies to all security mechanisms of course, but for for these techniques the linkage is very tight. Its kind of hard to give exact rules on when its applicable and when its not, however. In particular, I suspect there are cases where CGA could be used even for higher layer applications, as long as the IP address is the identifier used in that application. Also, taking "protect higher-layer data" literally would also preclude using CGAs to bootstrap IP layer encryption, which would also seem to be possible. So how about changing In any protocol that aims to protect higher-layer data, CGA-based authentication alone is not sufficient and there must also be a secure mechanism for mapping higher-layer identifiers, such as DNS names, to IP addresses. If the primary goal is not to authenticate an IPv6 address, CGA-based authentication is probably not the right solution. to In any protocol that aims to use other identifiers, CGA-based authentication alone is not sufficient to protect the application. There must also be a secure mechanism for mapping higher-layer identifiers, such as DNS names, to IP addresses. If the primary goal is not to authenticate an IPv6 address, CGA-based authentication is probably not the right solution. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Mar 31 13:59:56 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07450 for ; Wed, 31 Mar 2004 13:59:55 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2VIxuAh032416 for ; Wed, 31 Mar 2004 20:59:56 +0200 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 31 Mar 2004 21:00:11 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H8FAXASX; Wed, 31 Mar 2004 21:00:29 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2VIxtXA028885; Wed, 31 Mar 2004 20:59:55 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2VIxIIt001933; Wed, 31 Mar 2004 20:59:18 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2VIxIZN001932; Wed, 31 Mar 2004 20:59:18 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2VIxGIt001913 for ; Wed, 31 Mar 2004 20:59:16 +0200 (MET DST) Message-ID: <015301c41752$517cd870$5b6115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Jari Arkko" , "Tuomas Aura" Cc: "SEND WG" References: <64A531765B7C8342BFA260497BE00457019D3C7C@RED-MSG-43.redmond.corp.microsoft.com> <406B10CE.3090403@kolumbus.fi> Subject: Re: CGA Issue #7: Strengthening Section 7.4 (Ted Hardie) Date: Wed, 31 Mar 2004 10:59:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 31 Mar 2004 19:00:11.0702 (UTC) FILETIME=[64ACCD60:01C41752] Content-Transfer-Encoding: 7bit I agree, with the provision that CGAs don't provide authentication, they prove authorization. Hence I'd suggest the following rewording: In any protocol that aims to use other identifiers, CGA-based authorization alone is not sufficient to protect the application. There must also be a secure mechanism for mapping higher-layer identifiers, such as DNS names, to IP addresses. If the primary goal is not to deterimine the authorization to make claims about an IPv6 address, CGA-based authorization is probably not the right solution. and changing "authentication" to "authorization" in the rest of the paragraph. This still leaves open the possibility for using CGA for other applications that want to make a claim about the right to do something with an IPv6 address (provided the IPR issue is solved), for example, a claim to be able to change the routing that might be part of a Mobile IPv6 BU security mechanism for route optimization. jak ----- Original Message ----- From: "Jari Arkko" To: "Tuomas Aura" Cc: "SEND WG" Sent: Wednesday, March 31, 2004 10:41 AM Subject: Re: CGA Issue #7: Strengthening Section 7.4 (Ted Hardie) > Tuomas Aura wrote: > > > Finally, a strong cautionary note needs to be made about using > > CGA-based authentication for other purposes than SEND. First, the > > other protocols MUST include a type tag and the sender address > > in all signed messages in the same way as SEND does. Each protocol > > MUST define its own type tag values as explained in Section 8. > > Moreover, because of the possibility of related-protocol attacks, > > the public key can be used only for signing and it MUST NOT be used > > for encryption. Second, CGA-based authentication is particularly > > suitable for securing neighbor discovery [RFC2461] and duplicate > > address detection [RFC2462] because these are network-layer > > signaling protocols where IPv6 addresses are natural endpoint > > identifiers. In any protocol that aims to protect higher-layer > > data, CGA-based authentication alone is not sufficient and there > > must also be a secure mechanism for mapping higher-layer identifiers, > > such as DNS names, to IP addresses. If the primary goal is not to > > authenticate an IPv6 address, CGA-based authentication is probably > > not the right solution. > > I basically agree with the sugggested text, with one > proposed change. > > The CGA technique, as well as other infrastructureless > techniques, is very much tied together with the semantics > of the application it protects. This applies to all > security mechanisms of course, but for for these techniques > the linkage is very tight. Its kind of hard to give > exact rules on when its applicable and when its not, > however. In particular, I suspect there are cases > where CGA could be used even for higher layer applications, > as long as the IP address is the identifier used in > that application. Also, taking "protect higher-layer > data" literally would also preclude using CGAs to > bootstrap IP layer encryption, which would also seem > to be possible. So how about changing > > In any protocol that aims to protect higher-layer > data, CGA-based authentication alone is not sufficient and there > must also be a secure mechanism for mapping higher-layer identifiers, > such as DNS names, to IP addresses. If the primary goal is not to > authenticate an IPv6 address, CGA-based authentication is probably > not the right solution. > > to > > In any protocol that aims to use other identifiers, > CGA-based authentication alone is not sufficient to protect > the application. There must also be a secure mechanism for > mapping higher-layer identifiers, such as DNS names, to > IP addresses. If the primary goal is not to authenticate > an IPv6 address, CGA-based authentication is probably > not the right solution. > > --Jari > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Mar 31 14:42:50 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08782 for ; Wed, 31 Mar 2004 14:42:49 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2VJgoqY028054 for ; Wed, 31 Mar 2004 21:42:50 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 31 Mar 2004 21:42:53 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 2AA7YFB9; Wed, 31 Mar 2004 21:42:49 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i2VJgjwg008411; Wed, 31 Mar 2004 21:42:45 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2VJgCIt011263; Wed, 31 Mar 2004 21:42:12 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i2VJgCAE011262; Wed, 31 Mar 2004 21:42:12 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i2VJgBIt011257 for ; Wed, 31 Mar 2004 21:42:11 +0200 (MET DST) Received: from kolumbus.fi ([62.248.171.125]) by fep01-app.kolumbus.fi with ESMTP id <20040331194210.UJLZ4029.fep01-app.kolumbus.fi@kolumbus.fi>; Wed, 31 Mar 2004 22:42:10 +0300 Message-ID: <406B1E72.2090505@kolumbus.fi> Date: Wed, 31 Mar 2004 22:39:30 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: Tuomas Aura , SEND WG Subject: Re: CGA Issue #7: Strengthening Section 7.4 (Ted Hardie) References: <64A531765B7C8342BFA260497BE00457019D3C7C@RED-MSG-43.redmond.corp.microsoft.com> <406B10CE.3090403@kolumbus.fi> <015301c41752$517cd870$5b6115ac@dcml.docomolabsusa.com> In-Reply-To: <015301c41752$517cd870$5b6115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 31 Mar 2004 19:42:53.0191 (UTC) FILETIME=[5B710170:01C41758] Content-Transfer-Encoding: 7bit Ok. James Kempf wrote: > I agree, with the provision that CGAs don't provide authentication, they > prove authorization. Hence I'd suggest the following rewording: > > In any protocol that aims to use other identifiers, > CGA-based authorization alone is not sufficient to protect > the application. There must also be a secure mechanism for > mapping higher-layer identifiers, such as DNS names, to > IP addresses. If the primary goal is not to deterimine the > authorization to make claims about an IPv6 address, CGA-based > authorization is probably not the right solution. > > and changing "authentication" to "authorization" in the rest of the > paragraph. > > This still leaves open the possibility for using CGA for other applications > that want to make a claim about the right to do something with an IPv6 > address (provided the IPR issue is solved), for example, a claim to be able > to change the routing that might be part of a Mobile IPv6 BU security > mechanism for route optimization. > > jak > > > ----- Original Message ----- > From: "Jari Arkko" > To: "Tuomas Aura" > Cc: "SEND WG" > Sent: Wednesday, March 31, 2004 10:41 AM > Subject: Re: CGA Issue #7: Strengthening Section 7.4 (Ted Hardie) > > > >>Tuomas Aura wrote: >> >> >>> Finally, a strong cautionary note needs to be made about using >>> CGA-based authentication for other purposes than SEND. First, the >>> other protocols MUST include a type tag and the sender address >>> in all signed messages in the same way as SEND does. Each protocol >>> MUST define its own type tag values as explained in Section 8. >>> Moreover, because of the possibility of related-protocol attacks, >>> the public key can be used only for signing and it MUST NOT be used >>> for encryption. Second, CGA-based authentication is particularly >>> suitable for securing neighbor discovery [RFC2461] and duplicate >>> address detection [RFC2462] because these are network-layer >>> signaling protocols where IPv6 addresses are natural endpoint >>> identifiers. In any protocol that aims to protect higher-layer >>> data, CGA-based authentication alone is not sufficient and there >>> must also be a secure mechanism for mapping higher-layer identifiers, >>> such as DNS names, to IP addresses. If the primary goal is not to >>> authenticate an IPv6 address, CGA-based authentication is probably >>> not the right solution. >> >>I basically agree with the sugggested text, with one >>proposed change. >> >>The CGA technique, as well as other infrastructureless >>techniques, is very much tied together with the semantics >>of the application it protects. This applies to all >>security mechanisms of course, but for for these techniques >>the linkage is very tight. Its kind of hard to give >>exact rules on when its applicable and when its not, >>however. In particular, I suspect there are cases >>where CGA could be used even for higher layer applications, >>as long as the IP address is the identifier used in >>that application. Also, taking "protect higher-layer >>data" literally would also preclude using CGAs to >>bootstrap IP layer encryption, which would also seem >>to be possible. So how about changing >> >> In any protocol that aims to protect higher-layer >> data, CGA-based authentication alone is not sufficient and there >> must also be a secure mechanism for mapping higher-layer identifiers, >> such as DNS names, to IP addresses. If the primary goal is not to >> authenticate an IPv6 address, CGA-based authentication is probably >> not the right solution. >> >>to >> >> In any protocol that aims to use other identifiers, >> CGA-based authentication alone is not sufficient to protect >> the application. There must also be a secure mechanism for >> mapping higher-layer identifiers, such as DNS names, to >> IP addresses. If the primary goal is not to authenticate >> an IPv6 address, CGA-based authentication is probably >> not the right solution. >> >>--Jari >> >>-------------------------------------------------------------------- >>To unsubscribe from this list, send email with "UNSUBSCRIBE" in the >>body to . >>Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html >>-------------------------------------------------------------------- > > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html --------------------------------------------------------------------