From jari.arkko@lmf.ericsson.se Sun Nov 2 20:34:35 2003 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 UAA02664 for ; Sun, 2 Nov 2003 20:34:34 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hA31VpSs000794; Mon, 3 Nov 2003 02:31:51 +0100 (MET) 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 V63CLSBH; Mon, 3 Nov 2003 02:32:04 +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 hA31VoXA016864; Mon, 3 Nov 2003 02:31: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 hA31UcB5000274; Mon, 3 Nov 2003 02:30:38 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hA31UcSQ000270; Mon, 3 Nov 2003 02:30:38 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id hA31UZB5000249 for ; Mon, 3 Nov 2003 02:30:36 +0100 (MET) Received: (qmail 26791 invoked from network); 3 Nov 2003 01:30:33 -0000 Received: from unknown (HELO [192.168.2.2]) ([66.93.135.225]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 3 Nov 2003 01:30:33 -0000 In-Reply-To: <3FA13D72.9060401@kolumbus.fi> References: <3FA13D72.9060401@kolumbus.fi> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <50B8178A-0D9D-11D8-941B-0003930D291E@speakeasy.net> Content-Transfer-Encoding: 7bit Cc: SEND WG From: Jonathan Wood Subject: Re: DCS and DCA semantics Date: Sun, 2 Nov 2003 17:30:32 -0800 To: Jari Arkko X-Mailer: Apple Mail (2.606) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit On Oct 30, 2003, at 8:33 AM, Jari Arkko wrote: > Jonathan Wood wrote: <...> >> All these will happen naturally as a consequence of a RS/RA exchange, >> if the host cannot form a delegation chain for the RA. So I think the >> text >> quoted above could be replaced with just the last item: >> o A Router Advertisement has been received with a public key that >> is >> not stored in the hosts' cache of certificates, or there is no >> authorization delegation chain to the host's trust anchor. > > Hmm... this sounds very good actually. It even covers the case when the > router's key is re-configured but everything else stays the same. > > Just one check: you are replacing just the items, and keeping the > rate limiting? I think we need that. Perhaps this could be the final > text: > > The host has a need to retrieve a delegation chain when a > Router Advertisement has been received with a public key that is > not stored in the hosts' cache of certificates, or there is no > authorization delegation chain to the host's trust anchor. In these > situations, the host MAY transmit up to MAX_DCS_MESSAGES > Delegation Chain Solicitation messages, each separated by at least > DCS_INTERVAL seconds. > > (And MAX_DCS_MESSAGES would be defined similarly to > MAX_RTR_SOLICITATIONS, > and DCS_INTERVAL similarly for RTR_SOLICITATION_INTERVAL) Yes, I agree that we still need rate limiting. I think your text should cover it. > >> The following should also be changed: >> Delegation Chain Solicitations SHOULD be rate limited and timed >> similarly with Router Solicitations, as specified in RFC 2461 [6]. >> to perhaps just some text about rate limiting (if even that is >> necessary...) > > Ah, you thought about this too. Well, I think the host should > be able to send multiple messages if there's packet loss, but > not too often. Maybe the text that I provided above works. Yes. > >> Section 6.6 says >> Routers MAY send unsolicited Delegation Chain Advertisements for >> their configured trust anchor(s). When such advertisements are >> sent, >> their timing MUST follow the rules given for Router Advertisements >> in >> RFC 2461 [6]. >> Periodic, unsolicited DCAs, however, do not serve the same purpose as >> unsolicited RAs. Usually hosts that care about the certificates in a >> DCA will >> have already retrieved them as a consequence of receiving an RA, or >> they won't care about them at all. The only case I can think of where >> unsolicited >> DCAs could be useful is if they contain proxied certificates for >> routers on >> other links (in which case hosts would not be able to discovery them >> by >> receiving RAs). So if I'm not missing something, I propose that the >> wording >> be changed to make this explicit, i.e. > > Routers are allowed to send the DCAs to the specific node (or its > solicited-node > address to be more exact). A periodic DCA to the all-nodes address > might > be received by all hosts. OTOH, the routers are also allowed to the > send the > solicited DCAs to the all-nodes address. This depends on what the > source > of the DCS was. If there's multiple nodes coming to the link at the > same > time, they probably don't have an address yet, and the DCA goes to all > then... maybe you are right and we don't need periodic DCAs. > >> Routers MAY send unsolicited Delegation Chain Advertisements for >> other >> routers that hosts may encounter on other links. Routers should not >> otherwise send unsolicited Delegation Chain Advertisements. > > Hmm... there might be other means of receiving information from the > other links. I wonder if we need a SEND specific scheme here. Delete > periodic DCA completely? Yes, I think it probably should be removed completely. > >> I'm not sure I agree with the timing rules either - some randomization >> as per RFC 2461 is probably a good thing, but we don't need to >> inherit the complexity involved with sending adverts more frequently >> on startup. >> Regarding DCA rate limiting, RFC 2461 only mandates rate limiting >> for RAs sent to the all-nodes multicast group. DCAs (as currently >> specified) are only sent to all-nodes if unsolicited (in which case >> rate >> limiting is moot) or the DCS has an unspecified address (which is >> probably not common). So the rate-limiting rule mostly misses the >> mark. > > Ok. > >> In fact, one scenario where it would be useful is when a router first >> comes up. It will multicast an RA, which will likely cause all hosts >> to send DCSs, which will in turn cause the router to multicast (to the >> solicited-node MC address) a storm of DCAs. Since the rate limiting >> only covers all-nodes MC, it will not prevent this (and if it did, >> many >> nodes would not be able to process the RA). To handle this sort of >> situation, I propose all multicast DCAs be rate limited and monitored. >> If a router finds that it is responding to a DCS too soon after one >> has >> just been sent, it should set the DCA's ID to 0 and multicast it to >> the >> all-nodes group. This should ensure both that the network is not >> flooded with DCAs and that all nodes receive the DCA. > > Sounds good. Essentially, we'd be allowing the router to respond to > the all-nodes address at its discretion. Right. This is another reason to strike periodic DCA from the spec. Jon > > --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 Mon Nov 3 21:14:21 2003 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 VAA09109 for ; Mon, 3 Nov 2003 21:14:20 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9V2RxI2028505; Fri, 31 Oct 2003 03:27:59 +0100 (MET) 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 V6NLNPVZ; Fri, 31 Oct 2003 03:27:58 +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 h9V2RvXA017766; Fri, 31 Oct 2003 03:27:57 +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 h9V2RAB5011618; Fri, 31 Oct 2003 03:27:10 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9V2R9tS011617; Fri, 31 Oct 2003 03:27:09 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9V2R7B5011601 for ; Fri, 31 Oct 2003 03:27:08 +0100 (MET) Received: from localhost ([130.194.13.83]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01L2HARGL8T68ZOPF3@vaxc.its.monash.edu.au> for ietf-send@standards.ericsson.net; Fri, 31 Oct 2003 13:26:47 +1100 Received: from splat.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id E4B2223C005; Fri, 31 Oct 2003 13:26:44 +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 C7188164007; Fri, 31 Oct 2003 13:26:44 +1100 (EST) Date: Fri, 31 Oct 2003 13:26:44 +1100 From: Greg Daley Subject: Re: New issue?: The scope of source address for DCS? To: Jari Arkko Cc: Pekka Nikander , SEND WG Reply-to: greg.daley@eng.monash.edu.au Message-id: <3FA1C864.4070106@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <3F8A5221.1040902@ericsson.com> <3FA13FAC.5000107@kolumbus.fi> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7BIT Hi Jari, Jari Arkko wrote: > Pekka Nikander wrote: > >> Folks, >> >> With regard to the DCS source address, the current spec says >> the following: >> >> An IP address assigned to the sending interface, or the >> unspecified address if no address is assigned to the sending >> interface. >> >> Should we be more specific, and say that the source address SHOULD >> be the link local address? Right now I don't see any specific >> reason, other than the old saying of being conservative when >> sending and liberal when receiving. > > > In issue 21 we agreed that DCA source should be link-local. > It seems logical to require the same from DCS? This is a holdover from RFC-2461 where the RS has as source any address on the host's interface, and the RA is only link-local. The original motivation may indeed be as Pekka mentioned. I'm not fussed now about where we the group goes with this, but I guess that the same issues which affect RS/RA will affect DCS/DCA. I'm currently concerned with RS/DCS messages coming from an address which is not on an adjacent link. I don't know how this is handled in the case where RS's are sent from a global address today (rfc-2461 doesn't seem to specify this). Should we even listen to such DCS's? I'm pretty certain that we don't want to create erroneous NC state on the router in this case, so unicast responses are out. Greg -------------------------------------------------------------------- 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 Tue Nov 4 02:17:39 2003 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 CAA01191 for ; Tue, 4 Nov 2003 02:17:38 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9VBYKI2026383; Fri, 31 Oct 2003 12:34:20 +0100 (MET) 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 V63BJQHN; Fri, 31 Oct 2003 12:34:26 +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 h9VBYJXA022861; Fri, 31 Oct 2003 12:34:19 +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 h9VBXRB5028779; Fri, 31 Oct 2003 12:33:27 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9VBXRPr028778; Fri, 31 Oct 2003 12:33:27 +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 h9VBXPB5028774 for ; Fri, 31 Oct 2003 12:33:26 +0100 (MET) Message-ID: <019e01c39fa2$d2f1b4c0$1d6015ac@dclkempt40> From: "James Kempf" To: Cc: "Kempf" , "Pekka Nikander" Subject: Volunteers for Taking Minutes Date: Fri, 31 Oct 2003 03:33:35 -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 Content-Transfer-Encoding: 7bit The IESG has requested that WG chairs make a stronger effort to get accurate minutes of IETF meetings. So, we would like to have a couple of volunteers to take minutes at the SEND WG meeting in Minneapolis. Please reply to either me or Pekka. jak -------------------------------------------------------------------- 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 Thu Nov 6 15:42:51 2003 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 PAA29738 for ; Thu, 6 Nov 2003 15:42:50 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hA6Ke8I2026262; Thu, 6 Nov 2003 21:40:08 +0100 (MET) 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 V6NNNMDT; Thu, 6 Nov 2003 21:40: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 hA6Ke0wg016778; Thu, 6 Nov 2003 21:40:01 +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 hA6Kd8B5027000; Thu, 6 Nov 2003 21:39:08 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hA6Kd8us026999; Thu, 6 Nov 2003 21:39:08 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id hA6Kd6B5026995 for ; Thu, 6 Nov 2003 21:39:07 +0100 (MET) Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 Nov 2003 12:41:26 -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); Thu, 6 Nov 2003 12:38:52 -0800 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 06 Nov 2003 12:38:53 -0800 Received: from RED-MSG-43.redmond.corp.microsoft.com ([157.54.12.204]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 Nov 2003 12:39:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: Changing back: Signature inconsistency between the CGA and NDOPTs drafts Date: Thu, 6 Nov 2003 12:39:03 -0800 Message-ID: <64A531765B7C8342BFA260497BE00457508C7D@RED-MSG-43.redmond.corp.microsoft.com> Thread-Topic: Changing back: Signature inconsistency between the CGA and NDOPTs drafts thread-index: AcORYEEo/sPM7eRYQJSK42r0uVAxDwTREqXw From: "Tuomas Aura" To: X-OriginalArrivalTime: 06 Nov 2003 20:39:00.0368 (UTC) FILETIME=[021FF100:01C3A4A6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id hA6Kd7B5026996 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Pasi Eronen just pointed out to me that the name of the algorith is RSASSA-PKCS1-v1_5 (not -v2_1), even though the document PKCS#1 version is 2.1. Thus, the previous CGA draft was correct and the change I made to the latest version is wrong. Also, the NDOPT draft needs to be changed. (Of course, I should have spotted this rather blindly making the change.) Thanks to Pasi for the careful review. He also checked that the example in the CGA draft is correct. Tuomas > -----Original Message----- > From: owner-ietf-send@standards.ericsson.net [mailto:owner-ietf- > send@standards.ericsson.net] On Behalf Of jari.arkko@kolumbus.fi > Sent: 13 October 2003 08:59 > To: pekka.nikander@nomadiclab.com > Cc: ietf-send@standards.ericsson.net > Subject: Re: New Issue: Signature inconsistency between the CGA and NDOPTs > drafts > > > These seem to be in conflict. Which one is the right one, 1.5 or 2.1? > > 2.1. This issue was raised earlier by Pasi Eronen and Valtteri > Niemi, registered as issue #9. They were right, I think. I > edited a fix for this issue in an intermediate draft version, > which you have. So it looks like the CGA draft needs to be > changed in this respect. > > --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 Sun Nov 9 17:02:29 2003 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 RAA12159 for ; Sun, 9 Nov 2003 17:02:28 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hA9LxEI2027427; Sun, 9 Nov 2003 22:59:14 +0100 (MET) 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 V6N3DAF3; Sun, 9 Nov 2003 22:59:13 +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 hA9Lx0XA004297; Sun, 9 Nov 2003 22:59:04 +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 hA9LqAB5029557; Sun, 9 Nov 2003 22:52:10 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hA9LqADB029556; Sun, 9 Nov 2003 22:52:10 +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 hA9Lq8B5029533 for ; Sun, 9 Nov 2003 22:52:09 +0100 (MET) Received: from ocean.jinmei.org (unknown [2001:468:19ff:80:aca9:d200:4607:d4ec]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 5B7C61521A; Mon, 10 Nov 2003 06:52:05 +0900 (JST) Date: Mon, 10 Nov 2003 06:52:05 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: pekka.nikander@nomadiclab.com, kempf@docomolabs-usa.com, erik.nordmark@sun.com Cc: ietf-send@standards.ericsson.net Subject: a question about send-psreq-04 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 Hello, I have a quick question about draft-ietf-send-psreq-04. Section 4.1.1 (4.1.1 Neighbor Solicitation/Advertisement Spoofing) mentions Duplicate Address Detection as follows: 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. (BTW: there is a typo: Soliciations should be Solicitation in the first sentence) The description per se is not wrong, but I don't understand how this is related to the story described in this section. In my understanding, the main point of the attack in this section is a DoS/Redirect attack by sending an ND message with a forged link-layer address option. In that sense, it should basically apply to all kinds of neighbor solicitation. Perhaps this bullet tries to show an exception to this attack, but if so, I don't understand why this is listed with the 1st bullet (the router solicitation case) where the attack can be applied. Could someone clarify this point? Thanks, 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 -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Nov 9 18:16:11 2003 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 SAA18270 for ; Sun, 9 Nov 2003 18:16:10 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hA9NDASs002385; Mon, 10 Nov 2003 00:13:10 +0100 (MET) 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 V6MKT9JT; Mon, 10 Nov 2003 00:13:10 +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 hA9ND8XA004544; Mon, 10 Nov 2003 00:13: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 hA9N73B5017186; Mon, 10 Nov 2003 00:07:03 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hA9N73Fp017185; Mon, 10 Nov 2003 00:07:03 +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 hA9N72B5017180 for ; Mon, 10 Nov 2003 00:07:02 +0100 (MET) Received: from ocean.jinmei.org (unknown [2001:468:19ff:80:aca9:d200:4607:d4ec]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id E96171521A; Mon, 10 Nov 2003 08:06:59 +0900 (JST) Date: Mon, 10 Nov 2003 08:06:59 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: pekka.nikander@nomadiclab.com, kempf@docomolabs-usa.com, erik.nordmark@sun.com Cc: ietf-send@standards.ericsson.net Subject: Re: a question about send-psreq-04 In-Reply-To: References: 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 Oops, sorry, I was a bit careless when I typed the previous message. >>>>> On Mon, 10 Nov 2003 06:52:05 +0900, >>>>> JINMEI Tatuya said: > 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. > (BTW: there is a typo: Soliciations should be Solicitation in the > first sentence) I meant "Soliciations should be Solicitations in the first sentence" 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 -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Nov 10 20:22:19 2003 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 UAA27359 for ; Mon, 10 Nov 2003 20:22:18 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAB1JDSs020053; Tue, 11 Nov 2003 02:19:13 +0100 (MET) 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 V6MLHQLA; Tue, 11 Nov 2003 02:19:12 +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 hAB1JCXA023178; Tue, 11 Nov 2003 02:19:12 +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 hAB1GpB5010076; Tue, 11 Nov 2003 02:16:51 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hAB1GpSe010075; Tue, 11 Nov 2003 02:16:51 +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 hAB1GnB5010059 for ; Tue, 11 Nov 2003 02:16:49 +0100 (MET) Message-ID: <07a101c3a7f1$8543dd00$b36015ac@dclkempt40> From: "James Kempf" To: "Pekka Nikander" , "Erik Nordmark" Cc: References: Subject: Re: a question about send-psreq-04 Date: Mon, 10 Nov 2003 17:16:58 -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 Content-Transfer-Encoding: 7bit > I have a quick question about draft-ietf-send-psreq-04. > > Section 4.1.1 (4.1.1 Neighbor Solicitation/Advertisement Spoofing) > mentions Duplicate Address Detection as follows: > > 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. > > (BTW: there is a typo: Soliciations should be Solicitation in the > first sentence) > > The description per se is not wrong, but I don't understand how this > is related to the story described in this section. > > In my understanding, the main point of the attack in this section is a > DoS/Redirect attack by sending an ND message with a forged link-layer > address option. In that sense, it should basically apply to all kinds > of neighbor solicitation. > Section 4.1.1 is about attacks that involve spoofing an address when a node would create a Neighbor Cache entry. jak > Perhaps this bullet tries to show an exception to this attack, but if > so, I don't understand why this is listed with the 1st bullet (the > router solicitation case) where the attack can be applied. > > Could someone clarify this point? > > Thanks, > > 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 -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Nov 10 22:22:48 2003 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 WAA02221 for ; Mon, 10 Nov 2003 22:22:48 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAB3KwSs010096; Tue, 11 Nov 2003 04:20:58 +0100 (MET) 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 V6N3QJ3V; Tue, 11 Nov 2003 04:20:57 +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 hAB3Kowg026798; Tue, 11 Nov 2003 04:20: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 hAB3HGB5014122; Tue, 11 Nov 2003 04:17:16 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hAB3HGjK014121; Tue, 11 Nov 2003 04:17:16 +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 hAB3HEB5014117 for ; Tue, 11 Nov 2003 04:17:15 +0100 (MET) Received: from ocean.jinmei.org (unknown [2001:468:19ff:80:928:bd54:9353:fa2]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 28A281521B; Tue, 11 Nov 2003 12:17:11 +0900 (JST) Date: Tue, 11 Nov 2003 12:17:10 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "James Kempf" Cc: "Pekka Nikander" , "Erik Nordmark" , Subject: Re: a question about send-psreq-04 In-Reply-To: <07a101c3a7f1$8543dd00$b36015ac@dclkempt40> References: <07a101c3a7f1$8543dd00$b36015ac@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 >>>>> On Mon, 10 Nov 2003 17:16:58 -0800, >>>>> "James Kempf" said: >> I have a quick question about draft-ietf-send-psreq-04. >> >> Section 4.1.1 (4.1.1 Neighbor Solicitation/Advertisement Spoofing) >> mentions Duplicate Address Detection as follows: >> >> 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. >> The description per se is not wrong, but I don't understand how this >> is related to the story described in this section. >> >> In my understanding, the main point of the attack in this section is a >> DoS/Redirect attack by sending an ND message with a forged link-layer >> address option. In that sense, it should basically apply to all kinds >> of neighbor solicitation. > Section 4.1.1 is about attacks that involve spoofing an address when a node > would create a Neighbor Cache entry. Okay, but my main point still applies. There should be nothing special in the DAD case in terms of the attacks; other "normal" neighbor solicitations for link-layer address resolution would also cause the creation of a neighbor cache entry. So, why the 2nd bullet of Section 4.1.1 exists? 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 -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Nov 10 22:39:41 2003 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 WAA03015 for ; Mon, 10 Nov 2003 22:39:40 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAB3cASs013186; Tue, 11 Nov 2003 04:38:10 +0100 (MET) 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 V6MLJHH0; Tue, 11 Nov 2003 04:38:09 +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 hAB3c0wg027176; Tue, 11 Nov 2003 04:38: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 hAB3YHB5017902; Tue, 11 Nov 2003 04:34:17 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hAB3YHAX017901; Tue, 11 Nov 2003 04:34: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 hAB3YEB5017894 for ; Tue, 11 Nov 2003 04:34:15 +0100 (MET) Message-ID: <087801c3a804$b579f4b0$b36015ac@dclkempt40> From: "James Kempf" Cc: "Pekka Nikander" , "Erik Nordmark" , References: <07a101c3a7f1$8543dd00$b36015ac@dclkempt40> Subject: Re: a question about send-psreq-04 Date: Mon, 10 Nov 2003 19:34:25 -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 Content-Transfer-Encoding: 8bit Like I said, this section deals with cases where the node creates a NC entry. There are two such cases, thus there are two bullets. jak ----- Original Message ----- From: )> To: "James Kempf" Cc: "Pekka Nikander" ; "Erik Nordmark" ; Sent: Monday, November 10, 2003 7:17 PM Subject: Re: a question about send-psreq-04 > >>>>> On Mon, 10 Nov 2003 17:16:58 -0800, > >>>>> "James Kempf" said: > > >> I have a quick question about draft-ietf-send-psreq-04. > >> > >> Section 4.1.1 (4.1.1 Neighbor Solicitation/Advertisement Spoofing) > >> mentions Duplicate Address Detection as follows: > >> > >> 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. > > >> The description per se is not wrong, but I don't understand how this > >> is related to the story described in this section. > >> > >> In my understanding, the main point of the attack in this section is a > >> DoS/Redirect attack by sending an ND message with a forged link-layer > >> address option. In that sense, it should basically apply to all kinds > >> of neighbor solicitation. > > > Section 4.1.1 is about attacks that involve spoofing an address when a node > > would create a Neighbor Cache entry. > > Okay, but my main point still applies. There should be nothing > special in the DAD case in terms of the attacks; other "normal" > neighbor solicitations for link-layer address resolution would also > cause the creation of a neighbor cache entry. So, why the 2nd bullet > of Section 4.1.1 exists? > > 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 -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Nov 11 16:05:19 2003 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 QAA22058 for ; Tue, 11 Nov 2003 16:05:18 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hABL0FI2028805; Tue, 11 Nov 2003 22:00:15 +0100 (MET) 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 V6MLXCKW; Tue, 11 Nov 2003 22:00:15 +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 hABL0EXA003685; Tue, 11 Nov 2003 22:00:14 +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 hABKw2B5023724; Tue, 11 Nov 2003 21:58:02 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hABKw2eC023723; Tue, 11 Nov 2003 21:58:02 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep21-app.kolumbus.fi (fep21-0.kolumbus.fi [193.229.0.48]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id hABKw1B5023716 for ; Tue, 11 Nov 2003 21:58:01 +0100 (MET) Received: from mta.imail.kolumbus.fi ([193.229.5.109]) by fep21-app.kolumbus.fi with ESMTP id <20031111205801.FGSR23234.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi>; Tue, 11 Nov 2003 22:58:01 +0200 X-Mailer: Openwave WebEngine, version 2.8.10 (webedge20-101-191-20030113) From: To: CC: Subject: (fwd) Review of send-ndopt by Pasi Eronen (thanks Pasi!) Date: Tue, 11 Nov 2003 22:58:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20031111205801.FGSR23234.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit ------------ Hi, Please find below some comments about draft-ietf-send-ndopt-00. o This is a reasonably complex draft; if you have any ideas how to simplify the text, please do implement them :-) One possibility would be to reorder sections 5-8 as 7,8,5,6 (but I'm not 100% sure whether this would make it easier to read or not). o There quite a lot of redundant text, since the same requirements are stated several times (and it's difficult to see that they always match completely). For instance, the requirement that solicitations must include a Nonce option is stated a total of five (!) times with a MUST/REQUIRED keyword, and mentioned a couple of times without RFC2119 keywords. o It seems that the intent of Sections 7 and 8 would be to describe changes to the RFC2461/2462 processing model, but they don't actually contain all the changes (e.g. when receiving a solicitation with bogus timestamp, reply to the message but don't update caches). o Section 5.1 seems to suggest that other options than CGA, Nonce, or Timestamp could be placed after the Signature option; however, Section 5.3.1 says the Signature option MUST be the last option. Perhaps 5.1 should be clarified? o Section 5.2: The Modifier field is 16 bits (2 octets), but in draft-ietf-send-cga-02, the modifier is 16 octets (128 bits)? o Section 5.4.2.2: The timestamp should also have some fuzz factor taking the typical resolution of timestamps (e.g., 1 second) into account. Otherwise we get a situation like this: (Let's assume that both hosts have perfectly synchronized and accurate clocks, timestamp resolution is 1 second, and transmission delay is 100 ms.) 10.100 Sender sends a message, with Timestamp value 10 10.200 Packet is received (RDnew=10, TSnew=10). This is a new message, so we store RDlast=10, TSlast=10. 11.950 Sender sends another message, with Timestamp value 11 12.050 Packet is received (RDnew=12, TSnew=11). This is a known peer, so we compare 11 > 10 + (12-10)*(1-0.01). Unfortunately, this fails! o Section 6.5.1: "The parent certificates in the certificate chain MUST contain one or more X.509 IP address extensions, back up to the delegating authority (the Regional Address Registry or IANA) that delegated the original IP address space block." I think it's much more likely that the trust anchor is something below, like ISP or company IT administrator. o Section 6.5.1: It's not 100% clear whether the certificate chain sent should also contain the CA certificate (in most protocols, it's not sent since the client is assumed to have it already). o Section 8.1.2: the last paragraph should be probably deleted, because I guess we don't usually use trust anchor authorization for router _solicitations_? o Section 9 says that "Unsolicited Neighbor and Router Advertisements sent by a SEND router MUST be secured.". I guess the text about unsolicited NAs applies also to non-router SEND nodes? o Section 11.2.1: Should this section also mention the case when cache entries are created as a side effect of non-DAD Neighbor Solicitation, or when cache entries are updated as a result of unsolicited Neighbor Advertisement? (BTW, I have a feeling that some parts of the document don't take unsolicited NAs into account) Editorial nits: o Section 2: Should have reference to RFC2119 (keywords) o Section 3: s/preformed/performed/ o Section 4: "To secure the various functions, a set of new Neighbor Discovery options introduced." -> "...options is introduced." o Section 5.3: The name of the algorithm is "RSASSA-PKCS1-v1_5", not "RSASSA-PKCS1-v2_1". o Section 5.3.2: s/TheDigital/The Digital/ o Section 5.3.2: s/preceeding/preceding/ o Section 5.4.2.2: s/dritf/drift/ o Section 5.4.2.2: s/acepted/accepted/ o Section 6.5.1: s/advertize/advertise/, twice o Section 6.5.1: s/AFI/Address Family Identifier/ o Section 7.2.2: s/eighbor/neighbor/ o References: are 9 (RFC3041) and 12 (RFC 3531) really normative? o References: 26 (draft-ietf-send-cga) is certainly normative o References: 10,14,28,29,30,31,32,33 are never cited anywhere; o Intellectual Property Statement: should contain the boilerplate from Section 10.4(d) of RFC2026 (add for xml2rfc). -------------------------------------------------------------------- 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 Tue Nov 11 16:08:19 2003 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 QAA22145 for ; Tue, 11 Nov 2003 16:08:19 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hABL5hSs003615; Tue, 11 Nov 2003 22:05:44 +0100 (MET) 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 V63G6TCV; Tue, 11 Nov 2003 22:06: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 hABL5cwg025165; Tue, 11 Nov 2003 22:05: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 hABL48B5025729; Tue, 11 Nov 2003 22:04:08 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hABL48H9025728; Tue, 11 Nov 2003 22:04:08 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep21-app.kolumbus.fi (fep21-0.kolumbus.fi [193.229.0.48]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id hABL47B5025724 for ; Tue, 11 Nov 2003 22:04:08 +0100 (MET) Received: from mta.imail.kolumbus.fi ([193.229.5.109]) by fep21-app.kolumbus.fi with ESMTP id <20031111210407.FICF23234.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi>; Tue, 11 Nov 2003 23:04:07 +0200 X-Mailer: Openwave WebEngine, version 2.8.10 (webedge20-101-191-20030113) From: To: CC: Subject: e: New issue?: The scope of source address for DCS? Date: Tue, 11 Nov 2003 23:04:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20031111210407.FICF23234.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit (resend of an e-mail from the time before the WG meeting) >> >> In issue 21 we agreed that DCA source should be link-local. >> It seems logical to require the same from DCS? > > > > This is a holdover from RFC-2461 where the RS has as source any > address on the host's interface, and the RA is only > link-local. Indeed. > The original motivation may indeed be as Pekka mentioned. > > I'm not fussed now about where we the group > goes with this, but I guess that the same issues which > affect RS/RA will affect DCS/DCA. > > I'm currently concerned with RS/DCS messages coming from an > address which is not on an adjacent link. I don't know > how this is handled in the case where RS's are sent from > a global address today (rfc-2461 doesn't seem to specify > this). > > Should we even listen to such DCS's? Maybe not. But as you say, I'm not sure this is documented even in the ND case. > I'm pretty certain that we don't want to create > erroneous NC state on the router in this case, so > unicast responses are out. It still seems safest to me that we should use link-local addresses. --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 Tue Nov 11 16:09:03 2003 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 QAA22196 for ; Tue, 11 Nov 2003 16:09:02 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hABL7EI2029907; Tue, 11 Nov 2003 22:07:17 +0100 (MET) 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 V6N355MB; Tue, 11 Nov 2003 22:07: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 hABL7Dwg025213; Tue, 11 Nov 2003 22:07: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 hABL5iB5025978; Tue, 11 Nov 2003 22:05:44 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hABL5i3u025977; Tue, 11 Nov 2003 22:05:44 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep21-app.kolumbus.fi (fep21-0.kolumbus.fi [193.229.0.48]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id hABL5gB5025973 for ; Tue, 11 Nov 2003 22:05:42 +0100 (MET) Received: from mta.imail.kolumbus.fi ([193.229.5.109]) by fep21-app.kolumbus.fi with ESMTP id <20031111210542.FILY23234.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi>; Tue, 11 Nov 2003 23:05:42 +0200 X-Mailer: Openwave WebEngine, version 2.8.10 (webedge20-101-191-20030113) From: To: CC: Subject: Re: Source Address Selection and CGA relationship Date: Tue, 11 Nov 2003 23:05:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20031111210542.FILY23234.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit (another resend, failed mail config... sigh) Julien Laganier wrote: > I have a couple of questions regarding the dependance between SEND and default address selections algorithms [RFC3484]. > While using SEND, a node only benefits from SEND if itself and its on-link correspondent (that is, either an on-link router or the other communication endpoint if it's on-link) both uses a CGA to mutually denotes each other. There might be some partial benefits if one of the parties uses SEND. But I agree. > Hence, perhaps the SEND protocol specification should state that: "Rule X: Prefer CGA. If SA is a CGA and SB is not, then prefer SA." ? I think this is what should happen, not sure yet who needs to actually state that and in which document. > In case the remaining questions being: > > o Where should this check be done relatively to others source address selection rules (like home/CoA or public/tmp checks)? Good question. This appears to depend on the user preferences of e.g. security vs. availability or security vs. speed. Anyway, perhaps the practical thing that will happen is that if your node is CGA-enabled, it probably has all of its addresses CGA addresses, and does not use a mixture. It can still communicate with non-SEND nodes, who do not realize that the addresses are so different. So maybe the order really doesn't matter that much. But it must still be defined. It looks like one of the SEND documents would be an appropriate place to put the default... I would say the new rule would go between rules 2 and 3 in RFC 3484. What do you think? > o Should the sense of this preference be reversible for (mostly diagnostic) applications that aren't interested in having a "secure" network (e.g., parallel fping) ? An addendum might be "Implementations MUST/SHOULD provide a mechanism allowing an application to reverse the sense of this preference and prefer non-CG-Addresses over CG-Addresses (e.g., via appropriate API extensions)." We may have a general mechanism for that already. RFC 3484 says: This specification optionally allows for the possibility of administrative configuration of policy that can override the default behavior of the algorithms. The policy override takes the form of a configurable table that specifies precedence values and ... So, it seems to me that if you want to tweak the default then this would suffice, or? I think the case is different for care-of/home addresses because you have a *dynamic* need to prefer care-of addresses in certain cases. --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 Nov 12 11:12:10 2003 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 LAA24651 for ; Wed, 12 Nov 2003 11:12:08 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hACG8KI2009679; Wed, 12 Nov 2003 17:08:21 +0100 (MET) 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 WYRFQRX6; Wed, 12 Nov 2003 17:09:02 +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 hACG84wg026078; Wed, 12 Nov 2003 17:08:04 +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 hACG4WB5001329; Wed, 12 Nov 2003 17:04:32 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hACG4VWv001328; Wed, 12 Nov 2003 17:04:31 +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 hACG4UB5001321 for ; Wed, 12 Nov 2003 17:04:30 +0100 (MET) Received: from mta.imail.kolumbus.fi ([193.229.5.114]) by fep06-app.kolumbus.fi with ESMTP id <20031112160430.OWXF18555.fep06-app.kolumbus.fi@mta.imail.kolumbus.fi>; Wed, 12 Nov 2003 18:04:30 +0200 X-Mailer: Openwave WebEngine, version 2.8.10 (webedge20-101-191-20030113) From: To: CC: Subject: Re: Source Address Selection and CGAs Date: Wed, 12 Nov 2003 18:04:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20031112160430.OWXF18555.fep06-app.kolumbus.fi@mta.imail.kolumbus.fi> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > The table can describe preferences for prefixes and nothing more. Ouch. > Thus unless you pit CGA addresses in different prefixes, which would be > a really BAD idea, you can't use that mechanism AFAIK. In that case I agree. This means that we do need an API, if someone wants to tweak the default preference. --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 Nov 12 15:49:58 2003 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 PAA08667 for ; Wed, 12 Nov 2003 15:49:55 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hACKhuSs025828; Wed, 12 Nov 2003 21:43:56 +0100 (MET) 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 WHXDN920; Wed, 12 Nov 2003 21:44: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 hACKhtXA021828; Wed, 12 Nov 2003 21:43: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 hACKeUB5004157; Wed, 12 Nov 2003 21:40:30 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hACKeUZd004156; Wed, 12 Nov 2003 21:40:30 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id hACKeSB5004152 for ; Wed, 12 Nov 2003 21:40:29 +0100 (MET) Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hACKeQPh025470 for ; Wed, 12 Nov 2003 13:40:26 -0700 (MST) Received: from sun.com (vpn-129-147-154-106.Central.Sun.COM [129.147.154.106]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id hACKeOQ24348; Wed, 12 Nov 2003 21:40:24 +0100 (MET) Message-ID: <3FB29AC9.3020108@sun.com> Date: Wed, 12 Nov 2003 21:40:41 +0100 From: gabriel montenegro Reply-To: gab@sun.com User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-send@standards.ericsson.net Subject: question on ecc for draft-ietf-send-cga References: <20031112160430.OWXF18555.fep06-app.kolumbus.fi@mta.imail.kolumbus.fi> In-Reply-To: <20031112160430.OWXF18555.fep06-app.kolumbus.fi@mta.imail.kolumbus.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Current security is based on RSA almost exclusively: Each CGA address is associated with a public key and auxiliary parameters. The public key is formatted as a DER-encoded [ITU.X690.2002] ASN.1 structure of the type SubjectPublicKeyInfo defined in the Internet X.509 certificate profile [RFC3280]. 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]. The RSA key length SHOULD be at least 384 bits. Using any other public key type or format is strongly discouraged as it will result in incompatible CGA implementations. I understand why whatever is chosen (RSA currently) will end up being *it* as anything else will be incompatible. My question is why not standardize on ECC instead? This would certainly aid small systems both because of the lower CPU requirements and because of smaller packets (true with current levels of 160ECC/1024RSA, improving going forward to 224ECC/2048RSA, etc). So was this ever considered? If so, why was it rejected? I couldn't find any discussion on the mailing list... tnx, -gabriel -------------------------------------------------------------------- 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 Nov 12 18:21:23 2003 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 SAA16736 for ; Wed, 12 Nov 2003 18:21:23 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hACNImSs012418; Thu, 13 Nov 2003 00:18:53 +0100 (MET) 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 V6MMK6CQ; Thu, 13 Nov 2003 00:18:48 +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 hACNIlXA023604; Thu, 13 Nov 2003 00:18:47 +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 hACNFQB5010220; Thu, 13 Nov 2003 00:15:26 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hACNFQdW010216; Thu, 13 Nov 2003 00:15: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 hACNFNB5010176 for ; Thu, 13 Nov 2003 00:15:24 +0100 (MET) Message-ID: <007101c3a972$e5bf47f0$85818182@dclkempt40> From: "James Kempf" To: , References: <20031112160430.OWXF18555.fep06-app.kolumbus.fi@mta.imail.kolumbus.fi> <3FB29AC9.3020108@sun.com> Subject: Re: question on ecc for draft-ietf-send-cga Date: Wed, 12 Nov 2003 15:15: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 Content-Transfer-Encoding: 7bit Gab, > I understand why whatever is chosen (RSA currently) will end up being > *it* as anything else will be incompatible. My question is why not > standardize on ECC instead? This would certainly aid small systems > both because of the lower CPU requirements and because of smaller > packets (true with current levels of 160ECC/1024RSA, improving going > forward to 224ECC/2048RSA, etc). > > So was this ever considered? If so, why was it rejected? I couldn't find > any discussion on the mailing list... > The original SEND draft that I wrote up very early on suggested using ECC for exactly the reasons you describe. This was rejected by the original design team, due to the problem that most ECC methods are heavily RAND IPR encumbered. RSA is IPR free. With a protocol such as SEND that is deeply embedded into the base platform, including RAND IPR encumbered technology is more likely to act as an inhibitor for people who want to implement it. Unlike CGA, I don't think it would be possible to get a nonRAND IPR statement on ECC because it is a much broader technology than CGA and, even if it were, the amount of time and effort required for such a statement would delay SEND at a time when IPv6 deployment is proceeding apace, thereby making it less attractive from a market perspective. At a more general level, one could also ask, why not make the crypto method negotiable? For a basic system function like SEND, this seems a little heavyweight, as long as the protocol accommodates Moore's Law, and it also would complicate the protocol considerably through requiring negotiation. jak -------------------------------------------------------------------- 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 Nov 12 18:45:04 2003 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 SAA17690 for ; Wed, 12 Nov 2003 18:45:04 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hACNegI2021802; Thu, 13 Nov 2003 00:40:42 +0100 (MET) 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 WYRFVTAR; Thu, 13 Nov 2003 00:41:24 +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 hACNeYwg018592; Thu, 13 Nov 2003 00:40:34 +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 hACNbNB5014787; Thu, 13 Nov 2003 00:37:23 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hACNbNAc014786; Thu, 13 Nov 2003 00:37:23 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id hACNbLB5014770 for ; Thu, 13 Nov 2003 00:37:22 +0100 (MET) Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hACNbIxA018071; Wed, 12 Nov 2003 15:37:19 -0800 (PST) Received: from sun.com (vpn-129-147-153-171.Central.Sun.COM [129.147.153.171]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id hACNbGQ17257; Thu, 13 Nov 2003 00:37:16 +0100 (MET) Message-ID: <3FB2C43A.9050801@sun.com> Date: Thu, 13 Nov 2003 00:37:30 +0100 From: gabriel montenegro Reply-To: gab@sun.com User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: ietf-send@standards.ericsson.net Subject: Re: question on ecc for draft-ietf-send-cga References: <20031112160430.OWXF18555.fep06-app.kolumbus.fi@mta.imail.kolumbus.fi> <3FB29AC9.3020108@sun.com> <007101c3a972$e5bf47f0$85818182@dclkempt40> In-Reply-To: <007101c3a972$e5bf47f0$85818182@dclkempt40> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit James Kempf wrote: > The original SEND draft that I wrote up very early on suggested using ECC > >for exactly the reasons you describe. This was rejected by the original >design team, due to the problem that most ECC methods are heavily RAND IPR >encumbered. RSA is IPR free. With a protocol such as SEND that is deeply >embedded into the base platform, including RAND IPR encumbered technology is >more likely to act as an inhibitor for people who want to implement it. >Unlike CGA, I don't think it would be possible to get a nonRAND IPR >statement on ECC because it is a much broader technology than CGA and, even >if it were, the amount of time and effort required for such a statement >would delay SEND at a time when IPv6 deployment is proceeding apace, thereby >making it less attractive from a market perspective. > > Was this done in the light of the fact that Openssl.org already includes (under that license) an optimized ECC implementation? If open source can use it, why not SeND? Further info here: http://research.sun.com/projects/crypto/FrequenlyAskedQuestions.html Caveat: That contribution and text is from my employer, but I'm asking this question as an individual who believes ECC may be a better choice. I think the terms are fine (they're part of openssl, so presumably the terms are identical to those). But this is my personal opinion. -gabriel -------------------------------------------------------------------- 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 Nov 12 21:06:31 2003 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 VAA22481 for ; Wed, 12 Nov 2003 21:06:30 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAD24WI2009112; Thu, 13 Nov 2003 03:04:33 +0100 (MET) 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 V6NP2MZG; Thu, 13 Nov 2003 03:04:32 +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 hAD24VXA026092; Thu, 13 Nov 2003 03:04:31 +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 hAD20lB5020306; Thu, 13 Nov 2003 03:00:47 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hAD20kxk020300; Thu, 13 Nov 2003 03:00:46 +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 hAD20jB5020275 for ; Thu, 13 Nov 2003 03:00:45 +0100 (MET) Received: from mta.imail.kolumbus.fi ([193.229.5.114]) by fep06-app.kolumbus.fi with ESMTP id <20031113020045.QWGG18555.fep06-app.kolumbus.fi@mta.imail.kolumbus.fi> for ; Thu, 13 Nov 2003 04:00:45 +0200 X-Mailer: Openwave WebEngine, version 2.8.10 (webedge20-101-191-20030113) From: To: Subject: Re: question on ecc for draft-ietf-send-cga Date: Thu, 13 Nov 2003 4:00:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20031113020045.QWGG18555.fep06-app.kolumbus.fi@mta.imail.kolumbus.fi> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Gabriel, Its a good question to ask. But I really think RSA is a better choice in terms of being clearly unencumbered. ECC, on the other hand, is widely known to have IPR issues. I do not think the appearance of an algorithm in a public domain software is a proof that there are no IPR issues, say, if a large vendor started using the algorithm. So, I'm strongly in favor of keeping RSA. That doesn't mean that we couldn't revisit this decision and bring another algorithm in to SEND in a Draft Standard phase, for instance, or even later when the IPRs expire like they did for RSA couple of years ago. Secondly, James asked why we can't make this negotiable. It certainly is negotiable in, say, IKE. However, there the situation is different. First of all, its a unicast, negotiated security setup. What we have is in some cases multicast (e.g. DAD) and its hard to see how we could get it to work with negotiation. Also, in IKE the algorithm affects what keys you have, and what the protocols do. In our case it would also affect the addresses that we use for communication. --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 Nov 12 22:02:10 2003 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 WAA24137 for ; Wed, 12 Nov 2003 22:02:09 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAD30ZI2017428; Thu, 13 Nov 2003 04:00:36 +0100 (MET) 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 V6MMNLT9; Thu, 13 Nov 2003 04:00:35 +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 hAD30YXA026702; Thu, 13 Nov 2003 04:00:34 +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 hAD2vKB5002373; Thu, 13 Nov 2003 03:57:20 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hAD2vKmJ002372; Thu, 13 Nov 2003 03:57:20 +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 hAD2vJB5002368 for ; Thu, 13 Nov 2003 03:57:19 +0100 (MET) Received: from mta.imail.kolumbus.fi ([193.229.5.114]) by fep06-app.kolumbus.fi with ESMTP id <20031113025719.QZWE18555.fep06-app.kolumbus.fi@mta.imail.kolumbus.fi>; Thu, 13 Nov 2003 04:57:19 +0200 X-Mailer: Openwave WebEngine, version 2.8.10 (webedge20-101-191-20030113) From: To: CC: Subject: Re: question on ecc for draft-ietf-send-cga Date: Thu, 13 Nov 2003 4:57:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20031113025719.QZWE18555.fep06-app.kolumbus.fi@mta.imail.kolumbus.fi> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > http://research.sun.com/projects/crypto/FrequenlyAskedQuestions.html Having taken a look at this, it does not appear to say more than that SUN will not use its patents against OpenSSL users. It does not say that other implementations of the same techniques would get the same benefits, it does not say that others have no patents on ECC (they do), nor does it say that those others would not come after the users of those patents (my guess is that they would). Lets just not go there. --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 Nov 12 23:51:55 2003 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 XAA27533 for ; Wed, 12 Nov 2003 23:51:54 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAD4nXSs020978; Thu, 13 Nov 2003 05:49:34 +0100 (MET) 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 WYRFY68Q; Thu, 13 Nov 2003 05:50:16 +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 hAD4nVwg029485; Thu, 13 Nov 2003 05:49:31 +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 hAD4kCB5007779; Thu, 13 Nov 2003 05:46:12 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hAD4kCNa007778; Thu, 13 Nov 2003 05:46:12 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mx-serv.inrialpes.fr (mx-serv.inrialpes.fr [194.199.18.100]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id hAD4kBB5007774 for ; Thu, 13 Nov 2003 05:46:11 +0100 (MET) Received: from imap-serv.inrialpes.fr (imap-serv.inrialpes.fr [194.199.18.72]) by mx-serv.inrialpes.fr (8.12.10/8.12.10) with ESMTP id hAD4k7mu017395; Thu, 13 Nov 2003 05:46:07 +0100 (MET) Received: (from nobody@localhost) by imap-serv.inrialpes.fr (8.11.6/8.11.3/ImagV2) id hAD4k7311285; Thu, 13 Nov 2003 05:46:07 +0100 (MET) X-Authentication-Warning: imap-serv.inrialpes.fr: nobody set sender to ccastel@inrialpes.fr using -f Received: from 68.4.96.163 ( [68.4.96.163]) as user ccastel@imap-serv.inrialpes.fr by imap-serv.inrialpes.fr with HTTP; Thu, 13 Nov 2003 05:46:07 +0100 Message-ID: <1068698767.3fb30c8f38f79@imap-serv.inrialpes.fr> Date: Thu, 13 Nov 2003 05:46:07 +0100 From: Claude.Castelluccia@inrialpes.fr To: jari.arkko@kolumbus.fi Cc: ietf-send@standards.ericsson.net Subject: Re: question on ecc for draft-ietf-send-cga References: <20031113020045.QWGG18555.fep06-app.kolumbus.fi@mta.imail.kolumbus.fi> In-Reply-To: <20031113020045.QWGG18555.fep06-app.kolumbus.fi@mta.imail.kolumbus.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-INRIALPES-MailScanner-Information: Please contact the ISP for more information X-INRIALPES-MailScanner: McAfee uvscan 4241 RBL+ ORBS Found to be clean Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Quoting jari.arkko@kolumbus.fi: > > Secondly, James asked why we can't make this negotiable. > It certainly is negotiable in, say, IKE. However, there > the situation is different. First of all, its a unicast, > negotiated security setup. What we have is in some cases > multicast (e.g. DAD) and its hard to see how we could > get it to work with negotiation. For the DAD case, the network (or the router) could actually specify to the hosts which algorithm to use for their CGAs... the algorithm does not have to be negociated between users, it just have to be specified by the network...does this make sense? Claude. -------------------------------------------------------------------- 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 Thu Nov 13 05:25:07 2003 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 FAA19531 for ; Thu, 13 Nov 2003 05:25:06 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hADAN8Ss012089; Thu, 13 Nov 2003 11:23:08 +0100 (MET) 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 V6MMSS08; Thu, 13 Nov 2003 11:23:04 +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 hADAN3XA003493; Thu, 13 Nov 2003 11:23: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 hADAKuB5015434; Thu, 13 Nov 2003 11:20:56 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hADAKuq8015433; Thu, 13 Nov 2003 11:20:56 +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 hADAKsB5015417 for ; Thu, 13 Nov 2003 11:20:54 +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); Thu, 13 Nov 2003 02:20:53 -0800 Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 13 Nov 2003 02:20:52 -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); Thu, 13 Nov 2003 02:20:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: question on ecc for draft-ietf-send-cga Date: Thu, 13 Nov 2003 02:20:31 -0800 Message-ID: <64A531765B7C8342BFA260497BE0045763578F@RED-MSG-43.redmond.corp.microsoft.com> Thread-Topic: question on ecc for draft-ietf-send-cga Thread-Index: AcOpoe5Zql3lB9gZQuyquInZeESxUgAKW2Xw From: "Tuomas Aura" To: X-OriginalArrivalTime: 13 Nov 2003 10:20:51.0336 (UTC) FILETIME=[D03B0880:01C3A9CF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id hADAKtB5015418 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Having multiple alternative algorithms is a bad idea for the following reasons: - Loss of interoperability unless there is at least one mandatory algorithm that everyone must always accept. - Reduced security: The more algorithms a node accepts, the more likely it is that one of them will be broken. Thus, implementing any algorithm on top of the one mandatory one reduces security. - Algorithm negotiation does not work for the delegation chain. - Negotiation requires a multi-message handshake. This makes protocols far less efficient and breaks broadcast protocols like SEND (as Jari already pointed out). - Ad-hoc networks and networks with no SEND-capable router cannot rely on the router to select the algorithm. Tuomas -------------------------------------------------------------------- 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 Thu Nov 13 09:49:30 2003 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 JAA29175 for ; Thu, 13 Nov 2003 09:49:29 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hADEjeSs005572; Thu, 13 Nov 2003 15:45:41 +0100 (MET) 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 V6NP3CPK; Thu, 13 Nov 2003 15:45: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 hADEjdXA008420; Thu, 13 Nov 2003 15:45:40 +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 hADEhNB5014933; Thu, 13 Nov 2003 15:43:23 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hADEhNXX014932; Thu, 13 Nov 2003 15:43:23 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mx.laposte.net (mx.laposte.net [81.255.54.11]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id hADEhMB5014928 for ; Thu, 13 Nov 2003 15:43:22 +0100 (MET) Received: from gbl-dhcp-198-236.europe.research.sun.com (194.2.198.236) by mx.laposte.net (6.0.053) (authenticated as julien.laganier@laposte.net) id 3F65959E00EBE741; Thu, 13 Nov 2003 15:43:20 +0100 From: Julien Laganier To: Subject: Re: Source Address Selection and CGA relationship Date: Thu, 13 Nov 2003 15:41:59 +0100 User-Agent: KMail/1.5.3 Cc: References: <20031111210542.FILY23234.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> In-Reply-To: <20031111210542.FILY23234.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200311131541.59532.julien.laganier@laposte.net> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday 11 November 2003 22:05, jari.arkko@kolumbus.fi wrote: > > Anyway, perhaps the practical thing that will happen is that > if your node is CGA-enabled, it probably has all of its addresses > CGA addresses, and does not use a mixture. It can still communicate > with non-SEND nodes, who do not realize that the addresses are > so different. So maybe the order really doesn't matter that > much. But it must still be defined. It looks like one of the SEND > documents would be an appropriate place to put the default... I agree it's a good simplification if a CGA-enabled has all of its addresses CGA addresses, but I would like to have a mean to make diagnostic tools avoid SeND processing. I guess we agreed that it requires an API cuz it cannot be done with system defaults (a diagnostic tools doesn't fall in the default category). Thus, the API should allow either 1) to choose a non-CGA address, or 2) disable SeND processing. It's not yet clear to me which is the best solution. > I would say the new rule would go between rules 2 and 3 in > RFC 3484. What do you think? My first idea was to put the new rule at the end of the list, so that, hopefully, it doesn't disturb too much regular address selection processing :-) But it makes sense to me to put the new CGA preference rule between rules 2 and 3, though I'm not sure it doesn't conflicts with others rules, like those related to MobileIP for example. Suppose, for instance, that your CoA is a CGA (e.g., your attachment LAN is SeND-enabled) and your HoA is not (e.g., your home network isn't SeND-enabled): An application would prefer to use the CoA as a source address, which negates rule 4 (prefer HoA). I don't know if this is really an issue. What do mobile-ip guys think? Thanks, --julien -------------------------------------------------------------------- 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 Thu Nov 13 15:19:58 2003 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 PAA18142 for ; Thu, 13 Nov 2003 15:19:57 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hADKHXI2018856; Thu, 13 Nov 2003 21:17:33 +0100 (MET) 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 V6NPQ6CS; Thu, 13 Nov 2003 21:17:33 +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 hADKHWXA012289; Thu, 13 Nov 2003 21:17: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 hADKFQB5002028; Thu, 13 Nov 2003 21:15:26 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hADKFQHV002025; Thu, 13 Nov 2003 21:15: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 hADKFNB5001962 for ; Thu, 13 Nov 2003 21:15:24 +0100 (MET) Message-ID: <041a01c3aa22$e78b6c70$85818182@dclkempt40> From: "James Kempf" To: "Julien Laganier" , Cc: References: <20031111210542.FILY23234.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> <200311131541.59532.julien.laganier@laposte.net> Subject: Re: Source Address Selection and CGA relationship Date: Thu, 13 Nov 2003 12:15:36 -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 Content-Transfer-Encoding: 7bit Julian, > > Anyway, perhaps the practical thing that will happen is that > > if your node is CGA-enabled, it probably has all of its addresses > > CGA addresses, and does not use a mixture. It can still communicate > > with non-SEND nodes, who do not realize that the addresses are > > so different. So maybe the order really doesn't matter that > > much. But it must still be defined. It looks like one of the SEND > > documents would be an appropriate place to put the default... > > I agree it's a good simplification if a CGA-enabled has all of its addresses > CGA addresses, but I would like to have a mean to make diagnostic tools avoid > SeND processing. I guess we agreed that it requires an API cuz it cannot be > done with system defaults (a diagnostic tools doesn't fall in the default > category). > > Thus, the API should allow either 1) to choose a non-CGA address, or 2) > disable SeND processing. It's not yet clear to me which is the best solution. > So how about if the draft-ietf-send-ndopts says: A SEND=enabled node SHOULD use CGA addresses by default, but MAY use nonCGA addresses for testing, diagnostics, and other purposes. The node MAY provide an API to switch address type, but such an API is not considered further in this document. ...since an API is out of scope of the SEND group. > > I would say the new rule would go between rules 2 and 3 in > > RFC 3484. What do you think? > Changing RFC 3484 is not within the scope of the SEND group's charter. Pekka and I will inform the IESG about this when we send the document to them, so they can figure out how to get the change made. > My first idea was to put the new rule at the end of the list, so that, > hopefully, it doesn't disturb too much regular address selection processing > :-) > > But it makes sense to me to put the new CGA preference rule between rules 2 > and 3, though I'm not sure it doesn't conflicts with others rules, like those > related to MobileIP for example. > > Suppose, for instance, that your CoA is a CGA (e.g., your attachment LAN is > SeND-enabled) and your HoA is not (e.g., your home network isn't > SeND-enabled): An application would prefer to use the CoA as a source > address, which negates rule 4 (prefer HoA). > > I don't know if this is really an issue. What do mobile-ip guys think? > We don't have to figure this out now. jak -------------------------------------------------------------------- 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 Thu Nov 13 16:35:25 2003 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 QAA21974 for ; Thu, 13 Nov 2003 16:35:24 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hADLWeSs021758; Thu, 13 Nov 2003 22:32:41 +0100 (MET) 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 V6MM7TX0; Thu, 13 Nov 2003 22:32: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 hADLWdXA012751; Thu, 13 Nov 2003 22:32: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 hADLTGB5017825; Thu, 13 Nov 2003 22:29:17 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hADLTG83017824; Thu, 13 Nov 2003 22:29:16 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id hADLTEB5017805 for ; Thu, 13 Nov 2003 22:29:15 +0100 (MET) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hADLSxW27998; Thu, 13 Nov 2003 13:28:59 -0800 X-mProtect: <200311132128> Nokia Silicon Valley Messaging Protection Received: from danira-pool05457.americas.nokia.com (10.241.54.57, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQuyHmu; Thu, 13 Nov 2003 13:28:58 PST Message-ID: <3FB3F78F.1080909@iprg.nokia.com> Date: Thu, 13 Nov 2003 13:28:47 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julien Laganier CC: jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net Subject: Re: Source Address Selection and CGA relationship References: <20031111210542.FILY23234.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> <200311131541.59532.julien.laganier@laposte.net> In-Reply-To: <200311131541.59532.julien.laganier@laposte.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Julien Laganier wrote: > >>I would say the new rule would go between rules 2 and 3 in >>RFC 3484. What do you think? > > > My first idea was to put the new rule at the end of the list, so that, > hopefully, it doesn't disturb too much regular address selection processing > :-) > > But it makes sense to me to put the new CGA preference rule between rules 2 > and 3, though I'm not sure it doesn't conflicts with others rules, like those > related to MobileIP for example. > > Suppose, for instance, that your CoA is a CGA (e.g., your attachment LAN is > SeND-enabled) and your HoA is not (e.g., your home network isn't > SeND-enabled): An application would prefer to use the CoA as a source > address, which negates rule 4 (prefer HoA). > > I don't know if this is really an issue. What do mobile-ip guys think? well, if you have a CGA CoA and non-CGA CoA, the rule can be 'prefer a CGA CoA'. between HoA and CoA, you have to always prefer the HoA irrespective of whether the HoA/CoA is a CGA address or not. Vijay -------------------------------------------------------------------- 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 Thu Nov 13 18:29:11 2003 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 SAA29171 for ; Thu, 13 Nov 2003 18:29:10 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hADNCLI2009145; Fri, 14 Nov 2003 00:12:22 +0100 (MET) 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 V6MM8Y2V; Fri, 14 Nov 2003 00:12:21 +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 hADNCKXA013338; Fri, 14 Nov 2003 00:12:20 +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 hADNAIB5011547; Fri, 14 Nov 2003 00:10:18 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hADNAIJo011546; Fri, 14 Nov 2003 00:10:18 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id hADNAGB5011530 for ; Fri, 14 Nov 2003 00:10:17 +0100 (MET) Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 13 Nov 2003 15:10:15 -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); Thu, 13 Nov 2003 15:10:14 -0800 Received: from 157.54.5.25 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 13 Nov 2003 15:10:14 -0800 Received: from RED-MSG-31.redmond.corp.microsoft.com ([157.54.47.231]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 13 Nov 2003 15:10:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Source Address Selection and CGA relationship Date: Thu, 13 Nov 2003 15:10:09 -0800 Message-ID: <5C611EA73500FE4C908733811F670B4501C4F868@RED-MSG-31.redmond.corp.microsoft.com> Thread-Topic: Source Address Selection and CGA relationship Thread-Index: AcOqLjYp1R43W7BQRgSZU0ErOCt5yQADOAdA From: "Richard Draves" To: "Vijay Devarapalli" , "Julien Laganier" Cc: , X-OriginalArrivalTime: 13 Nov 2003 23:10:10.0256 (UTC) FILETIME=[49174500:01C3AA3B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id hADNAHB5011531 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit > > > >>I would say the new rule would go between rules 2 and 3 in > RFC 3484. > >>What do you think? I think the preference for CGA would be at the end of the list, in rule 7. Somehow it feels similar to the public/temporary address preference. Rich -------------------------------------------------------------------- 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 Fri Nov 14 11:38:11 2003 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 LAA19361 for ; Fri, 14 Nov 2003 11:38:06 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAEGZCI2011224; Fri, 14 Nov 2003 17:35:13 +0100 (MET) 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 WYRGT63T; Fri, 14 Nov 2003 17:35:59 +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 hAEGZ6wg008565; Fri, 14 Nov 2003 17:35: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 hAEGUNB5023130; Fri, 14 Nov 2003 17:30:23 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hAEGUNaJ023127; Fri, 14 Nov 2003 17:30:23 +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 hAEGUMB5023076 for ; Fri, 14 Nov 2003 17:30:22 +0100 (MET) Received: from ericsson.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id DB0BD1C; Fri, 14 Nov 2003 18:43:26 +0200 (EET) Message-ID: <3FB5031C.6070409@ericsson.com> Date: Fri, 14 Nov 2003 10:30:20 -0600 From: Pekka Nikander Reply-To: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pasi.eronen@nokia.com, James Kempf , Greg Daley , Margaret Wasserman , Christian Huitema , Samita.Chakrabarti@eng.sun.com, Jari Arkko , Tony Hain Cc: SEND WG Subject: Please check: Discussion transcript from SEND WG on Tuesday Content-Type: multipart/mixed; boundary="------------000506030003060506050809" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk This is a multi-part message in MIME format. --------------000506030003060506050809 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pasi, James, Greg, Margaret, Christian, Samita, Jari, and Tony, I have now prepared a transcript of the discussions that took place at the SEND WG on Tuesday, based on minutes provided by Greg Daley and Michael Richardsson. Many thanks to Greg and Michael! Please check that what I have written matches accurately enough with what you intended to say. If not, please send me corrections. If you said something, and notice that we have missed that, please let me know. I will produce summarized minutes next week, and also post a corrected version of this discussion. [I am posting this from p.n@ericsson.com, but please send replies to p.n@nomadiclab.com. The reason for posting from ericsson.com are the problems that I have with posting to the list. I'm sorry for the inconvenience.] --Pekka Nikander --------------000506030003060506050809 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="discussion.txt" Content-Disposition: inline; filename="discussion.txt" Content-Transfer-Encoding: 7bit Pasi Eronen: I reviewed the CGA draft and even checked the hashes in the examples, and the draft seems to be OK. James Kempf: Thanks, these kinds of reviews are important, especially ones that go deep enough. Greg Daley: Did Jon Wood implement the DCS/DCA response delay? In other words, did the measured number include the DCS/DCA random delay? James Kempf: No, I don't think so. I will post a definite answer to the list. Margaret Wasserman: Question. HOW do we configure to use the secure address as the source address? All the other address selection rules in RFC3484 check the prefix of the address. How can the configuration table in RFC3484 dtermine if the address is a CGA address? Or do we always want to prefer the secure address? Christian Huitema: We already do this with RFC3014 privacy addresses. We might not want to prefer a CGA address, we might want to use some other address, a throw away address which we use for privacy. We may also want to use a different key for privacy addresses. Samita Chakrabarti: In terms of source addresses it is implementation specific how to determine whether to use a CGA address or not. The local node will know if a given source address is a CGA or not. The MIPv6 API contains switching of addresses on/off. Jari: For care-of addresses, one might prefer, but why CGA? Samita: I am not sure, I am probably not the best person to answer this question. But please specify what the default mode is to be, to use CGA addresses or not? For the question of whether a new API should be created or not, please consult the IPv6 WG. Tony Hain: The new public keys will have to registered somewhere, right? Jari Arkko: We do not need any infrastructure to store the keys. James: These keys aren't being used elsewhere. Only in RS/ND. Tony Hain: If CGAs become the preferred addresses, we need to ensure that there is a place to make the keys available, since people will want to use the keys elsewhere. So, don't go there right now. James Kempf: We need to take this to the list. Greg Daley: I have not seen any hosts that send redirects. However, if there indeed are such cases, maybe we have to have a look into this. James Kempf: Lets take this, too, to the list. Pasi Eronen: I did the review of the NDopts document, too, and most of the issues are editorial in nature. For example, the ndopts document says the modifier is 16 bits and the CGA document states that it is 16 octets (or was it the other way around?). However, I have an issue with the timestamp algorithm. I am not sure whether it works with 1 second resolution for timestamp, even with less than 1 second timestamp. Allow things to be off by 1 second. But I've sent this comment to the list already. There seems to be also some text missing about unsolicited ND. If the node has some reason to update things, it can send them. Jari Arkko: Yes, we need to handle these issues. Thank you for bringing them up. Pasi Eronen: There is also lots of redundant text. Jari Arkko: Yes, the document needs some serious editing. James Kempf: The goal right now is to get the document ready, and announce another last call before the end of November, if possible. We will also send the document to the review board. Apparently, it will take some time to process the review comments, but the goal is to get the document ready for IESG before the end of the year. Then it usually takes 6-9 months to get through the IESG and the RFC Editor. Margaret Wasserman: We need to try to do better than 9 years for getting this through. James Kempf: The idea is to shut down the working group of the IESG review, but keep the mailing list running anyway. Margeret Wasserman: Maybe we need to keep the group on a hiatus if we need to go to draft standard. But that is just a process issue. James Kempf: I like things to start, cruise, and reach end. Hence I would prefer to close down the working group and run later another bof, if needed. --------------000506030003060506050809-- -------------------------------------------------------------------- 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 Fri Nov 14 13:32:10 2003 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 NAA23825 for ; Fri, 14 Nov 2003 13:32:09 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAEIUJI2027613; Fri, 14 Nov 2003 19:30:20 +0100 (MET) 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 V6NP6JBB; Fri, 14 Nov 2003 19:30:19 +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 hAEIUHXA018298; Fri, 14 Nov 2003 19:30: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 hAEIPdB5018864; Fri, 14 Nov 2003 19:25:39 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hAEIPdhu018863; Fri, 14 Nov 2003 19:25:39 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mx.laposte.net (mx.laposte.net [81.255.54.11]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id hAEIPcB5018859 for ; Fri, 14 Nov 2003 19:25:38 +0100 (MET) Received: from gbl-dhcp-198-236.europe.research.sun.com (194.2.198.236) by mx.laposte.net (6.0.053) (authenticated as julien.laganier@laposte.net) id 3F48B1C501499D1B; Thu, 13 Nov 2003 14:57:09 +0100 From: Julien Laganier Reply-To: julien.laganier@ens-lyon.fr Organization: LIP - ENS-Lyon To: Subject: Re: Source Address Selection and CGA relationship Date: Thu, 13 Nov 2003 14:55:48 +0100 User-Agent: KMail/1.5.3 Cc: References: <20031111210542.FILY23234.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> In-Reply-To: <20031111210542.FILY23234.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200311131455.24614.julien.laganier@laposte.net> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday 11 November 2003 22:05, jari.arkko@kolumbus.fi wrote: > > Anyway, perhaps the practical thing that will happen is that > if your node is CGA-enabled, it probably has all of its addresses > CGA addresses, and does not use a mixture. It can still communicate > with non-SEND nodes, who do not realize that the addresses are > so different. So maybe the order really doesn't matter that > much. But it must still be defined. It looks like one of the SEND > documents would be an appropriate place to put the default... I agree it's a good simplification if a CGA-enabled has all of its addresses CGA addresses, but I would like to have a mean to make diagnostic tools avoid SeND processing. I guess we agreed that it requires an API cuz it cannot be done with system defaults (a diagnostic tools doesn't fall in the default category). Thus, the API should allow either 1) to choose a non-CGA address, or 2) disable SeND processing. It's not yet clear to me which is the best solution. > I would say the new rule would go between rules 2 and 3 in > RFC 3484. What do you think? My first idea was to put the new rule at the end of the list, so that, hopefully, it doesn't disturb too much regular address selection processing :-) But it makes sense to me to put the new CGA preference rule between rules 2 and 3, though I'm not sure it doesn't conflicts with others rules, like those related to MobileIP for example. Suppose, for instance, that your CoA is a CGA (e.g., your attachment LAN is SeND-enabled) and your HoA is not (e.g., your home network isn't SeND-enabled): An application would prefer to use the CoA as a source address, which negates rule 4 (prefer HoA). I don't know if this is really an issue. What do mobile-ip guys think? Thanks, --julien -------------------------------------------------------------------- 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 Fri Nov 14 17:45:24 2003 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 RAA02588 for ; Fri, 14 Nov 2003 17:45:23 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAEMgRSs026042; Fri, 14 Nov 2003 23:42:27 +0100 (MET) 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 V6MNN6NJ; Fri, 14 Nov 2003 23:42:27 +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 hAEMfOwg018993; Fri, 14 Nov 2003 23:41:47 +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 hAEMaDB5016284; Fri, 14 Nov 2003 23:36:13 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hAEMaDu8016283; Fri, 14 Nov 2003 23:36:13 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mx.laposte.net (mx.laposte.net [81.255.54.11]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id hAEMaCB5016279 for ; Fri, 14 Nov 2003 23:36:12 +0100 (MET) Received: from [194.2.144.31] (194.2.144.31) by mx.laposte.net (6.0.053) (authenticated as julien.laganier@laposte.net) id 3FAA8BBF0024BE00 for ietf-send@standards.ericsson.net; Fri, 14 Nov 2003 23:15:39 +0100 From: Julien Laganier To: ietf-send@standards.ericsson.net Subject: Re: Source Address Selection and CGA relationship Date: Fri, 14 Nov 2003 23:14:16 +0100 User-Agent: KMail/1.5.3 References: <20031111210542.FILY23234.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> <200311131541.59532.julien.laganier@laposte.net> <3FB3F78F.1080909@iprg.nokia.com> In-Reply-To: <3FB3F78F.1080909@iprg.nokia.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200311142314.16362.julien.laganier@laposte.net> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday 13 November 2003 22:28, Vijay Devarapalli wrote: > Julien Laganier wrote: > >>I would say the new rule would go between rules 2 and 3 in > >>RFC 3484. What do you think? > > > > My first idea was to put the new rule at the end of the list, so that, > > hopefully, it doesn't disturb too much regular address selection > > processing > > > > :-) > > > > But it makes sense to me to put the new CGA preference rule between rules > > 2 and 3, though I'm not sure it doesn't conflicts with others rules, like > > those related to MobileIP for example. > > > > Suppose, for instance, that your CoA is a CGA (e.g., your attachment LAN > > is SeND-enabled) and your HoA is not (e.g., your home network isn't > > SeND-enabled): An application would prefer to use the CoA as a source > > address, which negates rule 4 (prefer HoA). > > > > I don't know if this is really an issue. What do mobile-ip guys think? > > well, if you have a CGA CoA and non-CGA CoA, the rule can be > 'prefer a CGA CoA'. between HoA and CoA, you have to always > prefer the HoA irrespective of whether the HoA/CoA is a CGA > address or not. So It seems that this new rule should be put at the end of the list, as Richard proposed (in rule 7), thus avoiding conflicts with MIP-related and others address selections rules. This probably implies, as some people stated before, that a SeND-enabled node should be configured with CGA only addresses. Thanks, --julien -------------------------------------------------------------------- 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 Fri Nov 14 21:20:18 2003 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 VAA10071 for ; Fri, 14 Nov 2003 21:20:18 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAF2HwI2011525; Sat, 15 Nov 2003 03:17:59 +0100 (MET) 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 V6MNPW4L; Sat, 15 Nov 2003 03:17:58 +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 hAF2Hnwg025096; Sat, 15 Nov 2003 03:17: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 hAF2DBB5008099; Sat, 15 Nov 2003 03:13:11 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hAF2DBmN008098; Sat, 15 Nov 2003 03:13:11 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mx.laposte.net (mx.laposte.net [81.255.54.11]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id hAF2D9B5008094 for ; Sat, 15 Nov 2003 03:13:10 +0100 (MET) Received: from gbl-dhcp-198-236.europe.research.sun.com (194.2.198.236) by mx.laposte.net (6.0.053) (authenticated as julien.laganier@laposte.net) id 3FAA8BBF00228BBB; Fri, 14 Nov 2003 14:44:34 +0100 From: Julien Laganier To: Vijay Devarapalli Subject: Re: Source Address Selection and CGA relationship Date: Fri, 14 Nov 2003 14:43:12 +0100 User-Agent: KMail/1.5.3 Cc: jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net References: <20031111210542.FILY23234.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> <200311131541.59532.julien.laganier@laposte.net> <3FB3F78F.1080909@iprg.nokia.com> In-Reply-To: <3FB3F78F.1080909@iprg.nokia.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200311141442.59857.julien.laganier@laposte.net> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday 13 November 2003 22:28, Vijay Devarapalli wrote: > Julien Laganier wrote: > >>I would say the new rule would go between rules 2 and 3 in > >>RFC 3484. What do you think? > > > > My first idea was to put the new rule at the end of the list, so that, > > hopefully, it doesn't disturb too much regular address selection > > processing > > > > :-) > > > > But it makes sense to me to put the new CGA preference rule between rules > > 2 and 3, though I'm not sure it doesn't conflicts with others rules, like > > those related to MobileIP for example. > > > > Suppose, for instance, that your CoA is a CGA (e.g., your attachment LAN > > is SeND-enabled) and your HoA is not (e.g., your home network isn't > > SeND-enabled): An application would prefer to use the CoA as a source > > address, which negates rule 4 (prefer HoA). > > > > I don't know if this is really an issue. What do mobile-ip guys think? > > well, if you have a CGA CoA and non-CGA CoA, the rule can be > 'prefer a CGA CoA'. between HoA and CoA, you have to always > prefer the HoA irrespective of whether the HoA/CoA is a CGA > address or not. So It seems that this new rule should be put at the end of the list, as Richard proposed (in rule 7), thus avoiding conflicts with MIP-related and others address selections rules. This probably implies, as some people stated before, that a SeND-enabled node should be configured with CGA only addresses. Thanks, --julien -------------------------------------------------------------------- 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 Sun Nov 16 05:30:28 2003 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 FAA24755 for ; Sun, 16 Nov 2003 05:30:27 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAGAQjI2003742; Sun, 16 Nov 2003 11:26:45 +0100 (MET) 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 V6MN0L6S; Sun, 16 Nov 2003 11:26:45 +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 hAGAQSwg019256; Sun, 16 Nov 2003 11:26: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 hAGAO6B5022361; Sun, 16 Nov 2003 11:24:06 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hAGAO5W5022360; Sun, 16 Nov 2003 11:24:05 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id hAGAO3B5022356 for ; Sun, 16 Nov 2003 11:24:04 +0100 (MET) Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hAGANrUP004279; Sun, 16 Nov 2003 02:23:55 -0800 (PST) Received: from sun.com (vpn-129-156-96-10.EMEA.Sun.COM [129.156.96.10]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id hAGANqQ13719; Sun, 16 Nov 2003 11:23:52 +0100 (MET) Message-ID: <3FB74F12.2020505@sun.com> Date: Sun, 16 Nov 2003 11:18:58 +0100 From: gabriel montenegro Reply-To: gab@sun.com User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tuomas Aura CC: ietf-send@standards.ericsson.net Subject: Re: question on ecc for draft-ietf-send-cga References: <64A531765B7C8342BFA260497BE0045763578F@RED-MSG-43.redmond.corp.microsoft.com> In-Reply-To: <64A531765B7C8342BFA260497BE0045763578F@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 Content-Transfer-Encoding: 7bit Tuomas Aura wrote: > Having multiple alternative algorithms is a bad idea for the > following reasons: > > - Loss of interoperability unless there is at least one > mandatory algorithm that everyone must always accept. Clearly at least one (and hopefully not more than that) must be a MUST. > - Reduced security: The more algorithms a node accepts, the > more likely it is that one of them will be broken. Thus, > implementing any algorithm on top of the one mandatory > one reduces security. I seem to think of this the other way around. If we put all eggs in one basket and that basket is broken into... > - Algorithm negotiation does not work for the delegation > chain. > - Negotiation requires a multi-message handshake. This > makes protocols far less efficient and breaks broadcast > protocols like SEND (as Jari already pointed out). Maybe negotiation does. But maybe that is not necessary. "Offer-and-choose" could perhaps work in the multicast or broadcast model( haven't thought through all the details though). > - Ad-hoc networks and networks with no SEND-capable router > cannot rely on the router to select the algorithm. Ad hoc networks? Is that in the charter? Perhaps small system performance is more of a concern? At any rate, from what I hear 1024 bit RSA is not estimated to be secure beyond 2010 (and some have moved to 2048 bit RSA already). Perhaps performance and fragmentation issues may force a revisiting of this decision within a few years. I realize that the IPR issues are not completely clear to all in spite of the existence of open source implementations (openssl is one, mozilla NSS as of version 3.8 is another). Heck, at least in my mind, this also applies to the CGA IPR itself. For example, the Ericsson/MS statements apply to draft-ietf-send-ipsec-XX, but there is no mention of draft-ietf-send-cga-XX. But perhaps the only way to get some warm and fuzzy that things are ok for us non-lawyers is to have some experience and see a track record of things being ok. -gabriel -------------------------------------------------------------------- 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 Mon Nov 17 07:54:45 2003 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 HAA10255 for ; Mon, 17 Nov 2003 07:54:45 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAHCpmI2007176; Mon, 17 Nov 2003 13:51:48 +0100 (MET) 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 V6NQ3WM7; Mon, 17 Nov 2003 13:51:47 +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 hAHCpkXA013876; Mon, 17 Nov 2003 13:51:46 +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 hAHCkeB5013137; Mon, 17 Nov 2003 13:46:40 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hAHCkeMj013136; Mon, 17 Nov 2003 13: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 hAHCkdB5013124 for ; Mon, 17 Nov 2003 13:46:39 +0100 (MET) Received: from mta.imail.kolumbus.fi ([193.229.5.110]) by fep20-app.kolumbus.fi with ESMTP id <20031117124639.BHDD15980.fep20-app.kolumbus.fi@mta.imail.kolumbus.fi>; Mon, 17 Nov 2003 14:46:39 +0200 X-Mailer: Openwave WebEngine, version 2.8.10 (webedge20-101-191-20030113) From: To: CC: Subject: Re: question on ecc for draft-ietf-send-cga Date: Mon, 17 Nov 2003 14:46:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20031117124639.BHDD15980.fep20-app.kolumbus.fi@mta.imail.kolumbus.fi> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > Heck, at least in my mind, this also applies to the CGA IPR itself. > For example, the Ericsson/MS statements apply to > draft-ietf-send-ipsec-XX, but there is no mention of > draft-ietf-send-cga-XX. And draft-ietf-send-ipsec has been replaced with draft-ietf- send-ndopt. But I think the original statements had some words about derivate works. If this is an issue for someone, we can ask for an updated statement; perhaps that would make sense around the time the draft names and versions don't change much more, such as in IETF last call. I'd rather not visit the IPR department too often ;-) > But perhaps the only way to get some warm and fuzzy that things > are ok for us non-lawyers is to have some experience and see a track > record of things being ok. I agree, even if I don't share your view that the thnings are ok. Things might be ok until enough billion dollar companies have put the stuff in their products ;-) But here's a practical proposal that I think we could both agree on: we would keep the drafts as they are now, but agree to revisit this issue after the SEND WG comes back alive to issue Draft Standard RFC perhaps. By that time (maybe 1-2 years from now) we should have learned whether the RSA packet sizes are a practical problem, and gotten additional evidence of the situation on the ECC side. --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 Mon Nov 17 08:54:03 2003 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 IAA11741 for ; Mon, 17 Nov 2003 08:54:03 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAHDpOI2028828; Mon, 17 Nov 2003 14:51:24 +0100 (MET) 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 WYRHZ7WN; Mon, 17 Nov 2003 14:52:19 +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 hAHDpFXA022968; Mon, 17 Nov 2003 14:51: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 hAHDkhB5000876; Mon, 17 Nov 2003 14:46:43 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hAHDkg5J000874; Mon, 17 Nov 2003 14:46:42 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id hAHDkeB5000868 for ; Mon, 17 Nov 2003 14:46:41 +0100 (MET) Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hAHDkUUP012284; Mon, 17 Nov 2003 05:46:32 -0800 (PST) Received: from sun.com (buse [129.157.212.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id hAHDkUQ29386; Mon, 17 Nov 2003 14:46:30 +0100 (MET) Message-ID: <3FB8D136.3070002@sun.com> Date: Mon, 17 Nov 2003 14:46:30 +0100 From: gabriel montenegro User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari.arkko@kolumbus.fi CC: ietf-send@standards.ericsson.net Subject: Re: question on ecc for draft-ietf-send-cga References: <20031117124639.BHDD15980.fep20-app.kolumbus.fi@mta.imail.kolumbus.fi> In-Reply-To: <20031117124639.BHDD15980.fep20-app.kolumbus.fi@mta.imail.kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit jari.arkko@kolumbus.fi wrote: > But here's a practical proposal that I think we could > both agree on: we would keep the drafts as they are now, > but agree to revisit this issue after the SEND WG comes > back alive to issue Draft Standard RFC perhaps. By that > time (maybe 1-2 years from now) we should have learned > whether the RSA packet sizes are a practical problem, and > gotten additional evidence of the situation on the ECC > side. This makes good sense, Jari, thanks. Who knows if the answer will have changed by then, but it's worth at least asking the question. -gabriel -------------------------------------------------------------------- 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 Mon Nov 17 14:12:01 2003 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 OAA28811 for ; Mon, 17 Nov 2003 14:12:00 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAHJ8fI2026176; Mon, 17 Nov 2003 20:08:41 +0100 (MET) 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 WYRH919K; Mon, 17 Nov 2003 20:09:37 +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 hAHJ8Lwg005660; Mon, 17 Nov 2003 20:08: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 hAHJ4wB5014585; Mon, 17 Nov 2003 20:04:58 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hAHJ4wLo014584; Mon, 17 Nov 2003 20:04:58 +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 hAHJ4uB5014572 for ; Mon, 17 Nov 2003 20:04:57 +0100 (MET) Message-ID: <021b01c3ad3d$bb1fce60$956015ac@dclkempt40> From: "James Kempf" To: , Cc: References: <20031117124639.BHDD15980.fep20-app.kolumbus.fi@mta.imail.kolumbus.fi> Subject: Re: question on ecc for draft-ietf-send-cga Date: Mon, 17 Nov 2003 11:05:12 -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 Content-Transfer-Encoding: 7bit > > Heck, at least in my mind, this also applies to the CGA IPR itself. > > For example, the Ericsson/MS statements apply to > > draft-ietf-send-ipsec-XX, but there is no mention of > > draft-ietf-send-cga-XX. > > And draft-ietf-send-ipsec has been replaced with draft-ietf- > send-ndopt. But I think the original statements had some > words about derivate works. If this is an issue for someone, > we can ask for an updated statement; perhaps that would make > sense around the time the draft names and versions don't > change much more, such as in IETF last call. I'd rather > not visit the IPR department too often ;-) > > > But perhaps the only way to get some warm and fuzzy that things > > are ok for us non-lawyers is to have some experience and see a track > > record of things being ok. > > I agree, even if I don't share your view that the thnings are > ok. Things might be ok until enough billion dollar companies > have put the stuff in their products ;-) > > But here's a practical proposal that I think we could > both agree on: we would keep the drafts as they are now, > but agree to revisit this issue after the SEND WG comes > back alive to issue Draft Standard RFC perhaps. By that > time (maybe 1-2 years from now) we should have learned > whether the RSA packet sizes are a practical problem, and > gotten additional evidence of the situation on the ECC > side. > This sounds reasonable to me. jak -------------------------------------------------------------------- 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 Mon Nov 17 14:40:03 2003 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 OAA29792 for ; Mon, 17 Nov 2003 14:40:02 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAHJaTSs013894; Mon, 17 Nov 2003 20:36:29 +0100 (MET) 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 WYRH9N7B; Mon, 17 Nov 2003 20:37: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 hAHJaLwg007293; Mon, 17 Nov 2003 20:36: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 hAHJX3B5021604; Mon, 17 Nov 2003 20:33:03 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hAHJX3xD021603; Mon, 17 Nov 2003 20:33:03 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mx-serv.inrialpes.fr (mx-serv.inrialpes.fr [194.199.18.100]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id hAHJX1B5021590 for ; Mon, 17 Nov 2003 20:33:02 +0100 (MET) Received: from imap-serv.inrialpes.fr (imap-serv.inrialpes.fr [194.199.18.72]) by mx-serv.inrialpes.fr (8.12.10/8.12.10) with ESMTP id hAHJWpYw021462; Mon, 17 Nov 2003 20:32:51 +0100 (MET) Received: (from nobody@localhost) by imap-serv.inrialpes.fr (8.11.6/8.11.3/ImagV2) id hAHJWpV10273; Mon, 17 Nov 2003 20:32:51 +0100 (MET) X-Authentication-Warning: imap-serv.inrialpes.fr: nobody set sender to ccastel@inrialpes.fr using -f Received: from 128.200.38.88 ( [128.200.38.88]) as user ccastel@imap-serv.inrialpes.fr by imap-serv.inrialpes.fr with HTTP; Mon, 17 Nov 2003 20:32:50 +0100 Message-ID: <1069097570.3fb92262e3e64@imap-serv.inrialpes.fr> Date: Mon, 17 Nov 2003 20:32:50 +0100 From: Claude.Castelluccia@inrialpes.fr To: James Kempf Cc: jari.arkko@kolumbus.fi, gab@eng.sun.cnri.reston.va.us, ietf-send@standards.ericsson.net Subject: Re: question on ecc for draft-ietf-send-cga References: <20031117124639.BHDD15980.fep20-app.kolumbus.fi@mta.imail.kolumbus.fi> <021b01c3ad3d$bb1fce60$956015ac@dclkempt40> In-Reply-To: <021b01c3ad3d$bb1fce60$956015ac@dclkempt40> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-INRIALPES-MailScanner-Information: Please contact the ISP for more information X-INRIALPES-MailScanner: McAfee uvscan 4241 RBL+ ORBS Found to be clean Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Hello, BTW i was just wondering: why/how was RSA selected instead of DSA? Is it because verifying in DSA is quite expensive and we rather put the burden on the signer? thanks, Claude. -------------------------------------------------------------------- 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 Nov 19 06:32:08 2003 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 GAA13016 for ; Wed, 19 Nov 2003 06:32:07 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAJBRxI2004913; Wed, 19 Nov 2003 12:27:59 +0100 (MET) 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 XFF53D43; Wed, 19 Nov 2003 12:27:59 +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 hAJBRwXA012382; Wed, 19 Nov 2003 12:27:58 +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 hAJBPYB5016493; Wed, 19 Nov 2003 12:25:34 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hAJBPYJM016492; Wed, 19 Nov 2003 12:25:34 +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 hAJBPXB5016488 for ; Wed, 19 Nov 2003 12:25:33 +0100 (MET) Received: from ericsson.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 2D72A1C; Wed, 19 Nov 2003 13:38:38 +0200 (EET) Message-ID: <3FBB5330.3020904@ericsson.com> Date: Wed, 19 Nov 2003 12:25:36 +0100 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Cc: Samita Chakrabarti Subject: An API question from Samita Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Following the discussion last week at Minneapolis, Samita Chakrabarti wants to ask the working group the following question: draft-chakrabarti-ipv6-addrselect-api-02.txt already has a mechanism to choose CGA and NON-CGA source addresses by the application using socket api. The SEND wg needs to decide whether such API is needed for applications running on a SEND-node. Please send the decision on this to the IPv6 wg alias - based on that we will update the address selection API draft (which actually goes along with RFC3484). Please send your replies to the mailing list. The chairs will summarize and post the summary also to the ipv6 mailing list. --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 -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Nov 19 14:04:10 2003 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 OAA03907 for ; Wed, 19 Nov 2003 14:04:10 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAJIxmI2015047; Wed, 19 Nov 2003 19:59:48 +0100 (MET) 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 XFF54K6W; Wed, 19 Nov 2003 19:59:48 +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 hAJIxYwg022083; Wed, 19 Nov 2003 19:59:34 +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 hAJIvSB5029214; Wed, 19 Nov 2003 19:57:28 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hAJIvSoQ029213; Wed, 19 Nov 2003 19:57:28 +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 hAJIvQB5029203 for ; Wed, 19 Nov 2003 19:57:27 +0100 (MET) Message-ID: <0a3d01c3aecf$052797d0$956015ac@dclkempt40> From: "James Kempf" To: Subject: Question on DCS/DCA Date: Wed, 19 Nov 2003 10:57:42 -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 Content-Transfer-Encoding: 7bit A question came up of whether Jon Wood's implementation used the RS/RA timing for DCS/DCA. I asked Jon and he said no, since the DCS/DCA is triggered by receipt of an RA for which the host doesn't have a cert chain. Thus, the original RS/RA achieves the proper timing. jak -------------------------------------------------------------------- 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 Thu Nov 20 18:24:24 2003 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 SAA07489 for ; Thu, 20 Nov 2003 18:24:24 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAKNKLI2012795; Fri, 21 Nov 2003 00:20:22 +0100 (MET) 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 XF16ZYMR; Fri, 21 Nov 2003 00:20: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 hAKNKHXA029799; Fri, 21 Nov 2003 00:20: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 hAKNF8B5000682; Fri, 21 Nov 2003 00:15:08 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hAKNF89h000663; Fri, 21 Nov 2003 00:15:08 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from smtp801.mail.ukl.yahoo.com (smtp801.mail.ukl.yahoo.com [217.12.12.138]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with SMTP id hAKNF7B5000577 for ; Fri, 21 Nov 2003 00:15:07 +0100 (MET) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp1.bt.mail.vip.ukl.yahoo.com with SMTP; 20 Nov 2003 23:15:06 -0000 Message-ID: <00fc01c3afbc$22687790$681067c0@adithya> From: "Mohan Parthasarathy" To: Subject: SEND with link-layer security Date: Thu, 20 Nov 2003 15:15:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit I have a question on section 11.1 of draft-ietf-send-ndopt-00. 11.1 Threats to the Local Link Not Covered by SEND SEND does not compensate for an insecure link layer. In particular, there is no cryptographic binding in SEND between the link layer frame address and the IPv6 address. On an insecure link layer that allows nodes to spoof the link layer address of other nodes, an attacker could disrupt IP service by sending out a Neighbor Advertisement having the source address on the link layer frame of a victim, a valid CGA address and a valid signature corresponding to itself, and a Target Link-layer Address extension corresponding to the victim. The attacker could then proceed to cause a traffic stream to bombard the victim in a DoS attack. To protect against such attacks, link layer security MUST be used. An example of such for 802 type networks is port-based access control defined in the 802.1X standard [34]. I am not sure how link-layer security helps. 802.1x will not check the target link-layer address option. It checks only the source address of the mac header. And IP layer does not check the source mac address and only checks the target link layer option. So, how does link layer security help this case ? thanks mohan -------------------------------------------------------------------- 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 Thu Nov 20 18:40:53 2003 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 SAA08135 for ; Thu, 20 Nov 2003 18:40:52 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAKNbVI2015266; Fri, 21 Nov 2003 00:37:31 +0100 (MET) 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 X16VSN4T; Fri, 21 Nov 2003 00:36:48 +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 hAKNbIwg013557; Fri, 21 Nov 2003 00:37:18 +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 hAKNYAB5005415; Fri, 21 Nov 2003 00:34:10 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hAKNYAp2005414; Fri, 21 Nov 2003 00:34:10 +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 hAKNY8B5005398 for ; Fri, 21 Nov 2003 00:34:09 +0100 (MET) Message-ID: <0fbc01c3afbe$d5945120$956015ac@dclkempt40> From: "James Kempf" To: "Mohan Parthasarathy" , References: <00fc01c3afbc$22687790$681067c0@adithya> Subject: Re: SEND with link-layer security Date: Thu, 20 Nov 2003 15:34:22 -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 Content-Transfer-Encoding: 7bit Mohan, I think this was one of the issues we resolved in the last round. Please check the issues page (http://users.piuha.net/jarkko/publications/send/issues/) and if that does not answer your question, repost it. Thanx. jak ----- Original Message ----- From: "Mohan Parthasarathy" To: Sent: Thursday, November 20, 2003 3:15 PM Subject: SEND with link-layer security > I have a question on section 11.1 of draft-ietf-send-ndopt-00. > > 11.1 Threats to the Local Link Not Covered by SEND > > SEND does not compensate for an insecure link layer. In particular, > there is no cryptographic binding in SEND between the link layer > frame address and the IPv6 address. On an insecure link layer that > allows nodes to spoof the link layer address of other nodes, an > attacker could disrupt IP service by sending out a Neighbor > Advertisement having the source address on the link layer frame of a > victim, a valid CGA address and a valid signature corresponding to > itself, and a Target Link-layer Address extension corresponding to > the victim. The attacker could then proceed to cause a traffic > stream to bombard the victim in a DoS attack. To protect against > such attacks, link layer security MUST be used. An example of such > for 802 type networks is port-based access control defined in the > 802.1X standard [34]. > > I am not sure how link-layer security helps. 802.1x will not check the > target link-layer address option. It checks only the source address > of the mac header. And IP layer does not check the source mac address > and only checks the target link layer option. So, how does link layer > security help this case ? > > thanks > mohan > -------------------------------------------------------------------- > 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 Thu Nov 20 20:43:49 2003 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 UAA13289 for ; Thu, 20 Nov 2003 20:43:48 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAL1fYI2000668; Fri, 21 Nov 2003 02:41:35 +0100 (MET) 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 XFF6N23J; Fri, 21 Nov 2003 02:41:34 +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 hAL1fXXA000826; Fri, 21 Nov 2003 02:41: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 hAL1cKB5005746; Fri, 21 Nov 2003 02:38:20 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hAL1cKbY005745; Fri, 21 Nov 2003 02:38:20 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from smtp800.mail.ukl.yahoo.com (smtp800.mail.ukl.yahoo.com [217.12.12.142]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with SMTP id hAL1cIB5005741 for ; Fri, 21 Nov 2003 02:38:18 +0100 (MET) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp1.bt.mail.vip.ukl.yahoo.com with SMTP; 21 Nov 2003 01:38:17 -0000 Message-ID: <012801c3afd0$22fc3c00$681067c0@adithya> From: "Mohan Parthasarathy" To: "James Kempf" , References: <00fc01c3afbc$22687790$681067c0@adithya> <0fbc01c3afbe$d5945120$956015ac@dclkempt40> Subject: Re: SEND with link-layer security Date: Thu, 20 Nov 2003 17:38:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > Mohan, > > I think this was one of the issues we resolved in the last round. Please > check the issues page > (http://users.piuha.net/jarkko/publications/send/issues/) and if that does > not answer your question, repost it. Thanx. > From what i can tell, it does not seem to answer the question. Unless you recommend the IP layer to cross check the source address of the mac header and the target link layer option AND you have 802.11i type security (that prevents mac address spoofing), this DoS attack cannot be prevented. But i remember some discussion in the past regarding why IP does not do the check. So, wihtout that, i don't see how this attack can be prevented. If my understanding is correct, the IP address ownership seems to solve the redirection attack problem i.e the attacker cannot redirect packets that are destined to some other address (that it does not own) to itself , but it still can cause flooding attacks by having the victim's mac address in the target link layer option of the NA. -mohan -mohan > jak > > ----- Original Message ----- > From: "Mohan Parthasarathy" > To: > Sent: Thursday, November 20, 2003 3:15 PM > Subject: SEND with link-layer security > > > > I have a question on section 11.1 of draft-ietf-send-ndopt-00. > > > > 11.1 Threats to the Local Link Not Covered by SEND > > > > SEND does not compensate for an insecure link layer. In particular, > > there is no cryptographic binding in SEND between the link layer > > frame address and the IPv6 address. On an insecure link layer that > > allows nodes to spoof the link layer address of other nodes, an > > attacker could disrupt IP service by sending out a Neighbor > > Advertisement having the source address on the link layer frame of a > > victim, a valid CGA address and a valid signature corresponding to > > itself, and a Target Link-layer Address extension corresponding to > > the victim. The attacker could then proceed to cause a traffic > > stream to bombard the victim in a DoS attack. To protect against > > such attacks, link layer security MUST be used. An example of such > > for 802 type networks is port-based access control defined in the > > 802.1X standard [34]. > > > > I am not sure how link-layer security helps. 802.1x will not check the > > target link-layer address option. It checks only the source address > > of the mac header. And IP layer does not check the source mac address > > and only checks the target link layer option. So, how does link layer > > security help this case ? > > > > thanks > > mohan > > -------------------------------------------------------------------- > > 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 -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Nov 21 02:23:53 2003 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 CAA03331 for ; Fri, 21 Nov 2003 02:23:53 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAL7LASs010024; Fri, 21 Nov 2003 08:21:11 +0100 (MET) 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 XF169YGN; Fri, 21 Nov 2003 08:21:16 +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 hAL7Kxwg025951; Fri, 21 Nov 2003 08:20:59 +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 hAL7HkB5003286; Fri, 21 Nov 2003 08:17:47 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hAL7HkSU003285; Fri, 21 Nov 2003 08:17:46 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep21-app.kolumbus.fi (fep21-0.kolumbus.fi [193.229.0.48]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id hAL7HjB5003281 for ; Fri, 21 Nov 2003 08:17:45 +0100 (MET) Received: from kolumbus.fi ([62.248.172.209]) by fep21-app.kolumbus.fi with ESMTP id <20031121071745.PSNG13518.fep21-app.kolumbus.fi@kolumbus.fi>; Fri, 21 Nov 2003 09:17:45 +0200 Message-ID: <3FBDBB14.5080408@kolumbus.fi> Date: Fri, 21 Nov 2003 09:13:24 +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: Mohan Parthasarathy CC: James Kempf , ietf-send@standards.ericsson.net Subject: Re: SEND with link-layer security References: <00fc01c3afbc$22687790$681067c0@adithya> <0fbc01c3afbe$d5945120$956015ac@dclkempt40> <012801c3afd0$22fc3c00$681067c0@adithya> In-Reply-To: <012801c3afd0$22fc3c00$681067c0@adithya> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Mohan, Thanks for your question. Inline: > I have a question on section 11.1 of draft-ietf-send-ndopt-00. > > 11.1 Threats to the Local Link Not Covered by SEND > > SEND does not compensate for an insecure link layer. In particular, > there is no cryptographic binding in SEND between the link layer > frame address and the IPv6 address. On an insecure link layer that > allows nodes to spoof the link layer address of other nodes, an > attacker could disrupt IP service by sending out a Neighbor > Advertisement having the source address on the link layer frame of a > victim, a valid CGA address and a valid signature corresponding to > itself, and a Target Link-layer Address extension corresponding to > the victim. The attacker could then proceed to cause a traffic > stream to bombard the victim in a DoS attack. To protect against > such attacks, link layer security MUST be used. An example of such > for 802 type networks is port-based access control defined in the > 802.1X standard [34]. > > I am not sure how link-layer security helps. 802.1x will not check the > target link-layer address option. It checks only the source address of > the mac header. And IP layer does not check the source mac address and > only checks the target link layer option. So, how does link layer > security help this case ? > > From what i can tell, it does not seem to > answer the question. Unless you recommend the IP layer to cross check > the source address of the mac header and the target link layer option > AND you have 802.11i type security (that prevents mac address > spoofing), this DoS attack cannot be prevented. But i remember some > discussion in the past regarding why IP does not do the check. So, > wihtout that, i don't see how this attack can be prevented. > > If my understanding is correct, the IP address ownership seems to > solve the redirection attack problem i.e the attacker cannot redirect > packets that are destined to some other address (that it does not own) > to itself , but it still can cause flooding attacks by having the > victim's mac address in the target link layer option of the NA. In issue 24 we discussed this: http://users.piuha.net/jarkko/publications/send/issues/issue24.txt This brought us the text that follows the part that you quoted. The first part of Section 11.1 seems to say (more on this later) that the layer 2 - 3 binding is covered when both SEND and L2 security are used; the second part of Section 11.1 seems to imply otherwise. I think the bottom line is the following: o L2 security such as 802.11i can indeed ensure that the right sender uses the given MAC address. o The specific attack mentioned in the beginning of 11.1 is that the attacker lies both about the L2 and the ND target address. *This* attack is in fact prevented by the use of L2SEC + SEND. So it only seemed that the text was inconsistent... o However, there's another attack which is *not* prevented: the attacker lies just about the ND target address. Since neither L2 or SEND checks the L2 information against L3 information, there's currently nothing that prevents this attack. o We have discussed the prevention of this attack in SEND, but it would require stacks to retain the L2 addresses of the packets until the packets are processed by ND. Folks felt that this of a too tough requirement. So now I have a few questions: 1. Given the above, what change would you Mohan like to make to 11.1 to clarify it? 2. Is everyone still comfortable with the fact that no one is doing the L2-L3 cross check? --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 Fri Nov 21 06:30:08 2003 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 GAA10236 for ; Fri, 21 Nov 2003 06:30:07 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hALBQsSs002940; Fri, 21 Nov 2003 12:26:59 +0100 (MET) 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 X16VXFQ4; Fri, 21 Nov 2003 12:26:02 +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 hALBQjwg007682; Fri, 21 Nov 2003 12:26: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 hALBNQB5000717; Fri, 21 Nov 2003 12:23:26 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hALBNQ7Z000716; Fri, 21 Nov 2003 12:23:26 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ftmail.lab.flarion.com (mail.flarion.com [63.103.94.23]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id hALBNPB5000712 for ; Fri, 21 Nov 2003 12:23:25 +0100 (MET) Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Fri, 21 Nov 2003 06:23:23 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F042019@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Jari Arkko'" , Mohan Parthasarathy Cc: James Kempf , ietf-send@standards.ericsson.net Subject: RE: SEND with link-layer security Date: Fri, 21 Nov 2003 06:23:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk > 2. Is everyone still comfortable with the fact that no > one is doing the L2-L3 cross check? => Although this is probably not as bad as the reverse case (someone steals another node's address) it still allows an attacker to flood another node onlink. I don't think it's increadibly significant but are there implementations out there that cannot acquire the sender's MAC address from their link layer (802.anything) driver? In any case this seems like an optimisation that can be done on a per implementation basis, so I'm wondering whether we should say that SEND does not allow for the L2-L3 cross check because I don't see an inherent obstacle in SEND here, just implementation issues local to the IP stack and the driver. Hesham **************************************************************************** ******************************************* This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. **************************************************************************** ******************************************* -------------------------------------------------------------------- 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 Fri Nov 21 09:06:18 2003 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 JAA13917 for ; Fri, 21 Nov 2003 09:06:17 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hALE31I2019855; Fri, 21 Nov 2003 15:03:05 +0100 (MET) 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 X16VYZ64; Fri, 21 Nov 2003 15:02:07 +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 hALE30XA012160; Fri, 21 Nov 2003 15:03: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 hALDxbB5005710; Fri, 21 Nov 2003 14:59:37 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hALDxbGQ005709; Fri, 21 Nov 2003 14:59:37 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mx.laposte.net (mx.laposte.net [81.255.54.11]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id hALDxaB5005690 for ; Fri, 21 Nov 2003 14:59:36 +0100 (MET) Received: from gbl-dhcp-198-236.europe.research.sun.com (194.2.198.236) by mx.laposte.net (6.0.053) (authenticated as julien.laganier@laposte.net) id 3FB343CE002A1CC8; Fri, 21 Nov 2003 11:36:30 +0100 From: Julien Laganier To: Pekka Nikander , SEND WG Subject: Re: An API question from Samita Date: Fri, 21 Nov 2003 11:35:01 +0100 User-Agent: KMail/1.5.3 Cc: Samita Chakrabarti References: <3FBB5330.3020904@ericsson.com> In-Reply-To: <3FBB5330.3020904@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200311211132.17035.julien.laganier@laposte.net> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 19 November 2003 12:25, Pekka Nikander wrote: > Following the discussion last week at Minneapolis, > Samita Chakrabarti wants to ask the working group > the following question: > > draft-chakrabarti-ipv6-addrselect-api-02.txt already has a mechanism > to choose CGA and NON-CGA source addresses by the application using > socket api. The SEND wg needs to decide whether such API is needed > for applications running on a SEND-node. Please send the decision on > this to the IPv6 wg alias - based on that we will update the address > selection API draft (which actually goes along with RFC3484). > > Please send your replies to the mailing list. The chairs > will summarize and post the summary also to the ipv6 mailing > list. As this API is now defined, it allows a SeND nodes to be configured with both CGA and non-CGA addresses (and source address selection always prefer a CGA over a non-CGA), but with the possibility for debugging tools to avoid the penalty incurred by CGA signature and validation by reversing the sense of this preference. The first examples coming to my mind are those of an administrator wanting to flood the network by: o ping ff02::1, or fping (parallel ping) while there's a huge number of on-link nodes. o spray (or flood) the network with UDP packets. OTOH, there's nod doubt that the same effect (avoid CGA signature and validation) can be achieved through a future dedicated API. But as the source address selection API draft is almost ready, mentions CGA without creating apparent conflicts, I think it's worth keeping CGA in it. What do folks thinks? Thanks, -- julien -------------------------------------------------------------------- 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 Fri Nov 21 09:14:05 2003 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 JAA14224 for ; Fri, 21 Nov 2003 09:14:04 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hALEBASs003850; Fri, 21 Nov 2003 15:11:10 +0100 (MET) 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 XF17F3G4; Fri, 21 Nov 2003 15:11: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 hALEAowg018756; Fri, 21 Nov 2003 15:10: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 hALE7vB5008290; Fri, 21 Nov 2003 15:07:57 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hALE7veL008289; Fri, 21 Nov 2003 15:07:57 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mx.laposte.net (mx.laposte.net [81.255.54.11]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id hALE7tB5008285 for ; Fri, 21 Nov 2003 15:07:56 +0100 (MET) Received: from gbl-dhcp-198-236.europe.research.sun.com (194.2.198.236) by mx.laposte.net (6.0.053) (authenticated as julien.laganier@laposte.net) id 3FBD083A000864D8; Fri, 21 Nov 2003 14:47:15 +0100 From: Julien Laganier To: Pekka Nikander , SEND WG Subject: Re: An API question from Samita Date: Fri, 21 Nov 2003 14:45:50 +0100 User-Agent: KMail/1.5.3 Cc: Samita Chakrabarti References: <3FBB5330.3020904@ericsson.com> In-Reply-To: <3FBB5330.3020904@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200311211445.50302.julien.laganier@laposte.net> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 19 November 2003 12:25, Pekka Nikander wrote: > Following the discussion last week at Minneapolis, > Samita Chakrabarti wants to ask the working group > the following question: > > draft-chakrabarti-ipv6-addrselect-api-02.txt already has a mechanism > to choose CGA and NON-CGA source addresses by the application using > socket api. The SEND wg needs to decide whether such API is needed > for applications running on a SEND-node. Please send the decision on > this to the IPv6 wg alias - based on that we will update the address > selection API draft (which actually goes along with RFC3484). > > Please send your replies to the mailing list. The chairs > will summarize and post the summary also to the ipv6 mailing > list. As this API is now defined, it allows a SeND nodes to be configured with both CGA and non-CGA addresses (and source address selection always prefer a CGA over a non-CGA), but with the possibility for debugging tools to avoid the penalty incurred by CGA signature and validation by reversing the sense of this preference. The first examples coming to my mind are those of an administrator wanting to flood the network by: o ping ff02::1, or fping (parallel ping) while there's a huge number of on-link nodes. o spray (or flood) the network with UDP packets. OTOH, there's nod doubt that the same effect (avoid CGA signature and validation) can be achieved through a future dedicated API. But as the source address selection API draft is almost ready, mentions CGA without creating apparent conflicts, I think it's worth keeping CGA in it. What do folks thinks? Thanks, -- julien -------------------------------------------------------------------- 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 Fri Nov 21 12:53:21 2003 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 MAA24501 for ; Fri, 21 Nov 2003 12:53:20 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hALHoxSs001460; Fri, 21 Nov 2003 18:50:59 +0100 (MET) 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 XF1728VM; Fri, 21 Nov 2003 18:51: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 hALHotwg010422; Fri, 21 Nov 2003 18:50: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 hALHlhB5027964; Fri, 21 Nov 2003 18:47:43 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hALHlhuk027963; Fri, 21 Nov 2003 18:47:43 +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 hALHlfB5027959 for ; Fri, 21 Nov 2003 18:47:41 +0100 (MET) Message-ID: <109e01c3b057$9800f9f0$956015ac@dclkempt40> From: "James Kempf" To: "Jari Arkko" , "Mohan Parthasarathy" Cc: References: <00fc01c3afbc$22687790$681067c0@adithya> <0fbc01c3afbe$d5945120$956015ac@dclkempt40> <012801c3afd0$22fc3c00$681067c0@adithya> <3FBDBB14.5080408@kolumbus.fi> Subject: Re: SEND with link-layer security Date: Fri, 21 Nov 2003 09:47:55 -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 Content-Transfer-Encoding: 7bit > 2. Is everyone still comfortable with the fact that no > one is doing the L2-L3 cross check? > Might be worthwhile to mention it SHOULD be done in order to prevent the attack. jak -------------------------------------------------------------------- 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 Fri Nov 21 12:57:20 2003 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 MAA24663 for ; Fri, 21 Nov 2003 12:57:20 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hALHsdSs002126; Fri, 21 Nov 2003 18:54:39 +0100 (MET) 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 XFF661XD; Fri, 21 Nov 2003 18:54:39 +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 hALHsZXA006837; Fri, 21 Nov 2003 18:54:35 +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 hALHpjB5028670; Fri, 21 Nov 2003 18:51:45 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hALHpj6G028669; Fri, 21 Nov 2003 18:51:45 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from smtp805.mail.sc5.yahoo.com (smtp805.mail.sc5.yahoo.com [66.163.168.184]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with SMTP id hALHphB5028662 for ; Fri, 21 Nov 2003 18:51:43 +0100 (MET) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 21 Nov 2003 17:51:42 -0000 Message-ID: <001301c3b058$202e1f10$681067c0@adithya> From: "Mohan Parthasarathy" To: "Jari Arkko" Cc: "James Kempf" , References: <00fc01c3afbc$22687790$681067c0@adithya> <0fbc01c3afbe$d5945120$956015ac@dclkempt40> <012801c3afd0$22fc3c00$681067c0@adithya> <3FBDBB14.5080408@kolumbus.fi> Subject: Re: SEND with link-layer security Date: Fri, 21 Nov 2003 09:51:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > > From what i can tell, it does not seem to > > answer the question. Unless you recommend the IP layer to cross check > > the source address of the mac header and the target link layer option > > AND you have 802.11i type security (that prevents mac address > > spoofing), this DoS attack cannot be prevented. But i remember some > > discussion in the past regarding why IP does not do the check. So, > > wihtout that, i don't see how this attack can be prevented. > > > > If my understanding is correct, the IP address ownership seems to > > solve the redirection attack problem i.e the attacker cannot redirect > > packets that are destined to some other address (that it does not own) > > to itself , but it still can cause flooding attacks by having the > > victim's mac address in the target link layer option of the NA. > > In issue 24 we discussed this: > http://users.piuha.net/jarkko/publications/send/issues/issue24.txt > This brought us the text that follows the part that you quoted. > > The first part of Section 11.1 seems to say (more on this later) > that the layer 2 - 3 binding is covered when both SEND and L2 security > are used; the second part of Section 11.1 seems to imply otherwise. > Yeah. But the second part was not very clear. > I think the bottom line is the following: > > o L2 security such as 802.11i can indeed ensure that the right > sender uses the given MAC address. > > o The specific attack mentioned in the beginning of 11.1 > is that the attacker lies both about the L2 and the ND target > address. *This* attack is in fact prevented by the use of > L2SEC + SEND. So it only seemed that the text was inconsistent... > > o However, there's another attack which is *not* prevented: > the attacker lies just about the ND target address. > Since neither L2 or SEND checks the L2 information against > L3 information, there's currently nothing that prevents > this attack. > Agreed. > o We have discussed the prevention of this attack in SEND, > but it would require stacks to retain the L2 addresses > of the packets until the packets are processed by ND. > Folks felt that this of a too tough requirement. > > So now I have a few questions: > > 1. Given the above, what change would you Mohan like to > make to 11.1 to clarify it? > Yes, i am looking for a clarification. It would make it clear as to what SEND protects. > 2. Is everyone still comfortable with the fact that no > one is doing the L2-L3 cross check? > I just re-read Pekka's summary on this issue. There were many reasons why it is not done. And Erik responded saying that in some cases it even provides flexibility like in bridging or even in some cases where there is no actual link-layer address. So, i am not sure how feasible this is. But it might be worth recommending. -mohan > --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 Nov 26 11:54:46 2003 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 LAA17030 for ; Wed, 26 Nov 2003 11:54:46 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAQGpVSs013119; Wed, 26 Nov 2003 17:51:32 +0100 (MET) 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 XTF0HYGQ; Wed, 26 Nov 2003 17:51: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 hAQGoQwg014849; Wed, 26 Nov 2003 17:50:26 +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 hAQGhxIt008635; Wed, 26 Nov 2003 17:43:59 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hAQGhxW8008634; Wed, 26 Nov 2003 17:43:59 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from i2kc02-ukbr.domain1.systemhost.net (smtp2.smtp.bt.com [217.32.164.150]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id hAQGhwIt008600 for ; Wed, 26 Nov 2003 17:43:58 +0100 (MET) Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by i2kc02-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 16:43:47 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 16:43:47 +0000 x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: SEND with link-layer security Date: Wed, 26 Nov 2003 16:43:14 -0000 Message-ID: <0AAF93247C75E3408638B965DEE11A7003EFED91@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: SEND with link-layer security Thread-Index: AcOwWIwpsYN2jgHFQemsDW7/atlcjgD4xm0Q From: To: X-OriginalArrivalTime: 26 Nov 2003 16:43:47.0303 (UTC) FILETIME=[76581F70:01C3B43C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id hAQGhwIt008630 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit While reading and thinking about this thread, a question occurred to me. Section 11.1 of draft-ietf-send-ndopt-00 states: For shared media, such as multiple nodes authenticated through the same 802.11 AP (which acts as a single port for all nodes), other measures [than 802.1x] are necessary [to prevent against specific attacks]... What 'other measures' are there, and would it be worth mentioning them explicitly in this section of the document? Mat -------------------------------------------------------------------- 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 Nov 26 12:52:57 2003 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 MAA19528 for ; Wed, 26 Nov 2003 12:52:56 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAQHpDSs026797; Wed, 26 Nov 2003 18:51:14 +0100 (MET) 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 XTF71NHL; Wed, 26 Nov 2003 18:51:19 +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 hAQHpCXA011651; Wed, 26 Nov 2003 18:51:12 +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 hAQHlnIt024554; Wed, 26 Nov 2003 18:47:49 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hAQHln14024553; Wed, 26 Nov 2003 18:47: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 hAQHllIt024549 for ; Wed, 26 Nov 2003 18:47:48 +0100 (MET) Message-ID: <010101c3b445$729d9960$956015ac@dclkempt40> From: "James Kempf" To: , References: <0AAF93247C75E3408638B965DEE11A7003EFED91@i2km41-ukdy.domain1.systemhost.net> Subject: Re: SEND with link-layer security Date: Wed, 26 Nov 2003 09:48:05 -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 Content-Transfer-Encoding: 7bit > While reading and thinking about this thread, a question occurred to me. > Section 11.1 of draft-ietf-send-ndopt-00 states: > > For shared media, such as multiple nodes authenticated through > the same 802.11 AP (which acts as a single port for all nodes), > other measures [than 802.1x] are necessary [to prevent against > specific attacks]... > > What 'other measures' are there, and would it be worth mentioning them > explicitly in this section of the document? > I'm wondering now whether we should take out this paragraph and the next, and the last sentence in the previous paragraph. I don't believe the SEND spec should be making specific recommendations about how people should deploy 802.11 security. I think it should be sufficient to say what the first paragraph says, namely that SEND does not protect against attacks at the link layer - full stop - and leave it up to the link layer specification to say how the link layer is secured and how to deploy that security. We could add a sentence at the end of the first paragraph that says, in effect, consult the link layer specification for information about how to secure the link layer. Comments? jak -------------------------------------------------------------------- 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 Sun Nov 30 15:48:25 2003 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 PAA12978 for ; Sun, 30 Nov 2003 15:48:23 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAUKgqSs024736; Sun, 30 Nov 2003 21:42:53 +0100 (MET) 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 XW6W5WNP; Sun, 30 Nov 2003 21:43: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 hAUKgkwg029239; Sun, 30 Nov 2003 21:42:48 +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 hAUKcxIt023107; Sun, 30 Nov 2003 21:38:59 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id hAUKcxGg023106; Sun, 30 Nov 2003 21: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 noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id hAUKcvIt023090 for ; Sun, 30 Nov 2003 21:38:58 +0100 (MET) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hAUKcft10934 for ; Sun, 30 Nov 2003 15:38:41 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hAUKg4V24515 for ; Sun, 30 Nov 2003 15:42:04 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hAUKXkpH013591 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 30 Nov 2003 15:33:46 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hAUKXjnR013587 for ; Sun, 30 Nov 2003 15:33:46 -0500 To: ietf-send@standards.ericsson.net Subject: Re: SEND with link-layer security In-reply-to: Your message of "Wed, 26 Nov 2003 09:48:05 PST." <010101c3b445$729d9960$956015ac@dclkempt40> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sun, 30 Nov 2003 15:33:45 -0500 Message-ID: <13586.1070224425@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I believe that there are significant issues if we do not eventually work on ways to bind link layer security (1x) and network layer security (SEND). ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP8pUJ4qHRg3pndX9AQE9bgQAx/OL56gzcmSCSosUjvvdYd3O6w25uy6R 8IoSvvHHnL+x2FNA4C/c0QR+bB9TwxX6AGnehU4wmMkpSqtpEVUWGa7RqYQdp1M2 rmImcdF02zo8BBmqU/gFGL6+nxJF5c+w31DDn7EQzRr81aFeX3loatRQpUJsdy6H I/60N6erjtk= =5ICH -----END PGP SIGNATURE----- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html --------------------------------------------------------------------