From jari.arkko@lmf.ericsson.se Tue Mar 4 07:14:02 2003 Received: from condor.wise.edt.ericsson.se (condor-ext.wise.edt.ericsson.se [193.180.251.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13882 for ; Tue, 4 Mar 2003 07:14:02 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by condor.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h24CEjA1015866; Tue, 4 Mar 2003 13:14:46 +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.2655.55) id FDVL6293; Tue, 4 Mar 2003 13:14:45 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h24CEj204041; Tue, 4 Mar 2003 13:14:45 +0100 (MET) Received: (from ietfmdomo@localhost) by sw.ericsson.se (8.8.8+Sun/8.8.8/unixcenter-xnet-1.0) id NAA01305; Tue, 4 Mar 2003 13:14:20 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mine.at (chello080108141189.9.12.vie.surfer.at [80.108.141.189]) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with SMTP id NAA01297 for ; Tue, 4 Mar 2003 13:14:09 +0100 (MET) From: ted@mine.at Message-ID: To: hithere@prdxweb.sw.ericsson.se Subject: Use your COMPUTER to create a PAYCHECK Date: Tue, 04 Mar 2003 23:09:17 -1100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 Content-Transfer-Encoding: 8bit Sender: owner-ietf-send@prdxweb.sw.ericsson.se Precedence: bulk Content-Transfer-Encoding: 8bit Hello - You get emails every day, offering to show you how to make money. Most of these emails are from people who are NOT making any money. And they expect you to listen to them? Enough. If you want to make money with your computer, then you should hook up with a group that is actually DOING it. We are making a large, continuing income every month. What's more - we will show YOU how to do the same thing. This business is done completely by internet and email, and you can even join for free to check it out first. If you can send an email, you can do this. No special "skills" are required. We are real people, and most of us work at this business part-time. But keep in mind, we do WORK at it - I am not going to insult your intelligence by saying you can sign up, do no work, and rake in the cash. That kind of job does not exist. But if you are willing to put in 10-12 hours per week, this might be just the thing you are looking for. This is not income that is determined by luck, or work that is done FOR you - it is all based on your effort. But, as I said, there are no special skills required. And this income is RESIDUAL - meaning that it continues each month (and it tends to increase each month also). Interested? I invite you to find out more. You can get in as a free member, at no cost, and no obligation to continue if you decide it is not for you. We are just looking for people who still have that "burning desire" to find an opportunity that will reward them incredibly well, if they work at it. To grab a FREE ID#, simply reply to: mailto:ted@mine.at or click on this link mailto:ted@mine.at?subject=Grab%20me%20an%20id!&body=Grab%20me%20a%20free%20membership and in the body of the email, write this phrase: "Grab me a free membership!" Be sure to include your: 1. First name 2. Last name 3. Email address (if different from above) We will confirm your position and send you a special report as soon as possible, and also Your free Member Number. That's all there's to it. We'll then send you info, and you can make up your own mind. Looking forward to hearing from you! Sincerely, Edward(Ted) Simpson Don't pass this up..you can sign up and test-drive the program for FREE. All you need to do is get your free membership. Unsubscribing: Send a blank email to: mailto:ted@mine.at with "Remove" in the subject line. or click here mailto:ted@mine.at?subject=Remove 9831gxdr6-693oexz0948bkvC5-222yMuC7429RYWM3-806oGxO2378NWah2-796IiLP9160PscYl72 -------------------------------------------------------------------- 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 Mar 7 07:46:46 2003 Received: from albatross.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 HAA27717 for ; Fri, 7 Mar 2003 07:46:46 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h27CjUB3008972; Fri, 7 Mar 2003 13:45:30 +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.2655.55) id FDVM5ADN; Fri, 7 Mar 2003 13:45:30 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h27CjT208933; Fri, 7 Mar 2003 13:45:29 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h27CiQYl009984; Fri, 7 Mar 2003 13:44:26 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h27CiQw1009983; Fri, 7 Mar 2003 13:44:26 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from albatross.wise.edt.ericsson.se ([193.180.251.49]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h27CiPYl009976 for ; Fri, 7 Mar 2003 13:44:25 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h26ErTB4001536 for ; Thu, 6 Mar 2003 15:53:30 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 6 Mar 2003 15:53:19 +0100 Message-ID: From: "Jari Arkko (LMF)" To: "'ietf-send@standards.ericsson.net'" Subject: two somewhat SEND-related drafts Date: Thu, 6 Mar 2003 15:53:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Just for your information, The IPv6 WG is discussing some solutions to use router advertisements to deliver information about which addresses are "within our network" and which are not. This would be used, for instance, by printers to limit services to those nodes within the organization's network. This is not exactly the protection ND, but the use of ND to protect something else. "Organization Zone Prefix Length Discovery" http://www.ietf.org/internet-drafts/draft-zill-ipv6wg-zone-prefixlen-00.txt "Access Control Prefix Router Advertisement Option for IPv6" http://www.ietf.org/internet-drafts/draft-bellovin-ipv6-accessprefix-01.txt 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 Mar 7 09:43:51 2003 Received: from albatross.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 JAA05819 for ; Fri, 7 Mar 2003 09:43:50 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h27EhNB3013334; Fri, 7 Mar 2003 15:43:23 +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.2655.55) id FDVM6CMJ; Fri, 7 Mar 2003 15:43:23 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h27EhM215240; Fri, 7 Mar 2003 15:43:22 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h27Eh3Yl024123; Fri, 7 Mar 2003 15:43:03 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h27Eh3QV024122; Fri, 7 Mar 2003 15:43:03 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h27Eh1Yl024118 for ; Fri, 7 Mar 2003 15:43:01 +0100 (MET) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id E039F1C; Fri, 7 Mar 2003 16:53:09 +0200 (EET) Message-ID: <3E68AFFE.8010007@nomadiclab.com> Date: Fri, 07 Mar 2003 16:43:10 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030220 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG , Craig Metz , Viday Devarapalli , Alper Yegin , Pekka Savola Subject: Resolving issues to draft-psreq raised during the WG LC 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 Thanks to Viday, Bill, Alper, Pekka S., Craig, Greg, Dave, and others, for your comments during the WG LC of draft-ietf-send-psreq-01.txt. I have compiled a list of issues raised during the WG last call (The list does not include editorial issues; I'll just adopt those). The list is available at http://www.tml.hut.fi/~pnr/SEND/issues.html Please check that your issues have been accurately recorded, and please mail me if something is missing. I will start going through these issues during the following days so that we would get most of them resolved before San Francisco. --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 Fri Mar 7 09:53:42 2003 Received: from albatross.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 JAA07126 for ; Fri, 7 Mar 2003 09:53:42 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h27Er8B3016031; Fri, 7 Mar 2003 15:53:08 +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.2655.55) id FDVM61H7; Fri, 7 Mar 2003 15:53:07 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h27Er6K05195; Fri, 7 Mar 2003 15:53:06 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h27EqxYl025675; Fri, 7 Mar 2003 15:52:59 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h27EqxXb025674; Fri, 7 Mar 2003 15:52:59 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h27EqwYl025670 for ; Fri, 7 Mar 2003 15:52:58 +0100 (MET) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 518D31C for ; Fri, 7 Mar 2003 17:03:07 +0200 (EET) Message-ID: <3E68B254.4090201@nomadiclab.com> Date: Fri, 07 Mar 2003 16:53:08 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030220 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: psreq issue#1: Should draft-psreq discuss solutions at all? 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 Many of the issues raised during the WG LC were somehow concerned with solutions. In fact, quite a few seemed to be concerned that the draft discusses solutions at all; some people expressed the strong opinion that it should not. In the draft, we currently state the following about solutions: > This document occasionally discusses solution proposals, such as CGA > [9] and ABK [8]. However, the discussion is solely for illustrative > purposes. It is meant to give the readers a more concrete idea of > some possible solutions. It does NOT indicate any preference on > solutions on the behalf of the authors or the working group. One reason for including any text about solutions is to make the draft more readable. Reading problem descriptions without any ideas on how to *possibly* solve them is very frustrating, at least to me personally. Another reason for including the text is to give the WG some idea of what is probably doable in a reasonable amount of time, and what are more likely to be research problems, requiring very long time to solve, if solvable at all with current technology. It is certainly easy to remove all text concerning solutions, but I am afraid that the readability of the draft would suffer. On the other hand, if text is added about the pros/cons of all solutions, the draft may become excessive long (see issues #3, #6, #7, #9, #18, #19, #21, #22). Now, on the light of this, I am solicitating well grounded opinions on whether the next version of the draft should include any text about solutions? If no, should the existing text be just removed or should something else to be done to it. If yes, is the existing level of illustrative talk about solutions appropriate, or should there be more/less text? Additionally, if yes, should there be more informative references to the possible solution approaches, or is the current practice of mentioning or briefly describing the solution approaches appropriate? --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 Fri Mar 7 10:35:33 2003 Received: from penguin.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 KAA11107 for ; Fri, 7 Mar 2003 10:35:32 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h27FJTwv020247; Fri, 7 Mar 2003 16:19:29 +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.2655.55) id FD4JTD70; Fri, 7 Mar 2003 16:19:29 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h27FJSK16359; Fri, 7 Mar 2003 16:19:28 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h27FJ6Yl029035; Fri, 7 Mar 2003 16:19:06 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h27FJ6PV029034; Fri, 7 Mar 2003 16:19:06 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from penguin.wise.edt.ericsson.se ([193.180.251.47]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h27FJ5Yl029030 for ; Fri, 7 Mar 2003 16:19:05 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h26BPuwv002699 for ; Thu, 6 Mar 2003 12:25:56 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 6 Mar 2003 12:25:50 +0100 Message-ID: From: "Jari Arkko (LMF)" To: "'ietf-send@standards.ericsson.net'" Subject: send background material Date: Thu, 6 Mar 2003 12:25:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Hi, I just thought I'd let you know that I've updated two drafts related to the background of SEND: "Manual Configuration of Security Associations for IPv6 Neighbor Discovery" This draft documents how you can use manually keyed IPsec to protect ND. It also states that this is possible on a very limited scale, due to the number of SAs involved and the lack of applicability to public access networks (where SEND results are needed). http://www.piuha.net/~jarkko/publications/send/drafts/draft-arkko-manual-icmpv6-sas-02.html http://www.piuha.net/~jarkko/publications/send/drafts/draft-arkko-manual-icmpv6-sas-02.txt "Effects of ICMPv6 on IKE" This draft documents the chicken-and-egg issues and how to avoid them when IKE is used. As a side effect, ND messages have to be left unprotected at least as far as IKE-based SAs are concerned. http://www.piuha.net/~jarkko/publications/send/drafts/draft-arkko-icmpv6-ike-effects-02.html http://www.piuha.net/~jarkko/publications/send/drafts/draft-arkko-icmpv6-ike-effects-02.txt -------------------------------------------------------------------- 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 Mar 7 12:14:24 2003 Received: from albatross.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 MAA17613 for ; Fri, 7 Mar 2003 12:14:23 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h27HDfB3015210; Fri, 7 Mar 2003 18:13: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.2655.55) id FDVM7BMJ; Fri, 7 Mar 2003 18:13:41 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h27HDeK22985; Fri, 7 Mar 2003 18:13:40 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h27HDEYl011392; Fri, 7 Mar 2003 18:13:14 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h27HDEaG011391; Fri, 7 Mar 2003 18:13:14 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h27HDBYl011384 for ; Fri, 7 Mar 2003 18:13:12 +0100 (MET) Message-ID: <00cb01c2e4cc$9bd95c90$156015ac@T23KEMPF> From: "James Kempf" To: "Pekka Nikander" , "SEND WG" References: <3E68B254.4090201@nomadiclab.com> Subject: Re: psreq issue#1: Should draft-psreq discuss solutions at all? Date: Fri, 7 Mar 2003 09:11: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 I think the draft would read better without the solutions discussion in it. While I think it makes sense to talk about solutions when formulating a problem statement (because some people typically have an easier time precisely specifying the problem that way), I think the problem statement itself should not include solutions. jak ----- Original Message ----- From: "Pekka Nikander" To: "SEND WG" Sent: Friday, March 07, 2003 6:53 AM Subject: psreq issue#1: Should draft-psreq discuss solutions at all? > Many of the issues raised during the WG LC were > somehow concerned with solutions. In fact, quite > a few seemed to be concerned that the draft > discusses solutions at all; some people expressed > the strong opinion that it should not. > > In the draft, we currently state the following about > solutions: > > > This document occasionally discusses solution proposals, such as CGA > > [9] and ABK [8]. However, the discussion is solely for illustrative > > purposes. It is meant to give the readers a more concrete idea of > > some possible solutions. It does NOT indicate any preference on > > solutions on the behalf of the authors or the working group. > > One reason for including any text about solutions > is to make the draft more readable. Reading problem > descriptions without any ideas on how to *possibly* > solve them is very frustrating, at least to me personally. > > Another reason for including the text is to give the > WG some idea of what is probably doable in a reasonable > amount of time, and what are more likely to be research > problems, requiring very long time to solve, if solvable > at all with current technology. > > It is certainly easy to remove all text concerning > solutions, but I am afraid that the readability of the > draft would suffer. On the other hand, if text is > added about the pros/cons of all solutions, the draft > may become excessive long (see issues #3, #6, #7, #9, > #18, #19, #21, #22). > > Now, on the light of this, I am solicitating well grounded > opinions on whether the next version of the draft should > include any text about solutions? > > If no, should the existing text be just removed or should > something else to be done to it. > > If yes, is the existing level of illustrative talk about > solutions appropriate, or should there be more/less > text? > > Additionally, if yes, should there be more informative > references to the possible solution approaches, or is the > current practice of mentioning or briefly describing the > solution approaches appropriate? > > --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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 Mar 7 13:57:14 2003 Received: from albatross.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 NAA23011 for ; Fri, 7 Mar 2003 13:57:13 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h27IjxB3024435; Fri, 7 Mar 2003 19:45: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.2655.55) id FDVM7N3Q; Fri, 7 Mar 2003 19:45:59 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h27IjvK25289; Fri, 7 Mar 2003 19:45:57 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h27IjbYl022366; Fri, 7 Mar 2003 19:45:37 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h27Ijb7c022365; Fri, 7 Mar 2003 19:45:37 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h27IjZYl022361 for ; Fri, 7 Mar 2003 19:45:36 +0100 (MET) Message-ID: <01ba01c2e4d9$864a2f00$156015ac@T23KEMPF> From: "James Kempf" To: Subject: Proxy ND? Date: Fri, 7 Mar 2003 10:44:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit A quiet IETF mailing list two weeks before a meeting is a real luxury, so I am reluctant to distrurb the peace, but here goes. Anybody want to describe how to secure Proxy ND? The CGA address gives the recipient of the NA the assurance that the sender is authorized for the source address, but not the target address in the packet. 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 Mar 7 15:11:06 2003 Received: from penguin.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 PAA26906 for ; Fri, 7 Mar 2003 15:11:05 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h27K7Gwv023034; Fri, 7 Mar 2003 21:07:17 +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.2655.55) id FDVM7YF2; Fri, 7 Mar 2003 21:07:16 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h27K7F210784; Fri, 7 Mar 2003 21:07:16 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h27K6qYl001238; Fri, 7 Mar 2003 21:06:52 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h27K6qP5001237; Fri, 7 Mar 2003 21:06:52 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h27K6pYl001233 for ; Fri, 7 Mar 2003 21:06:51 +0100 (MET) Received: from kolumbus.fi ([62.248.146.9]) by fep01-app.kolumbus.fi with ESMTP id <20030307200651.KUMU639.fep01-app.kolumbus.fi@kolumbus.fi>; Fri, 7 Mar 2003 22:06:51 +0200 Message-ID: <3E68FBAB.9070005@kolumbus.fi> Date: Fri, 07 Mar 2003 22:06:03 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: ietf-send@standards.ericsson.net Subject: Re: Proxy ND? References: <01ba01c2e4d9$864a2f00$156015ac@T23KEMPF> In-Reply-To: <01ba01c2e4d9$864a2f00$156015ac@T23KEMPF> 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 James Kempf wrote: > A quiet IETF mailing list two weeks before a meeting is a real luxury, so I am > reluctant to distrurb the peace, but here goes. > > Anybody want to describe how to secure Proxy ND? The CGA address gives the > recipient of the NA the assurance that the sender is authorized for the source > address, but not the target address in the packet. Good question. Technically, if the proxy and the true owner of the address share a security association (as in MIPv6), this node could give an authorization cert to the proxy. The proxy NA would carry the following information: - PKnode (as usual) - target address, where IID = hash(PKnode,...) (as usual) - cert for PKproxy, signed by SKnode (this is new) - signature of the NA, signed by SKproxy (new signer) 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 Mar 7 15:20:21 2003 Received: from penguin.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 PAA27366 for ; Fri, 7 Mar 2003 15:20:20 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h27KJQwv023917; Fri, 7 Mar 2003 21:19:26 +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.2655.55) id FDVM7ZQ2; Fri, 7 Mar 2003 21:19:25 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h27KJP211226; Fri, 7 Mar 2003 21:19:25 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h27KJ5Yl002775; Fri, 7 Mar 2003 21:19:05 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h27KJ5bZ002774; Fri, 7 Mar 2003 21:19:05 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h27KJ4Yl002770 for ; Fri, 7 Mar 2003 21:19:04 +0100 (MET) Received: from kolumbus.fi ([62.248.146.9]) by fep01-app.kolumbus.fi with ESMTP id <20030307201904.KVML639.fep01-app.kolumbus.fi@kolumbus.fi>; Fri, 7 Mar 2003 22:19:04 +0200 Message-ID: <3E68FE88.4090908@kolumbus.fi> Date: Fri, 07 Mar 2003 22:18:16 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander CC: SEND WG Subject: Re: psreq issue#1: Should draft-psreq discuss solutions at all? References: <3E68B254.4090201@nomadiclab.com> In-Reply-To: <3E68B254.4090201@nomadiclab.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 Pekka Nikander wrote: > Many of the issues raised during the WG LC were > somehow concerned with solutions. In fact, quite > a few seemed to be concerned that the draft > discusses solutions at all; some people expressed > the strong opinion that it should not. > > In the draft, we currently state the following about > solutions: > >> This document occasionally discusses solution proposals, such as CGA >> [9] and ABK [8]. However, the discussion is solely for illustrative >> purposes. It is meant to give the readers a more concrete idea of >> some possible solutions. It does NOT indicate any preference on >> solutions on the behalf of the authors or the working group. I'm fine with this text actually. Maybe you could add to the last sentence something about the two solutions not being an exhaustive list just to underline your point. 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 Mar 7 17:03:17 2003 Received: from albatross.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 RAA08253 for ; Fri, 7 Mar 2003 17:03:16 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h27M2uB3011940; Fri, 7 Mar 2003 23:02:57 +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.2655.55) id FDVM8F4Y; Fri, 7 Mar 2003 23:02:56 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h27M2sK00774; Fri, 7 Mar 2003 23:02:54 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h27M2OYl014497; Fri, 7 Mar 2003 23:02:24 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h27M2O3w014496; Fri, 7 Mar 2003 23:02:24 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h27M2MYl014486 for ; Fri, 7 Mar 2003 23:02:23 +0100 (MET) Message-ID: <00c901c2e4f5$016baef0$156015ac@T23KEMPF> From: "James Kempf" To: "Jari Arkko" Cc: References: <01ba01c2e4d9$864a2f00$156015ac@T23KEMPF> <3E68FBAB.9070005@kolumbus.fi> Subject: Re: Proxy ND? Date: Fri, 7 Mar 2003 14:00: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 > Technically, if the proxy and the true owner of the address share a > security association (as in MIPv6), this node could give an authorization > cert to the proxy. The proxy NA would carry the following information: > > - PKnode (as usual) > - target address, where IID = hash(PKnode,...) (as usual) I think you mean: > PKnode (as usual) > source address, where IID=hash(PKnode,...) (as usual) or? (see below for rest). > - cert for PKproxy, signed by SKnode (this is new) Is this an X.509 cert? If so, it might be pretty big. Also, I think it has to contain the PK of the SKnode, otherwise the receiver can't check the CGA on the target address. > - signature of the NA, signed by SKproxy (new signer) > and here: > target address, where IID=hash(SKnode,...) 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 Mar 7 20:11:52 2003 Received: from albatross.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 UAA23647 for ; Fri, 7 Mar 2003 20:11:51 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2819KB3028858; Sat, 8 Mar 2003 02:09:20 +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.2655.55) id GPHZZ9PN; Sat, 8 Mar 2003 02:09:19 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2819IK05967; Sat, 8 Mar 2003 02:09:18 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2818oYl007640; Sat, 8 Mar 2003 02:08:50 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2818oa8007639; Sat, 8 Mar 2003 02:08:50 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from sunlong.com ([202.105.130.36]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with SMTP id h2818jYl007633 for ; Sat, 8 Mar 2003 02:08:47 +0100 (MET) Received: from yahoo.com([62.188.49.8]) by sunlong.com(JetMail 2.5.3.0) with SMTP id jme13e69859c; Sat, 8 Mar 2003 01:05:38 -0000 Message-ID: <00005b99216a$00005b74$00007fbb@yahoo.com> To: From: qa_tindell@yahoo.com Subject: Re: A Healthy Work Environment12921 Date: Fri, 07 Mar 2003 20:08:20 -1700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Reply-To: qa_tindell@yahoo.com Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Good-bye office politics, stressfull commutes... Get a 5-6 figure annual income, earning $2,000-$12,000 monthly, working independently Part-Time/Full-Time. Read further and request more info... Enjoy: ---5-6 figure first year earning potential ---$10,000 monthly or more possible ---New marketing system from successful 8 year old company you can operate from anywhere. ---Make $1,000-$3,000 per sale. ---Pre-sold customers call you direct. Customers pay you direct. ---Residual income ---Spectacular benefits ---A fun business Say good-bye to: ---Long workdays ---Miserable commutes ---Corporate politics ---Employee hassles ---Franchise red tape ---Network marketing non-sense ---Inventory to purchase and store ---Periodic purchase requirements ---Cold-calling, expensive advertising, pressure selling ---Big Start-up costs What does it take to succeed? ---Standard home office equipment: telephone, fax, computer ---Work ---Being reasonably well-organized ---Big business mind-set ---Focus ---Belief in yourself and your potential So break free now--- Learn more today! Respond to: lori.katz@talk21.com say "Provide Data" ! -------------------------------------------------------------------- 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 Sat Mar 8 03:08:35 2003 Received: from penguin.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 DAA11965 for ; Sat, 8 Mar 2003 03:08:34 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2887swv011771; Sat, 8 Mar 2003 09:07:54 +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.2655.55) id GPH20FCP; Sat, 8 Mar 2003 09:07:54 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2887r225845; Sat, 8 Mar 2003 09:07:53 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2887HYl026490; Sat, 8 Mar 2003 09:07:17 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2887Hmi026489; Sat, 8 Mar 2003 09:07:17 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2887FYl026485 for ; Sat, 8 Mar 2003 09:07:15 +0100 (MET) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2887FM01723 for ; Sat, 8 Mar 2003 10:07:15 +0200 Date: Sat, 8 Mar 2003 10:07:15 +0200 (EET) From: Pekka Savola To: ietf-send@standards.ericsson.net Subject: Send protocol and CGA Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Hello, The send protocol spec is quite well written (a lot of comments in the queue in a separate mail), but there is one really imporant aspect I'd like the w.g. to consider. That is, the base protocol and interactions with (encumbered) CGA. Really, everything related to CGA must be thrown out of the base spec, and placed in separate draft(s). I thought this was the design decision early on, has it changed or am I misunderstanding something? My reasoning here is: - it is too difficult to read the protocol and assess its usability and completeness when CGA parts (which will *NOT* be used by some) are there - the base protocol is too closely interconnected to CGA parts (for instance check out the second bullet of section 10), and constitute a significant portion of already-long specification - securing ND is such an important issue, potentially affecting all nodes, that using encumbered technology is completely unacceptable. - when the organizations will be filing IPR disclosures, many of them are likely to just give a blanket statement like "some portions of ietf-send-ipsec-nn contain our IPR". This makes it difficult to assess whether *some other* portions (which are considered "free") of the spec (e.g. trust anchors etc.) have IPR claims. Therefore, I strongly request pulling CGA out of the spec before going any further with it, and before those with claims on CGA make IPR disclosures on it. btw. which organizations had IPR claims on CGA? I thought at least Ericsson and Microsoft do, but only Microsoft has made IPR disclosure at www.ietf.org/ipr/ (and has not made the disclosure on more recent documents) -- if so, certainly a violation of the process. Docomolabs also has something on PBK, but not sure whether on CGA? If I believed in conspiracies, 3 out of 4 in the author list the employers of which have significant vested interest in CGA-like mechanisms, would be sounding alarm bells quite loudly. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sat Mar 8 04:27:09 2003 Received: from penguin.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 EAA26070 for ; Sat, 8 Mar 2003 04:27:08 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h289R9wv017077; Sat, 8 Mar 2003 10:27:09 +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.2655.55) id GPHZ6RC9; Sat, 8 Mar 2003 10:27:09 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h289R8K16249; Sat, 8 Mar 2003 10:27:08 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h289QdYl005150; Sat, 8 Mar 2003 10:26:39 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h289QdBN005149; Sat, 8 Mar 2003 10:26:39 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h289QcYl005145 for ; Sat, 8 Mar 2003 10:26:38 +0100 (MET) Received: from kolumbus.fi ([62.248.146.9]) by fep01-app.kolumbus.fi with ESMTP id <20030308092638.MPAA639.fep01-app.kolumbus.fi@kolumbus.fi>; Sat, 8 Mar 2003 11:26:38 +0200 Message-ID: <3E69B71C.6010501@kolumbus.fi> Date: Sat, 08 Mar 2003 11:25:48 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: ietf-send@standards.ericsson.net Subject: Re: Send protocol and CGA References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, Actually, this "co-conspirator" agrees to a large extent to what you are saying. Namely, I do agree that we can't have an IPv6 base component deployment prevented by patents. For instance, it would be very unfortunate if we couldn't use this in free operating system distributions. However, at least Ericsson is in the process of preparing an IPR and licensing statement relating to SEND. Hopefully other companies will do the same. Let's wait and see what the statements say, and decide then whether the IPRs are an issue. If they are, we should do what you say. (And yes, Ericsson has IPRs on CGAs. I don't think we have a specific statement in the IPR page but we've had that statement in the various earlier drafts.) But at this point I'd like to ask you however about the too-hard-to-analyze aspect. So this is a technical problem, not just about the IPRs? How strongly do you feel about that? Would that be helped by split of the document? Or is there a need for some new "layering" or other abstraction as well which would help the analysis? I'm not against smaller documents. In fact, a protocol of this size at -00 is probably going to be nearer 100 pages when fully baked... But there's some additional overhead for lots of documents which the chairs have tried to avoid, I think. Plus we have some bad experience of badly split documents in the past. So there's something to be said for self-contained single documents as well. 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 Sat Mar 8 04:35:24 2003 Received: from penguin.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 EAA27702 for ; Sat, 8 Mar 2003 04:35:24 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h289Zbwv017672; Sat, 8 Mar 2003 10:35:37 +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.2655.55) id GPHZ6RZ9; Sat, 8 Mar 2003 10:35:36 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h289ZaK16488; Sat, 8 Mar 2003 10:35:36 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h289ZTYl006621; Sat, 8 Mar 2003 10:35:29 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h289ZTf3006620; Sat, 8 Mar 2003 10:35:29 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h289ZSYl006616 for ; Sat, 8 Mar 2003 10:35:28 +0100 (MET) Received: from kolumbus.fi ([62.248.146.9]) by fep01-app.kolumbus.fi with ESMTP id <20030308093528.MPQH639.fep01-app.kolumbus.fi@kolumbus.fi>; Sat, 8 Mar 2003 11:35:28 +0200 Message-ID: <3E69B92F.4060200@kolumbus.fi> Date: Sat, 08 Mar 2003 11:34:39 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: ietf-send@standards.ericsson.net Subject: Re: Proxy ND? References: <01ba01c2e4d9$864a2f00$156015ac@T23KEMPF> <3E68FBAB.9070005@kolumbus.fi> <00c901c2e4f5$016baef0$156015ac@T23KEMPF> In-Reply-To: <00c901c2e4f5$016baef0$156015ac@T23KEMPF> 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 James Kempf wrote: >>Technically, if the proxy and the true owner of the address share a >>security association (as in MIPv6), this node could give an authorization >>cert to the proxy. The proxy NA would carry the following information: >> >>- PKnode (as usual) >>- target address, where IID = hash(PKnode,...) (as usual) > > > I think you mean: > > > PKnode (as usual) > > source address, where IID=hash(PKnode,...) (as usual) > > or? (see below for rest). Hmm.... no, I don't think so. At least when MIPv6 HAs act as ND proxies, they set the source address to the home agent's address and its the target address that matters. See draft 21, section 10.4.1. I haven't thought of whether this breaks some of the IPsec processing rules we have. Have you? >>- cert for PKproxy, signed by SKnode (this is new) > > > Is this an X.509 cert? If so, it might be pretty big. Also, I think it has to > contain the PK of the SKnode, otherwise the receiver can't check the CGA on the > target address. I was assuming it contains the PK as well. Yes, it could be big. Actually, it might make sense for such certs to be distributed using the DC mechanisms than in the AH packet itself. 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 Sat Mar 8 08:50:09 2003 Received: from albatross.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 IAA15281 for ; Sat, 8 Mar 2003 08:50:08 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h28DmpB3005848; Sat, 8 Mar 2003 14:48:51 +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.2655.55) id FD4JW0S7; Sat, 8 Mar 2003 14:48:50 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h28Dmo203011; Sat, 8 Mar 2003 14:48:50 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h28DmCYl004904; Sat, 8 Mar 2003 14:48:12 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h28DmBjd004903; Sat, 8 Mar 2003 14:48:11 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h28DmAYl004899 for ; Sat, 8 Mar 2003 14:48:10 +0100 (MET) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h28Dm9Y03332; Sat, 8 Mar 2003 15:48:09 +0200 Date: Sat, 8 Mar 2003 15:48:09 +0200 (EET) From: Pekka Savola To: Jari Arkko cc: ietf-send@standards.ericsson.net Subject: Re: Send protocol and CGA In-Reply-To: <3E69B71C.6010501@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk On Sat, 8 Mar 2003, Jari Arkko wrote: > However, at least Ericsson is in the process of preparing > an IPR and licensing statement relating to SEND. Hopefully > other companies will do the same. Let's wait and see what > the statements say, and decide then whether the IPRs are > an issue. If they are, we should do what you say. I've seen a few licensing statements from Ericsson and I think those could be truly reasonable at least to certain major parties. However, looking back at the previous licensing statements from Microsoft, I can be about 99.9% certain that there will be no hope here. (Unless, of course, one would work around the IPR somehow, but that seems unlikely too.) > (And yes, > Ericsson has IPRs on CGAs. I don't think we have a specific > statement in the IPR page but we've had that statement > in the various earlier drafts.) This is a violation of the process, but no harm is done (IMO), this has always been quite openly on the table. > But at this point I'd like to ask you however about the > too-hard-to-analyze aspect. So this is a technical > problem, not just about the IPRs? How strongly do you feel > about that? Would that be helped by split of the document? This is IMO mostly a technical problem if we assume that many would have to implement SEND without CGA. Of course, this mainly shift the "core" protocol to be more easily verified, analyzed, implemented etc. -- while making it (at least slightly) more difficult to add for thos who in fact do want to add CGA. > Or is there a need for some new "layering" or other abstraction > as well which would help the analysis? That might help, yes, but I haven't thought about it enough to be able to say whether such a model would fix the corcerns. Certainly, one could abstractify some language in specific sections to, separate CGA and non-CGA to separate subsections, and analyze scenarios where there are only-CGA, CGA + non-CGA, non-CGA (and maybe differences which the router is), but as can be seen, this could become very complex. So, splitting them apart seems like the best choice if one could expect CGA to be only an extension (albeit probably a very useful one). > I'm not against smaller > documents. In fact, a protocol of this size at -00 is probably > going to be nearer 100 pages when fully baked... Of course :-) > But there's > some additional overhead for lots of documents which the chairs > have tried to avoid, I think. Plus we have some bad experience > of badly split documents in the past. So there's something to > be said for self-contained single documents as well. I agree -- the main required functions should be in a single document (if we look back on MIPv6 effort, one could say some functions could have been separated from the start -- let's try not to add too many new features here) -- but the question becomes "what is really required?". I'd vager that describing the CGA and non-CGA semantics, analyzing the different cases where they're used or or, etc. would yield at least 20 additional pages in the document, and would make it much difficult to analyze the consequences (thus, a delayed product). So, it seems to me that a single protocol, be it with CGA or without CGA, must be specified in one document if we want to manage the SEND case quickly. (Another question altogether is whether we have sufficient pieces in place to support a SEND model without CGA...) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sat Mar 8 08:56:02 2003 Received: from penguin.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 IAA16425 for ; Sat, 8 Mar 2003 08:56:02 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h28DuAwv005292; Sat, 8 Mar 2003 14:56: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.2655.55) id GPHZ7LS9; Sat, 8 Mar 2003 14:56:09 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h28Du8K22344; Sat, 8 Mar 2003 14:56:08 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h28Du2Yl005346; Sat, 8 Mar 2003 14:56:02 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h28Du2hd005345; Sat, 8 Mar 2003 14:56:02 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h28Du1Yl005341 for ; Sat, 8 Mar 2003 14:56:01 +0100 (MET) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h28Du0V03389; Sat, 8 Mar 2003 15:56:00 +0200 Date: Sat, 8 Mar 2003 15:55:59 +0200 (EET) From: Pekka Savola To: Pekka Nikander cc: SEND WG Subject: Re: psreq issue#1: Should draft-psreq discuss solutions at all? In-Reply-To: <3E68FE88.4090908@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk On Fri, 7 Mar 2003, Jari Arkko wrote: > Pekka Nikander wrote: > > Many of the issues raised during the WG LC were > > somehow concerned with solutions. In fact, quite > > a few seemed to be concerned that the draft > > discusses solutions at all; some people expressed > > the strong opinion that it should not. > > > > In the draft, we currently state the following about > > solutions: > > > >> This document occasionally discusses solution proposals, such as CGA > >> [9] and ABK [8]. However, the discussion is solely for illustrative > >> purposes. It is meant to give the readers a more concrete idea of > >> some possible solutions. It does NOT indicate any preference on > >> solutions on the behalf of the authors or the working group. > > I'm fine with this text actually. Maybe you could add to the last > sentence something about the two solutions not being an exhaustive list > just to underline your point. I'm also fine with including some rough hand-waving towards some solutions. For those who already are aware of the solutions, this makes it much easier to connect the PSreq cases and requirements. Perhaps a reasonable compromise could be found by editing the text describing the solutions slightly. But IIRC, the draft was already in a reasonably good condition. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sat Mar 8 09:02:28 2003 Received: from penguin.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 JAA17659 for ; Sat, 8 Mar 2003 09:02:27 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h28E2Uwv005732; Sat, 8 Mar 2003 15:02:30 +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.2655.55) id FDVNAB4Y; Sat, 8 Mar 2003 15:02:29 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h28E2T203268; Sat, 8 Mar 2003 15:02:29 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h28E2GYl006691; Sat, 8 Mar 2003 15:02:16 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h28E2GWt006690; Sat, 8 Mar 2003 15:02:16 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h28E2FYl006686 for ; Sat, 8 Mar 2003 15:02:15 +0100 (MET) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h28E2Ab03439; Sat, 8 Mar 2003 16:02:10 +0200 Date: Sat, 8 Mar 2003 16:02:10 +0200 (EET) From: Pekka Savola To: Jari Arkko cc: James Kempf , Subject: Re: Proxy ND? In-Reply-To: <3E68FBAB.9070005@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk On Fri, 7 Mar 2003, Jari Arkko wrote: > James Kempf wrote: > > A quiet IETF mailing list two weeks before a meeting is a real luxury, so I am > > reluctant to distrurb the peace, but here goes. > > > > Anybody want to describe how to secure Proxy ND? The CGA address gives the > > recipient of the NA the assurance that the sender is authorized for the source > > address, but not the target address in the packet. > > Good question. > > Technically, if the proxy and the true owner of the address share a > security association (as in MIPv6), this node could give an authorization > cert to the proxy. The proxy NA would carry the following information: > > - PKnode (as usual) > - target address, where IID = hash(PKnode,...) (as usual) > - cert for PKproxy, signed by SKnode (this is new) > - signature of the NA, signed by SKproxy (new signer) Considering a link protection solution without CGA, it is likely that a lot of traffic (at least) initially will follow a path similar to the proxy-ND case .. so this is probably *not* just a corner case to be dealt with, but a critical piece of the infrastructure. It seems likely that nodes will have to authorize the router to act on their behalf when initiating communications to another node in the subnet they don't have any prior association with. In this way, if we can make all nodes trust the router(s), in some fashion, we can build up the SEND infrastructure from there. (this was probably fairly obvious to the w.g., but here goes anyway.. :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sat Mar 8 16:59:21 2003 Received: from albatross.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 QAA18753 for ; Sat, 8 Mar 2003 16:59:20 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h28LvYB3016707; Sat, 8 Mar 2003 22:57:34 +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.2655.55) id GPHZ8Y7H; Sat, 8 Mar 2003 22:57:33 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h28LvWK02962; Sat, 8 Mar 2003 22:57:32 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h28Lv2Yl028614; Sat, 8 Mar 2003 22:57:02 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h28Lv29g028613; Sat, 8 Mar 2003 22:57:02 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h28Lv0Yl028608 for ; Sat, 8 Mar 2003 22:57:01 +0100 (MET) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h28Lv0106703 for ; Sat, 8 Mar 2003 23:57:00 +0200 Date: Sat, 8 Mar 2003 23:56:59 +0200 (EET) From: Pekka Savola To: ietf-send@standards.ericsson.net Subject: Comments on SEND protocol Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Hi, Here are the technical & editorial comments I scribbled down on a quick read. I didn't look at security considerations because they were too CGA-specific, and overlooked conclusions&path forward. Substantial: ------------ ==> Big issue (at least later): a security considerations section which checks the protocol against the SEND requirements and threats to see that there are no omissions etc. ==> One may have to consider whether Neighbor Discovery or IPsec changes have to go to separate document(s) -- in this case, the modifications are probably not as invasive as some in MIPv6, but some might argue for it. 4. Secure Neighbor Discovery Overview o IPsec AH is used to protect all advertisement messages relating to Neighbor and Router discovery. Solicitation messages are not protected, as they do not carry any information. ==> The latter sentence _incorrect_, and seems to be a show-stopper of a kind. With IPv4 ARP the link-layer address in Request is stored in the cache, and this is in fact one away to perform ARP spoofing. The same applies to solicitations, as below: RFC2461, 7.2.3: If the Source Address is not the unspecified address and, on link layers that have addresses, the solicitation includes a Source Link-Layer Address option, then the recipient SHOULD create or update the Neighbor Cache entry for the IP Source Address of the solicitation. If an entry does not already exist, the node SHOULD create a new one and set its reachability state to STALE as specified in Section 7.3.3. If an entry already exists, and the cached link-layer address differs from the one in the received Source Link-Layer option, the cached address should be replaced by the received address and the entry's reachability state MUST be set to STALE. RFC2461, 6.2.6: Router Solicitations in which the Source Address is the unspecified address MUST NOT update the router's Neighbor Cache; solicitations with a proper source address update the Neighbor Cache as follows. If the router already has a Neighbor Cache entry for the solicitation's sender, the solicitation contains a Source Link-Layer Address option, and the received link-layer address differs from that already in the cache, the link-layer address SHOULD be updated in the appropriate Neighbor Cache entry, and its reachability state MUST also be set to STALE. If there is no existing Neighbor Cache entry for the solicitation's sender, the router creates one, installs the link- layer address and sets its reachability state to STALE as specified in Section 7.3.3. Whether or not a Source Link-Layer Address option is provided, if a Neighbor Cache entry for the solicitation's sender exists (or is created) the entry's IsRouter flag MUST be set to FALSE. ... Note, however, that including these in the address requires the host to perform duplicate address detection for each address configured on the interface, not just for the link local address, as is allowed by RFC 2462. ==> right, so RFC2462/RFC2461 is being changed in this regard when it comes to SEND-secured links. I think it may be appropriate to say this explicitly, even create a new section of Neighbor Discovery modifications. Delegation Chain Solicitations MUST NOT be sent if a valid certificate chain exists in the host's cache from the desired router (or host) to the host's trusted root. A host MUST send Delegation Chain Solicitations either to the All-Routers multicast address, if it hasn't selected a default router yet, or to the default router's IP address if it has already been selected. If two hosts communicate with the solicitations and advertisements, these MUST be unicast to the hosts's address. ==> (and a few other places), I'm a bit confused on how certificate chains work between two hosts. In some places, I get an impression that they are not supported at all, in some I get an impression that they're supported as an afterthought -- for example, the send paragraph would seem to imply ("two hosts"...) that DCS/DCA could be done between two hosts but no DCS processing is specified for hosts. This issue needs some serious rewording. o If the cache becomes full, the receiver SHOULD temporarily reduce the Delta value for that source address so that all messages within that value can still be stored. ==> .. and discard messages outside of the new Delta, right? Otherwise the cache stays full until stuff in cache naturally expires, and the mechanism is useless. o The packet, in the form defined for AH's coverage, is signed using the private key in the security association, and the resulting PCKS #1 signature is put to the Digital Signature field. but earlier: Digital Signatures This variable length field, if present, contains the signature ==> in 7.1.5 text seems to say that PCKS#1 is always put to DS field, but earlier DS is not necessarily always present -- what's the deal? ==> editorial: "in the form defined for AH's coverage", perhaps this should be stated more explicitly? o Hosts configured for SEND MUST validate all Router Advertisements with the protocol described in Section 8. Note that this includes discarding advertisements received without a valid IPsec AH header and CGA address, thus making insecure prefixes invisible to them. ==> _and CGA address_ doesn't enhance my hope that CGA is only optional :-) o Hosts configured for SEND MUST secure and validate all Neighbor Advertisements with the protocol described in Section 8. Note that this includes discarding advertisements received without a valid IPsec AH header and CGA address. ==> note that this would seem to imply that if there are multiple nodes with the same layer 2 address, it will go undetected or cause A Great Deal of Trouble. Also, theoretically CGA address and manually configured link-local address could clash, but this should not happen unintentionally due to different u/g bit settings. o Routers MUST assign different addresses for their secure and insecure communications, including their link-local addresses. ==> Note that many none of router-only platforms I know of (IIRC) support multiple link-local addresses. Of course, this will change at the latest with SEND ;-), but maybe something to keep in mind, operationally -- it may not be as trivial as stated here. Signatures related to the use of the AH_RSA_Sig transform MAY be precomputed for Multicast Neighbor and Router Advertisements. Typically, solicited advertisements are sent to the unicast address from which the solicitation was sent. Given that the IPv6 header is covered by the AH integrity protection, it is typically not possible to precompute solicited advertisements. ==> uh, what about Timestamps in the messages? I guess if you time them just so (withing a sufficient delta), you can precompute them too, but I think this should be explicitly noted here? Appendix C. IPR Considerations The optional CGA part of SEND uses public keys and hashes to prove address ownership. Several IPR claims have been made about such methods. ==> "optional"? It's not april fools yet :-) Semi-subtantial/editorial: -------------------------- Section 5 describes the mechanism for showing address ownership, based on the use of Cryptographically Generated Addresses (CGAs). Section 6 describes the mechanism for distributing certificate chains to establish authorization delegation chain to a common trusted root. Section 7 describes the necessary modifications to IPsec. Finally, Section 8 show how to apply these components to securing Neighbor and Router Discovery. ==> this should be expanded slightly, so that when reading the Introduction you would have a better picture of how the components a connected. The Address Autoconfiguration mechanism is stateless, where the hosts use prefix information delivered to them during Router Discovery to create addresses, and then test these addresses for uniqueness using the DAD procedure. ==> s/test/typically test/, it's not necessary! o Router Advertisement: The destination address can be either a unicast or the All Nodes multicast address [1]. Like the solicitation message, the advertisement is also local to the link only. ==> The last sentence applies to all the messages here, I think, so the fact should be stated up front somewhere. 5. Cryptographically Generated Addresses Cryptographically Generated Addresses (CGAs) [22][23][20][25] are a technique whereby a node's IPv6 address can be unalterably tied to the node's public key. * Conceptually, CGAs allow a recipient of a message to determine whether the sender is authorized to use the public key and address claimed to be associated with the packet. Typically, this requires the sender to use the hash of the node's public key as the interface identifier in the bottom 64 bits of the IPv6 address. ==> Even though there are a number of references, it might be useful (if one can summarize in a paragraph of less than 5-10 lines) to describe why exactly the sentence marked above is true. This is because there are a lot of bogus specifications and proclamations of security mechanisms (e.g. many papers on HIP) which neglect to mention that you really need something like DNSsec to be secure, or the like. In this case, it is good to give very quick overview why such are *really* not needed. Equation (1). H(N) = Hash-160(public_key | nonce | routing_prefix) H(i) = Hash-160(H(i+1)) where Hash-160 is the 160 bits obtained from applying the SHA-1 secure hashing algorithm [12], public_key is the node's public key in the format defined in Section 7.1.2, and nonce is a random octet string of 8 or more bytes. The selection N is a local matter, but it MUST be at least 3. N is used as a defense mechanism against denial-of-service attacks. ==> in the equation I think you have to say that "nonce" = "N", or the like. Some rewording on N may also be appropriate in the last two sentences. The 'M' flag, when set, indicates that there are more components coming in this advertisement. Component This is a 15 bit unsigned integer field. The first message in a multi-component advertisement has the Component field set to 0, the second set to 1, and so on. ==> note that with 'M' flag, there is the obvious issue of packets getting reordered in the IP (or beneath) layer. That is why "Component" is useful (which should be explicitly stated for clarity, perhaps). ==> I think the field would be better named "Component Number" ==> I assume on a single-component advertisement, Component is zero (it isn't stated above)? ==> The last sentence could also be reworded for simplicity like: The value of the Component field allocated sequentially, starting from zero for each advertisement, to distinguish different parts of the original data. (I wonder if that's any clearer though! :-) Valid Options: Certificate Trusted Root ==> swap the order of these options, as Trusted Root is described first so that they're in the same order. MUST be set to zero by senders and ignored by receivers ==> is this the usual way of saying MBZ? I've also noted ".. and MUST BE ignored", but one can read the "MUST be" to apply to both parts of the sentence.. specification defines only one legal value for this field: ==> I'd strike out "legal" everywhere in this context in the spec, it seems out of place here, with wrong connotations. A host MUST silently discard any received Router Advertisement messages that do not satisfy all of the following validity checks: ==> this a/RA/DCA/ was already noted it seems (in a few other places also, of course, under this subsection) Delegation Chain Solicitations may be sent after any of the following events: ==> "may be sent" is slightly ambiguous: one should clarify that the list is not exhaustive, perhaps like (or simpler than that): Delegation Chain Solicitations may be sent after any event that might affect local network connectivity, including but not limited to: 6.5: Rate limitation of Delegation Chain Advertisements is performed as specified for Router Advertisements in RFC 2461 [6]. 6.6: Delegation Chain Solicitations SHOULD be rate limited and timed similarly with Router Solicitations, as specified in RFC 2461 [6]. ==> The language in these should be similar. The former approach seems better to me, but I'm indifferent. o The sum of the PK_Len, Nonce_Len, and LLA_Len fields does not exceed the length of the Authentication Data field. ==> LLA_Len was never defined anywhere! It is outside the scope of this specification to describe trusted roots and address autoconfiguration (stateful or stateless) with dynamically changing addresses works. It is also outside the scope of this specification to describe how stateful address autoconfiguration works with the CGA method. ==> s/describe/describe how/ ==> s/works/work/ ? ==> "dynamically changing addresses" --> I assume you mean RFC3041, add a reference there, like "dynamically changing addresses, like [ref], work" Editorial: ---------- 2. Terms Cryptographically Generated Addresses (CGAs) A technique [22] where the address of the node is cryptographically generated from the public key of the node and some other parameters using a one-way hash function. ==> The formatting must be changed, e.g. make the term explanations go on separate paragraphs or something. o Redirect: This message is always sent from the router's link-local address to the source address of the packet that triggered the Redirect. Hosts verify that the IP source address of the Redirect is the same as the current first-hop router for the specified ICMP Destination Address. ==> s/Hosts verify/Host verifies/ (singular seems better) ? The new transform uses also a fixed, standardized SPI (Security ==> s/uses also/also uses/ The authorization provide by CGA is computational in nature, deriving ==> s/provide/provided/ information when the node needs this information before to communicate off-link. ==> s/before to/before being able to/ selected. If two hosts communicate with the solicitations and advertisements, these MUST be unicast to the hosts's address. ==> s/hosts's address/hosts' addresses/ (or something else like that, I don't know the intent) When processing a possible advertisement sent as a response to a ==> s/as a/in/ ? Digital Signatures ==> s/res/re/ o If the use of CGA has been specified in the security association, we additionally require that A node receiving an Neighbor or ==> "we .." -- use the passive voice for consistency with the rest of the doc. ==> s/A/a/ parameter from the rightmost two bits of the Target Address. If the interface identifier checks, the recipient proceeds with the ==> s/checks/check succeeds/ ? 10. Operational Considerations During the transition to secure links or as a policy consideration, ==> s/links/neighbor discovery/ ? 10. Operational Considerations addresses, including link local addresses. ==> s/link local/link-local/ to use asymmetric transforms for a significant amount packets. ==> s/amount/amount of/ recipient. As a result both participants are forced to believe that ==> s/As a result/As a result,/ (not required but maybe good.) Normative References [1] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. ==> s/S. Deering/Deering, S./ (similar to others where multiple authors) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Mar 9 03:06:08 2003 Received: from penguin.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 DAA15350 for ; Sun, 9 Mar 2003 03:06:06 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h29848wv010030; Sun, 9 Mar 2003 09:04:08 +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.2655.55) id GPHJCXNB; Sun, 9 Mar 2003 09:04:07 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h29847225354; Sun, 9 Mar 2003 09:04:07 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2983IYl023035; Sun, 9 Mar 2003 09:03:18 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2983I1J023034; Sun, 9 Mar 2003 09:03:18 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2983HYl023030 for ; Sun, 9 Mar 2003 09:03:17 +0100 (MET) Received: from kolumbus.fi ([62.248.146.9]) by fep01-app.kolumbus.fi with ESMTP id <20030309080317.PPML639.fep01-app.kolumbus.fi@kolumbus.fi>; Sun, 9 Mar 2003 10:03:17 +0200 Message-ID: <3E6AF513.2020108@kolumbus.fi> Date: Sun, 09 Mar 2003 10:02:27 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: ietf-send@standards.ericsson.net Subject: Re: Comments on SEND protocol References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Thank you Pekka for your (as always) in-depth comments. This is a very useful discussion and I'll respond to a few points below: > ==> Big issue (at least later): a security considerations section which > checks the protocol against the SEND requirements and threats to see that > there are no omissions etc. Agreed. > 4. Secure Neighbor Discovery Overview > > o IPsec AH is used to protect all advertisement messages relating to > Neighbor and Router discovery. Solicitation messages are not > protected, as they do not carry any information. > > ==> The latter sentence _incorrect_, and seems to be a show-stopper of a > kind. Yes, and this is indeed the biggest problem in the protocol that I know of at the moment. I think we mention it already in Section 14, by the way, but we didn't have time to invent a solution. One approach would be to avoid the solitications with an effect in SEND, but this would increase the number of messages in typical situations, which would be unfortunate for e.g. fast movements. More seriously, DAD would not work between two nodes who are testing the same address at the same time. Also, we wouldn't like to change the ND protocol as such. So what's wrong with just protecting solicitations in the same manner as advertisements? The reason is tricky. Consider the DAD probes, where the solicitation message has the unspecified address as a source, and the solicited node multicast address as a destination. The tested address appears within the ND packet in the Target Address option. If our security solution is at the IPsec layer, how can we test that the tested address and the signature have been associated in the right way? (Whether that association is through a cert with an address or via CGA is not relevant, but IPsec needs to access the address which for now only appears inside the application layer.) > ==> (and a few other places), I'm a bit confused on how certificate chains > work between two hosts. In some places, I get an impression that they are > not supported at all, in some I get an impression that they're supported > as an afterthought -- for example, the send paragraph would seem to imply > ("two hosts"...) that DCS/DCA could be done between two hosts but no DCS > processing is specified for hosts. This issue needs some serious > rewording. Yes. One of our pre-00 versions only supported cert chains between a host and a router, and the host to host case was indeed an afterthought. Unfortunately we didn't have time to edit the specification to make it really clear how it works between hosts. > o If the cache becomes full, the receiver SHOULD temporarily reduce > the Delta value for that source address so that all messages > within that value can still be stored. > > ==> .. and discard messages outside of the new Delta, right? Otherwise > the cache stays full until stuff in cache naturally expires, and the > mechanism is useless. That's right. Good point. > o The packet, in the form defined for AH's coverage, is signed using > the private key in the security association, and the resulting > PCKS #1 signature is put to the Digital Signature field. > > but earlier: > > Digital Signatures > > This variable length field, if present, contains the signature > > ==> in 7.1.5 text seems to say that PCKS#1 is always put to DS field, but > earlier DS is not necessarily always present -- what's the deal? This is a bug. The DS field must always be present. > o Hosts configured for SEND MUST validate all Router Advertisements > with the protocol described in Section 8. Note that this includes > discarding advertisements received without a valid IPsec AH header > and CGA address, thus making insecure prefixes invisible to them. > > ==> _and CGA address_ doesn't enhance my hope that CGA is only optional > :-) Another bug in the text. CGA was indeed intended to be optional. Maybe it should have read "... a valid IPsec AH header with AH-RSA-Sig transform" or even "... a valid IPsec AH header". > o Hosts configured for SEND MUST secure and validate all Neighbor > Advertisements with the protocol described in Section 8. Note > that this includes discarding advertisements received without a > valid IPsec AH header and CGA address. > > ==> note that this would seem to imply that if there are multiple nodes > with the same layer 2 address, it will go undetected or cause A Great Deal > of Trouble. Also, theoretically CGA address and manually configured > link-local address could clash, but this should not happen unintentionally > due to different u/g bit settings. Hmmm... interesting. With GDT, do you mean that switches and the like would "forward" packets incorrectly? I mean if the router would not react in any way to someone claiming the same ll address as one of the SEND nodes, that wouldn't by itself be bad? > o Routers MUST assign different addresses for their secure and > insecure communications, including their link-local addresses. > > ==> Note that many none of router-only platforms I know of (IIRC) support > multiple link-local addresses. Of course, this will change at the latest > with SEND ;-), but maybe something to keep in mind, operationally -- it > may not be as trivial as stated here. Yes. I'm by the way not too happy with the current SEND transition specification. It doesn't deal with routers belonging to just the SEND or the non-SEND category, I'm not sure how it works with multiple routers, the address thing you mention above is somewhat troublesome etc. Good ideas sought... > Signatures related to the use of the AH_RSA_Sig transform MAY be > precomputed for Multicast Neighbor and Router Advertisements. > Typically, solicited advertisements are sent to the unicast address > from which the solicitation was sent. Given that the IPv6 header is > covered by the AH integrity protection, it is typically not possible > to precompute solicited advertisements. > > ==> uh, what about Timestamps in the messages? I guess if you time them > just so (withing a sufficient delta), you can precompute them too, but I > think this should be explicitly noted here? Ah, a good point. I'm not sure we can precompute then. > Equation (1). > H(N) = Hash-160(public_key | > nonce | > routing_prefix) > H(i) = Hash-160(H(i+1)) > > where Hash-160 is the 160 bits obtained from applying the SHA-1 > secure hashing algorithm [12], public_key is the node's public key in > the format defined in Section 7.1.2, and nonce is a random octet > string of 8 or more bytes. The selection N is a local matter, but it > MUST be at least 3. N is used as a defense mechanism against > denial-of-service attacks. > > ==> in the equation I think you have to say that "nonce" = "N", or the > like. Some rewording on N may also be appropriate in the last two > sentences. But N is not the nonce. Maybe we should have used "K" and "nonce" instead. "N" is a small integer number, and allows us to demand a sequence of hashes. (Anyway, we probably shouldn't discuss these details before we take a look at Tuomas' draft which IMHO defines the CGA addresses generation formulas in a very clean manner.) > o The sum of the PK_Len, Nonce_Len, and LLA_Len fields does not > exceed the length of the Authentication Data field. > > ==> LLA_Len was never defined anywhere! This a leftover of something we had in an earlier version. At that time, we included even the link-layer addresses in the computations. After the discussion on the IPv6 list, we no longer do... 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 Sun Mar 9 03:47:11 2003 Received: from albatross.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 DAA22286 for ; Sun, 9 Mar 2003 03:47:10 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h298kkB3011262; Sun, 9 Mar 2003 09:46:46 +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.2655.55) id GPHZ0VD9; Sun, 9 Mar 2003 09:46:45 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h298kjK16784; Sun, 9 Mar 2003 09:46:45 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h298kNYl027795; Sun, 9 Mar 2003 09:46:23 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h298kNc6027794; Sun, 9 Mar 2003 09:46:23 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h298kMYl027790 for ; Sun, 9 Mar 2003 09:46:22 +0100 (MET) Received: from kolumbus.fi ([62.248.146.9]) by fep01-app.kolumbus.fi with ESMTP id <20030309084622.PSPK639.fep01-app.kolumbus.fi@kolumbus.fi>; Sun, 9 Mar 2003 10:46:22 +0200 Message-ID: <3E6AFF2C.6000504@kolumbus.fi> Date: Sun, 09 Mar 2003 10:45:32 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: James Kempf , ietf-send@standards.ericsson.net Subject: Re: Proxy ND? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > Considering a link protection solution without CGA, it is likely that a > lot of traffic (at least) initially will follow a path similar to the > proxy-ND case .. so this is probably *not* just a corner case to be dealt > with, but a critical piece of the infrastructure. > > It seems likely that nodes will have to authorize the router to act on > their behalf when initiating communications to another node in the subnet > they don't have any prior association with. > > In this way, if we can make all nodes trust the router(s), in some > fashion, we can build up the SEND infrastructure from there. Interesting idea. In a way, this happens when the router and the first node are upgraded to SEND: everyone else sends their ND packets to the router, and all communications of the one SEND node come through the router. The SEND node believes it is the only node on the link. The other nodes are not on the link, and ND is not used for communicating with them. Just like any other node in the Internet. Obviously, the non-SEND nodes will not authorize the router or the router will not authorize them in any way. These are existing nodes. So for that we don't need secure proxy ND. But I guess your question is if we can simply provide SEND for the RD part, and build secure ND from that? For instance, since the host trusts the router's keys, it would believe an NA sent by the router for a peer. The tricky part is, however, getting the router to believe the peer. And it needs to, otherwise sending an NA signed by the router would be pointless. With delegation chain discovery, all hosts can trust the router. But how to get mutual trust? This seems harder, basically something that would require host certs or CGA. And if you have those, is there a need for the router to act as a mediator? 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 Sun Mar 9 12:47:37 2003 Received: from penguin.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 MAA00102 for ; Sun, 9 Mar 2003 12:47:37 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h29Hjnwv018616; Sun, 9 Mar 2003 18:45:50 +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.2655.55) id FDVN15AJ; Sun, 9 Mar 2003 18:45:49 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h29Hjm207087; Sun, 9 Mar 2003 18:45:48 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h29Hj6Yl026510; Sun, 9 Mar 2003 18:45:06 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h29Hj6jH026504; Sun, 9 Mar 2003 18:45:06 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h29Hj4Yl026463 for ; Sun, 9 Mar 2003 18:45:05 +0100 (MET) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Sun, 9 Mar 2003 09:44:55 -0800 Received: from 157.54.8.109 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 09 Mar 2003 09:45:03 -0800 Received: from RED-MSG-09.redmond.corp.microsoft.com ([157.54.12.7]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Sun, 9 Mar 2003 09:45:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: CGA draft and paper Date: Sun, 9 Mar 2003 09:45:07 -0800 Message-ID: Thread-Topic: CGA draft and paper Thread-Index: AcLZdiJVcERgdKZGQ2abww8GxyVxewCpy5NQApFwEJA= From: "Tuomas Aura" To: "SEND WG" X-OriginalArrivalTime: 09 Mar 2003 17:45:13.0147 (UTC) FILETIME=[A30CC8B0:01C2E663] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h29Hj6Yl026491 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit It seems that this is now in the ID directory: http://www.ietf.org/internet-drafts/draft-aura-cga-00.txt Tuomas > > -----Original Message----- > From: Tuomas Aura [mailto:tuomaura@microsoft.com] > Sent: 24 February 2003 16:13 > To: SEND WG > > I have posted a draft on Cryptographically Generated Addresses (CGA) > on my web page: > > http://research.microsoft.com/users/tuomaura/CGA/draft-aura-cg > a-pre00.tx > t > Unfortunately, I managed to miss the submission deadline for San > Francisco, so the draft will only be on this web site for now. > > A related (still unpublished) paper with some more background info > is also available: > > http://research.microsoft.com/users/tuomaura/CGA/aura-cga-unpu > blished.pd > f > > Tuomas > -------------------------------------------------------------------- > 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 Mar 9 13:00:20 2003 Received: from albatross.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 NAA02672 for ; Sun, 9 Mar 2003 13:00:19 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h29I07B3004510; Sun, 9 Mar 2003 19:00:07 +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.2655.55) id GPH5BLVN; Sun, 9 Mar 2003 19:00:07 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h29I06207362; Sun, 9 Mar 2003 19:00:06 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h29HxqYl027924; Sun, 9 Mar 2003 18:59:52 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h29Hxqjg027923; Sun, 9 Mar 2003 18:59:52 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h29HxoYl027919 for ; Sun, 9 Mar 2003 18:59:51 +0100 (MET) Received: from mail6.microsoft.com ([157.54.6.196]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Sun, 9 Mar 2003 09:59:48 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sun, 9 Mar 2003 09:59:47 -0800 Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 09 Mar 2003 09:59:48 -0800 Received: from RED-MSG-09.redmond.corp.microsoft.com ([157.54.12.7]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Sun, 9 Mar 2003 09:59:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Factoring the spec into digestible pieces (RE: Send protocol and CGA) Date: Sun, 9 Mar 2003 09:59:53 -0800 Message-ID: Thread-Topic: Factoring the spec into digestible pieces (RE: Send protocol and CGA) Thread-Index: AcLlSjsTZg480XVqQWO/fi8TR/1UhABGa+6A From: "Tuomas Aura" To: X-OriginalArrivalTime: 09 Mar 2003 17:59:51.0878 (UTC) FILETIME=[AED07E60:01C2E665] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h29HxqYl027920 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Pekka Savola wrote: > Really, everything related to CGA must be thrown out of the > base spec, and placed in separate draft(s). I thought this > was the design decision early on, has it changed or am I > misunderstanding something? I also think that the IPSec extensions should be factored out into a separate spec. Like CGA, they may have other uses beyond SEND. Let's keep this in small and digestible pieces, and make those pieces as universally usable as possible. Otherwise, we will have another giant spec that is impossible to check for completeness and consistency. (I'm sure Jari knows what particular prior example I'm thinking of.) 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 Sun Mar 9 13:38:24 2003 Received: from albatross.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 NAA09612 for ; Sun, 9 Mar 2003 13:38:23 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h29IbDB3007865; Sun, 9 Mar 2003 19:37: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.2655.55) id GPH5BPFZ; Sun, 9 Mar 2003 19:37:13 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h29IbC208120; Sun, 9 Mar 2003 19:37:12 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h29IarYl002671; Sun, 9 Mar 2003 19:36:53 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h29IarC6002670; Sun, 9 Mar 2003 19:36:53 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h29IaqYl002666 for ; Sun, 9 Mar 2003 19:36:52 +0100 (MET) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h29IalF20060; Sun, 9 Mar 2003 20:36:48 +0200 Date: Sun, 9 Mar 2003 20:36:47 +0200 (EET) From: Pekka Savola To: Jari Arkko cc: James Kempf , Subject: Re: Proxy ND? In-Reply-To: <3E6AFF2C.6000504@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk On Sun, 9 Mar 2003, Jari Arkko wrote: > Interesting idea. In a way, this happens when the router and the > first node are upgraded to SEND: everyone else sends their ND > packets to the router, and all communications of the one SEND > node come through the router. The SEND node believes it is the > only node on the link. The other nodes are not on the link, > and ND is not used for communicating with them. Just like > any other node in the Internet. Yep. > Obviously, the non-SEND nodes will not authorize the router > or the router will not authorize them in any way. Yes, but if that'd help, the SEND router could perform certain proxy functions on behalf of the SEND node for non-SEND nodes; naturally, certain functions are already necessary, but some others (e.g. the router might not believe some types of messages used for ND spoofing or other attacks) could also be added if that'd be of any help. Might get too complicated, though.. > These are > existing nodes. So for that we don't need secure proxy ND. Agree. > But I guess your question is if we can simply provide SEND > for the RD part, and build secure ND from that? Yes. > For instance, since the host trusts the router's keys, it would believe > an NA sent by the router for a peer. The tricky part is, however, > getting the router to believe the peer. And it needs to, otherwise > sending an NA signed by the router would be pointless. With delegation > chain discovery, all hosts can trust the router. But how to get mutual > trust? This seems harder, basically something that would require host > certs or CGA. And if you have those, is there a need for the router to > act as a mediator? In particular, all the SEND nodes might not have shared roots -- it might be difficult to have everyone trust everyone else. The approach here is secure proxy-ND. However, this could be made a bit more streamlined: there has to be a trust relationship with the router and host A. The router could (maybe, can't estimate the complexity and the overhead), certify to node B that node A is a "good guy", which might help in building an association with node A and B. It seems (quick thinking) to me that the approach for host-host communication could be one of: 1) CGA 2) secure proxy-ND through router 3) router certifying host A to host B and vice versa: assistance in delegation chain discovery between the hosts if they don't have shared roots. 4) fallback to insecure ND or the like if two hosts have no shared roots (ie. operational imperative to "get enough roots and certificates!") However, the SEND protocol is quite unclear to me yet on how exactly the certifying process even between a router/host would work without CGA. In particular, it seems some certificatetied to certain global and even link-local addresses which the other party can verify is needed. This brings up the question how that kind of certifying process could be done (particularly the link-local part, which seems like something only the admin of the link could be able to give -- which would lead to either a trivial or a very difficult solution). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Mar 9 13:54:26 2003 Received: from albatross.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 NAA12624 for ; Sun, 9 Mar 2003 13:54:25 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h29IsTB3009311; Sun, 9 Mar 2003 19:54:29 +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.2655.55) id GPHJ1D7C; Sun, 9 Mar 2003 19:54:29 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h29IsS208445; Sun, 9 Mar 2003 19:54:28 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h29IrmYl004497; Sun, 9 Mar 2003 19:53:48 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h29Irmef004496; Sun, 9 Mar 2003 19:53:48 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h29IrlYl004492 for ; Sun, 9 Mar 2003 19:53:47 +0100 (MET) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h29Irk720135; Sun, 9 Mar 2003 20:53:46 +0200 Date: Sun, 9 Mar 2003 20:53:46 +0200 (EET) From: Pekka Savola To: Jari Arkko cc: ietf-send@standards.ericsson.net Subject: Re: Comments on SEND protocol In-Reply-To: <3E6AF513.2020108@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Thanks for the quick response. Replying only to "left-over" issues. On Sun, 9 Mar 2003, Jari Arkko wrote: > > 4. Secure Neighbor Discovery Overview > > > > o IPsec AH is used to protect all advertisement messages relating to > > Neighbor and Router discovery. Solicitation messages are not > > protected, as they do not carry any information. > > > > ==> The latter sentence _incorrect_, and seems to be a show-stopper of a > > kind. > > Yes, and this is indeed the biggest problem in the protocol that I know > of at the moment. I think we mention it already in Section 14, by the way, > but we didn't have time to invent a solution. One approach would be to > avoid the solitications with an effect in SEND, but this would increase > the number of messages in typical situations, which would be unfortunate > for e.g. fast movements. More seriously, DAD would not work between two > nodes who are testing the same address at the same time. Also, we wouldn't > like to change the ND protocol as such. > > So what's wrong with just protecting solicitations in the same manner > as advertisements? The reason is tricky. Consider the DAD probes, where > the solicitation message has the unspecified address as a source, and the > solicited node multicast address as a destination. The tested address > appears within the ND packet in the Target Address option. If our > security solution is at the IPsec layer, how can we test that the > tested address and the signature have been associated in the right > way? (Whether that association is through a cert with an address or > via CGA is not relevant, but IPsec needs to access the address which > for now only appears inside the application layer.) Perhaps an intermediate solution, if securing certain solicitations is too tricky, to take some messages in the consideration *BUT* specify that using such "possibly insecure" solicitations the neighbor discovery cache MUST NOT be updated. Another approach would be to modify IPsec processing even further, to make it associate the source address, in the case of unspecified, with the target address (if it exists) .. but this seems rather dirty a solution. > > o Hosts configured for SEND MUST secure and validate all Neighbor > > Advertisements with the protocol described in Section 8. Note > > that this includes discarding advertisements received without a > > valid IPsec AH header and CGA address. > > > > ==> note that this would seem to imply that if there are multiple nodes > > with the same layer 2 address, it will go undetected or cause A Great Deal > > of Trouble. Also, theoretically CGA address and manually configured > > link-local address could clash, but this should not happen unintentionally > > due to different u/g bit settings. > > Hmmm... interesting. With GDT, do you mean that switches and the like > would "forward" packets incorrectly? Yes. (But I guess this is unavoidable, and happens even today.) This seems to be a possible bigger problem if the SEND-router (also acting as non-SEND) would take a ll-addr clash into consideration. I.e. when a SEND and non-SEND node claim they have the same ll address, who to believe? > I mean if the router would not > react in any way to someone claiming the same ll address as one of > the SEND nodes, that wouldn't by itself be bad? With proper checks in router, this would seem to be ok. (Note: in the SEND router implementations, you might need a toggle "allow SEND only" vs "allow SEND and ND interaction" -- in the first case, some things would get simpler.) > > o Routers MUST assign different addresses for their secure and > > insecure communications, including their link-local addresses. > > > > ==> Note that many none of router-only platforms I know of (IIRC) support > > multiple link-local addresses. Of course, this will change at the latest > > with SEND ;-), but maybe something to keep in mind, operationally -- it > > may not be as trivial as stated here. > > Yes. I'm by the way not too happy with the current SEND transition > specification. It doesn't deal with routers belonging to just the > SEND or the non-SEND category, I'm not sure how it works with multiple > routers, the address thing you mention above is somewhat troublesome > etc. Good ideas sought... Yes, I believe the transition part will require a lot of thought (whether in this document or elsewhere). Too difficult to imagine all the situations just yet, though. > > Signatures related to the use of the AH_RSA_Sig transform MAY be > > precomputed for Multicast Neighbor and Router Advertisements. > > Typically, solicited advertisements are sent to the unicast address > > from which the solicitation was sent. Given that the IPv6 header is > > covered by the AH integrity protection, it is typically not possible > > to precompute solicited advertisements. > > > > ==> uh, what about Timestamps in the messages? I guess if you time them > > just so (withing a sufficient delta), you can precompute them too, but I > > think this should be explicitly noted here? > > Ah, a good point. I'm not sure we can precompute then. Well, you can "precompute", strictly speaking, if you know when you'd be sending the multicasts, *but* you have to compute every message *anyway*, you just can influence when that precomputation happens (e.g. when you need to compute, you could spread it even over a couple of seconds, running on low priority, not when you're building the packet to send it out). Not that useful it seems, perhaps a bit to some very low-end devices. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Mar 10 00:19:43 2003 Received: from penguin.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 AAA04407 for ; Mon, 10 Mar 2003 00:19:42 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2A5I0wv003246; Mon, 10 Mar 2003 06:18:00 +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.2655.55) id GPH5DPWA; Mon, 10 Mar 2003 06:17:59 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2A5Hx221518; Mon, 10 Mar 2003 06:17:59 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2A5HLYl029277; Mon, 10 Mar 2003 06:17:21 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2A5HLK3029276; Mon, 10 Mar 2003 06:17:21 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from TNEXVS01.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2A5HJYl029269 for ; Mon, 10 Mar 2003 06:17:19 +0100 (MET) Received: from TNEXVS02.tahoenetworks.com ([10.10.1.132]) by TNEXVS01.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.2966); Sun, 9 Mar 2003 21:17:18 -0800 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Proxy ND? Date: Sun, 9 Mar 2003 21:17:18 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A3E8@TNEXVS02.tahoenetworks.com> Thread-Topic: Proxy ND? Thread-Index: AcLma4oVg//siK4pTxupkQTQtE0KjwAVjIKw From: "Mohan Parthasarathy" To: "Pekka Savola" , "Jari Arkko" Cc: "James Kempf" , X-OriginalArrivalTime: 10 Mar 2003 05:17:18.0435 (UTC) FILETIME=[520CE330:01C2E6C4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h2A5HKYl029273 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit > > On Sun, 9 Mar 2003, Jari Arkko wrote: > > Interesting idea. In a way, this happens when the router and the > > first node are upgraded to SEND: everyone else sends their ND > > packets to the router, and all communications of the one SEND > > node come through the router. The SEND node believes it is the > > only node on the link. The other nodes are not on the link, > > and ND is not used for communicating with them. Just like > > any other node in the Internet. > > Yep. > I am a bit confused by this. If "L" bit is set in the RA, then all nodes will think all other nodes covered by that prefix is on-link. In that case all nodes on that link covered by that prefix will send the advertisements to solicited node multicast address of the target node directly i.e how do you make the nodes send the ND packets to the router ? It would work if one never sets the L bit in that case. But as the SEND hosts increase, you may want them to communicate directly rather than through the router. -mohan > > Obviously, the non-SEND nodes will not authorize the router > > or the router will not authorize them in any way. > > Yes, but if that'd help, the SEND router could perform certain proxy > functions on behalf of the SEND node for non-SEND nodes; naturally, > certain functions are already necessary, but some others > (e.g. the router > might not believe some types of messages used for ND spoofing or other > attacks) could also be added if that'd be of any help. Might get too > complicated, though.. > > > These are > > existing nodes. So for that we don't need secure proxy ND. > > Agree. > > > But I guess your question is if we can simply provide SEND > > for the RD part, and build secure ND from that? > > Yes. > > > For instance, since the host trusts the router's keys, it > would believe > > an NA sent by the router for a peer. The tricky part is, however, > > getting the router to believe the peer. And it needs to, otherwise > > sending an NA signed by the router would be pointless. With > delegation > > chain discovery, all hosts can trust the router. But how to > get mutual > > trust? This seems harder, basically something that would > require host > > certs or CGA. And if you have those, is there a need for > the router to > > act as a mediator? > > In particular, all the SEND nodes might not have shared roots > -- it might > be difficult to have everyone trust everyone else. The > approach here is > secure proxy-ND. However, this could be made a bit more streamlined: > there has to be a trust relationship with the router and host A. The > router could (maybe, can't estimate the complexity and the overhead), > certify to node B that node A is a "good guy", which might help in > building an association with node A and B. > > It seems (quick thinking) to me that the approach for host-host > communication could be one of: > > 1) CGA > 2) secure proxy-ND through router > 3) router certifying host A to host B and vice versa: assistance in > delegation chain discovery between the hosts if they don't have shared > roots. > 4) fallback to insecure ND or the like if two hosts have no > shared roots > (ie. operational imperative to "get enough roots and certificates!") > > However, the SEND protocol is quite unclear to me yet on how > exactly the > certifying process even between a router/host would work > without CGA. In > particular, it seems some certificatetied to certain global and even > link-local addresses which the other party can verify is needed. This > brings up the question how that kind of certifying process > could be done > (particularly the link-local part, which seems like something only the > admin of the link could be able to give -- which would lead > to either a > trivial or a very difficult solution). > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 Mar 10 01:39:36 2003 Received: from penguin.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 BAA18828 for ; Mon, 10 Mar 2003 01:39:36 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2A6cfwv010279; Mon, 10 Mar 2003 07:38:41 +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.2655.55) id FDVNHHKY; Mon, 10 Mar 2003 07:38:40 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2A6ce223290; Mon, 10 Mar 2003 07:38:40 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2A6cGYl007940; Mon, 10 Mar 2003 07:38:16 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2A6cGn0007939; Mon, 10 Mar 2003 07:38:16 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2A6cEYl007935 for ; Mon, 10 Mar 2003 07:38:15 +0100 (MET) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2A6bZu23768; Mon, 10 Mar 2003 08:37:35 +0200 Date: Mon, 10 Mar 2003 08:37:35 +0200 (EET) From: Pekka Savola To: Mohan Parthasarathy cc: Jari Arkko , James Kempf , Subject: RE: Proxy ND? In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E0134A3E8@TNEXVS02.tahoenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk On Sun, 9 Mar 2003, Mohan Parthasarathy wrote: > > On Sun, 9 Mar 2003, Jari Arkko wrote: > > > Interesting idea. In a way, this happens when the router and the > > > first node are upgraded to SEND: everyone else sends their ND > > > packets to the router, and all communications of the one SEND > > > node come through the router. The SEND node believes it is the > > > only node on the link. The other nodes are not on the link, > > > and ND is not used for communicating with them. Just like > > > any other node in the Internet. > > > > Yep. > > > > I am a bit confused by this. If "L" bit is set in the RA, then all > nodes will think all other nodes covered by that prefix is on-link. > In that case all nodes on that link covered by that prefix > will send the advertisements to solicited node multicast address of > the target node directly i.e how do you make the nodes send the ND packets > to the router ? It would work if one never sets the L bit in that case. > But as the SEND hosts increase, you may want them to communicate directly > rather than through the router. The neighbor solicitations are sent to the solicited-node multicast address. However, the on-link target node will not respond to them: it will not even see them (because they're protected by AH and the target node can't verify AH). This could be worked around by e.g.: Modify the ND prototocol so that in the case of SEND: 1) solicits are sent to all-nodes multicast address, or 2) the SEND router also joins all solicited-node multicast addresses for non-SEND nodes so it can see the solicitations -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Mar 10 01:59:22 2003 Received: from albatross.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 BAA22550 for ; Mon, 10 Mar 2003 01:59:21 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2A6wSB3017232; Mon, 10 Mar 2003 07:58:28 +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.2655.55) id FDVNHK3L; Mon, 10 Mar 2003 07:58:27 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2A6wR223742; Mon, 10 Mar 2003 07:58:27 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2A6v6Yl009770; Mon, 10 Mar 2003 07:57:06 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2A6v5cA009769; Mon, 10 Mar 2003 07:57:05 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2A6v5Yl009765 for ; Mon, 10 Mar 2003 07:57:05 +0100 (MET) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 062B21C for ; Mon, 10 Mar 2003 09:07:13 +0200 (EET) Message-ID: <3E6C374C.4090407@nomadiclab.com> Date: Mon, 10 Mar 2003 08:57:16 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030220 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: Re: psreq issue#1: Should draft-psreq discuss solutions at all? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit I seem to be getting a very mixed signal on including any solutions text to the draft. Some people clearly oppose, some people think it is fine. To resolve this for now, I'll do the following, unless someone strongly opposes. 1. I'll leave the solution text to the draft, and try to add some clarifications as requested in a number of other issues. 2. At the same time, I will enclose all solution text in [[double brackets]], making it easy to recognize it and remove it later, if wanted. --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 Mon Mar 10 02:36:05 2003 Received: from penguin.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 CAA10346 for ; Mon, 10 Mar 2003 02:36:05 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2A7Z8wv019800; Mon, 10 Mar 2003 08:35:08 +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.2655.55) id FDVNHSVF; Mon, 10 Mar 2003 08:35:07 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2A7Z7224971; Mon, 10 Mar 2003 08:35:07 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2A7YOYl016428; Mon, 10 Mar 2003 08:34:24 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2A7YNcI016427; Mon, 10 Mar 2003 08:34: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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2A7YMYl016423 for ; Mon, 10 Mar 2003 08:34:22 +0100 (MET) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id D3C011C; Mon, 10 Mar 2003 09:44:30 +0200 (EET) Message-ID: <3E6C400A.8090409@nomadiclab.com> Date: Mon, 10 Mar 2003 09:34:34 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030220 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Cc: Craig Metz Subject: psreq issue#24: trust models 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 http://www.tml.hut.fi/~pnr/SEND/issues/issue24.txt In his comments, Craig Metz opinioned that the current trust model which is based on three scenarios should be replaced with one based on only two scenarios. While I agree that the scenarios Craig describes in his message are perhaps technically closer to what we expect the solutions to be in reality, I still think that the current three scenarios model is appropriate since it describes potential deployment schemes. What is the feeling of the WG? Should we adopt Craig's proposal, or stick with the current structure? --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 Mon Mar 10 03:01:03 2003 Received: from penguin.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 DAA14860 for ; Mon, 10 Mar 2003 03:01:02 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2A80bwv026279; Mon, 10 Mar 2003 09:00:37 +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.2655.55) id GPH51NDJ; Mon, 10 Mar 2003 09:00:36 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2A80PK19078; Mon, 10 Mar 2003 09:00:25 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2A7xeYl018546; Mon, 10 Mar 2003 08:59:40 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2A7xe1Q018545; Mon, 10 Mar 2003 08:59:40 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2A7xdYl018541 for ; Mon, 10 Mar 2003 08:59:39 +0100 (MET) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2A7xbt24322; Mon, 10 Mar 2003 09:59:37 +0200 Date: Mon, 10 Mar 2003 09:59:37 +0200 (EET) From: Pekka Savola To: Pekka Nikander cc: SEND WG , Craig Metz Subject: Re: psreq issue#24: trust models In-Reply-To: <3E6C400A.8090409@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk On Mon, 10 Mar 2003, Pekka Nikander wrote: > What is the feeling of the WG? Should we adopt > Craig's proposal, or stick with the current structure? I think the current structure is good. Basically it seems like a similar approach with nuances: centralized/decentralized is basically just wording 3.1/3.2 and 3.3 a bit differently -- and I believe the current models are closer to the deployment scenarios. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Mar 10 08:18:06 2003 Received: from albatross.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 IAA13197 for ; Mon, 10 Mar 2003 08:18:05 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2ADHoB3018736; Mon, 10 Mar 2003 14:17:51 +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.2655.55) id FDVNKZL2; Mon, 10 Mar 2003 14:17:50 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2ADHlK01376; Mon, 10 Mar 2003 14:17:47 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2ADHKYl028255; Mon, 10 Mar 2003 14:17:20 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2ADHKWY028254; Mon, 10 Mar 2003 14:17:20 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2ADHJYl028247 for ; Mon, 10 Mar 2003 14:17:19 +0100 (MET) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 5C4791C for ; Mon, 10 Mar 2003 15:27:27 +0200 (EET) Message-ID: <3E6C906B.4090001@ericsson.com> Date: Mon, 10 Mar 2003 15:17:31 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030220 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: psreq issues 6 - 10, 15, and 18 - 22 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 See http://www.tml.hut.fi/~pnr/SEND/issues.html I resolved the following issues as follows. The rationale behind several was that since I earlier decided to include solutions text in [[brackets]], it follows logically that new suggested solutions text should be added as such. The diffs between the -01 version and the current version are available at http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-psreq-02-from-1.diff.html 6 Clarify operator certification capability in 4.1.1 New text added, in [[brackets]], to 4.1.1 7 Should the document talk about solutions in 4.2.1? New text added, in [[brackets]], to 4.2.1 8 Add reference to secure DHCP in Section 4.2.6 Added discussion how secure DHCP does not solve all problems. 9 Remove mitigation approaches from 4.3.1 REJECTED. Text moved into [[brackets]] 10 Clarify the meaning of '+' in Section 4.4. New text added. 15 Add flooding DoS as a separate threat category New text added. 18 Recommend refusal of override bit? New text added, in [[brackets]]. 19 Recommend that only /64 on-link prefixes are accepted New text added, in [[brackets]]. 20 New subthreat: flooding host's routing table New text added. 21 Add a note about DDNS access controls REJECTED. Falls beyond the scope of the draft. 22 Add a note that small hop limits should not be accepted. New text added, in [[brackets]]. -------------------------------------------------------------------- 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 Mar 10 12:29:51 2003 Received: from albatross.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 MAA04599 for ; Mon, 10 Mar 2003 12:29:51 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2AHT8B3002919; Mon, 10 Mar 2003 18:29:08 +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.2655.55) id FDVNM8SX; Mon, 10 Mar 2003 18:29:07 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2AHT7214590; Mon, 10 Mar 2003 18:29:07 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2AHSVYl026294; Mon, 10 Mar 2003 18:28:31 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2AHSUj1026292; Mon, 10 Mar 2003 18:28:30 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2AHSSYl026288 for ; Mon, 10 Mar 2003 18:28:29 +0100 (MET) Message-ID: <00a901c2e72a$3c3eda70$156015ac@T23KEMPF> From: "James Kempf" To: "Pekka Savola" , Cc: "Kempf" References: Subject: Re: Send protocol and CGA Date: Mon, 10 Mar 2003 09:26:49 -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 Pekka, IPR encumbered technology can be and has been incorporated into IETF standards. An example is ROHC, the IPR within that draft is offered on a RAND basis. The current IETF IPR rules are not like W3C in this regard, though there is a working group discussing changes. That said, as a general rule, standards which are IPR free are preferable to those with IPR, and standards with free IPR (such as the Photuris, RFC 1822, which was incorporated into IPsec) are preferable to RAND. Particularly with something so basic as SEND, having RAND IPR is likely to cause the mechanism not to be widely implemented, effectively making it useless. PekkaN and I are currently working with Ericsson and Microsoft in order to get CGAs released as free IPR for the purposes of SEND, to address the issue that you mention. We expect the release, should it occur, to be similar to RFC 1822. Please take some time to look at RFC 1822 and see if it meets your concerns. Of course, these things take time and we do not expect a complete statement of release by the SFO meeting. If our efforts in this area should fail, we have a fallback position. The draft currently discusses using host certificates for securing NA, and we would in the event of failure remove CGAs leaving host certificates as the only mechanism. From a technical standpoint, host certificates are an inferior mechanism because they require provisioning of hosts with certificates, which is something that nobody has quite managed to get to work yet. However, if we have to make that the only mechanism, we will. As far as we know (and participants in IETF work MUST disclose this information) there is no other IPR on the draft. Regarding your specific comments on the draft, we could probably do better in describing how to use host certificates, currently, the draft is focussed on CGAs because the DT believes they are a superior mechanism. We will clean that up in the next round. jak ----- Original Message ----- From: "Pekka Savola" To: Sent: Saturday, March 08, 2003 12:07 AM Subject: Send protocol and CGA > Hello, > > The send protocol spec is quite well written (a lot of comments in the > queue in a separate mail), but there is one really imporant aspect I'd > like the w.g. to consider. > > That is, the base protocol and interactions with (encumbered) CGA. > > Really, everything related to CGA must be thrown out of the base spec, and > placed in separate draft(s). I thought this was the design decision early > on, has it changed or am I misunderstanding something? > > My reasoning here is: > - it is too difficult to read the protocol and assess its usability and > completeness when CGA parts (which will *NOT* be used by some) are there > > - the base protocol is too closely interconnected to CGA parts (for > instance check out the second bullet of section 10), and constitute a > significant portion of already-long specification > > - securing ND is such an important issue, potentially affecting all > nodes, that using encumbered technology is completely unacceptable. > > - when the organizations will be filing IPR disclosures, many of them are > likely to just give a blanket statement like "some portions of > ietf-send-ipsec-nn contain our IPR". This makes it difficult to assess > whether *some other* portions (which are considered "free") of the spec > (e.g. trust anchors etc.) have IPR claims. > > Therefore, I strongly request pulling CGA out of the spec before going any > further with it, and before those with claims on CGA make IPR disclosures > on it. > > btw. which organizations had IPR claims on CGA? I thought at least > Ericsson and Microsoft do, but only Microsoft has made IPR disclosure at > www.ietf.org/ipr/ (and has not made the disclosure on more recent > documents) -- if so, certainly a violation of the process. Docomolabs > also has something on PBK, but not sure whether on CGA? If I believed in > conspiracies, 3 out of 4 in the author list the employers of which have > significant vested interest in CGA-like mechanisms, would be sounding > alarm bells quite loudly. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 Mar 10 12:36:10 2003 Received: from penguin.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 MAA04874 for ; Mon, 10 Mar 2003 12:36:10 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2AHZ1wv006306; Mon, 10 Mar 2003 18:35:01 +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.2655.55) id FDVNM93V; Mon, 10 Mar 2003 18:35:01 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2AHZ0K10877; Mon, 10 Mar 2003 18:35:00 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2AHYpYl027690; Mon, 10 Mar 2003 18:34:51 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2AHYp1D027689; Mon, 10 Mar 2003 18:34: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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2AHYnYl027685 for ; Mon, 10 Mar 2003 18:34:50 +0100 (MET) Message-ID: <00e801c2e72b$1f537b90$156015ac@T23KEMPF> From: "James Kempf" To: "Pekka Savola" , "Jari Arkko" Cc: References: Subject: Re: Send protocol and CGA Date: Mon, 10 Mar 2003 09:33:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > However, looking back at the previous licensing statements from Microsoft, > I can be about 99.9% certain that there will be no hope here. > Microsoft has, in the past, released IPR for standards work. For example, they released some IPR to W3C. > So, it seems to me that a single protocol, be it with CGA or without CGA, > must be specified in one document if we want to manage the SEND case > quickly. > Agree. > (Another question altogether is whether we have sufficient pieces in place > to support a SEND model without CGA...) > The DT has discussed the non-CGA case, but not as extensively. It needs more attention. 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 Mar 10 12:50:12 2003 Received: from albatross.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 MAA05470 for ; Mon, 10 Mar 2003 12:50:11 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2AHn8B3005784; Mon, 10 Mar 2003 18:49:09 +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.2655.55) id GPHJK4K0; Mon, 10 Mar 2003 18:49:08 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2AHn7215231; Mon, 10 Mar 2003 18:49:07 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2AHmoYl029186; Mon, 10 Mar 2003 18:48:50 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2AHmn2I029181; Mon, 10 Mar 2003 18:48: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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2AHmlYl029156 for ; Mon, 10 Mar 2003 18:48:48 +0100 (MET) Message-ID: <01f501c2e72d$14645720$156015ac@T23KEMPF> From: "James Kempf" To: "Pekka Nikander" , "SEND WG" References: <3E6C374C.4090407@nomadiclab.com> Subject: Re: psreq issue#1: Should draft-psreq discuss solutions at all? Date: Mon, 10 Mar 2003 09:47:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, I'm fine with leaving it in if there is concensus. Let's revisit in SFO. jak ----- Original Message ----- From: "Pekka Nikander" To: "SEND WG" Sent: Sunday, March 09, 2003 10:57 PM Subject: Re: psreq issue#1: Should draft-psreq discuss solutions at all? > I seem to be getting a very mixed signal on including > any solutions text to the draft. Some people clearly > oppose, some people think it is fine. > > To resolve this for now, I'll do the following, unless > someone strongly opposes. > > 1. I'll leave the solution text to the draft, and > try to add some clarifications as requested in > a number of other issues. > > 2. At the same time, I will enclose all solution > text in [[double brackets]], making it easy to > recognize it and remove it later, if wanted. > > --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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 Mar 10 12:51:28 2003 Received: from albatross.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 MAA05501 for ; Mon, 10 Mar 2003 12:51:27 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2AHp4B3006167; Mon, 10 Mar 2003 18:51:04 +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.2655.55) id GPH5JTQM; Mon, 10 Mar 2003 18:51:04 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2AHp3215312; Mon, 10 Mar 2003 18:51:03 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2AHowYl029412; Mon, 10 Mar 2003 18:50:58 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2AHowFp029411; Mon, 10 Mar 2003 18:50: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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2AHouYl029403 for ; Mon, 10 Mar 2003 18:50:57 +0100 (MET) Message-ID: <01fd01c2e72d$5d30d0a0$156015ac@T23KEMPF> From: "James Kempf" To: "Pekka Nikander" , "SEND WG" Cc: "Craig Metz" References: <3E6C400A.8090409@nomadiclab.com> Subject: Re: psreq issue#24: trust models Date: Mon, 10 Mar 2003 09:49:13 -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 like the three trust models. They may not capture every situation exactly, but I think they represent three fairly common points on a continuum of deployment situations. The ad hoc case is certainly not very common today, but perhaps more common in the future. We might ask for some help here with someone having more operations experience. jak ----- Original Message ----- From: "Pekka Nikander" To: "SEND WG" Cc: "Craig Metz" Sent: Sunday, March 09, 2003 11:34 PM Subject: psreq issue#24: trust models > http://www.tml.hut.fi/~pnr/SEND/issues/issue24.txt > > In his comments, Craig Metz opinioned that the current > trust model which is based on three scenarios should > be replaced with one based on only two scenarios. > > > > While I agree that the scenarios Craig describes in > his message are perhaps technically closer to what > we expect the solutions to be in reality, I still > think that the current three scenarios model is > appropriate since it describes potential deployment > schemes. > > > > What is the feeling of the WG? Should we adopt > Craig's proposal, or stick with the current structure? > > --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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 Mar 10 13:23:57 2003 Received: from penguin.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 NAA06664 for ; Mon, 10 Mar 2003 13:23:56 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2AIN1wv012470; Mon, 10 Mar 2003 19:23:01 +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.2655.55) id GPH5JY3X; Mon, 10 Mar 2003 19:23:00 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2AIMxK12462; Mon, 10 Mar 2003 19:22:59 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2AIMjYl003023; Mon, 10 Mar 2003 19:22:45 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2AIMjRE003022; Mon, 10 Mar 2003 19:22:45 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from TNEXVS01.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2AIMgYl003011 for ; Mon, 10 Mar 2003 19:22:43 +0100 (MET) Received: from TNEXVS02.tahoenetworks.com ([10.10.1.132]) by TNEXVS01.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Mar 2003 10:22:39 -0800 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Proxy ND? Date: Mon, 10 Mar 2003 10:22:38 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A3E9@TNEXVS02.tahoenetworks.com> Thread-Topic: Proxy ND? Thread-Index: AcLmz56mlQGBgKYqRruebbmlBmUhswAXwGBg From: "Mohan Parthasarathy" To: "Pekka Savola" Cc: "Jari Arkko" , "James Kempf" , X-OriginalArrivalTime: 10 Mar 2003 18:22:39.0555 (UTC) FILETIME=[086D3130:01C2E732] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h2AIMiYl003012 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Pekka, > > On Sun, 9 Mar 2003, Mohan Parthasarathy wrote: > > > On Sun, 9 Mar 2003, Jari Arkko wrote: > > > > Interesting idea. In a way, this happens when the router and the > > > > first node are upgraded to SEND: everyone else sends their ND > > > > packets to the router, and all communications of the one SEND > > > > node come through the router. The SEND node believes it is the > > > > only node on the link. The other nodes are not on the link, > > > > and ND is not used for communicating with them. Just like > > > > any other node in the Internet. > > > > > > Yep. > > > > > > > I am a bit confused by this. If "L" bit is set in the RA, then all > > nodes will think all other nodes covered by that prefix is on-link. > > In that case all nodes on that link covered by that prefix > > will send the advertisements to solicited node multicast address of > > the target node directly i.e how do you make the nodes send > the ND packets > > to the router ? It would work if one never sets the L bit > in that case. > > But as the SEND hosts increase, you may want them to > communicate directly > > rather than through the router. > > The neighbor solicitations are sent to the solicited-node multicast > address. However, the on-link target node will not respond > to them: it > will not even see them (because they're protected by AH and > the target > node can't verify AH). > Agreed. > This could be worked around by e.g.: > > Modify the ND prototocol so that in the case of SEND: > 1) solicits are sent to all-nodes multicast address, or This requires the changes to the existing protocol, which may not be in the scope of the WG. > 2) the SEND router also joins all solicited-node multicast > addresses for > non-SEND nodes so it can see the solicitations Or listen for all multicast packets (like multicast router) which is more realistic to me. There are 2 cases : 1) ND packets coming from non-SEND nodes to SEND nodes. SEND node will drop the ND packet as it is not protected. The router will pick up this packet and it needs different set of IPsec processing rules i.e it needs to know whether the node that sent the ND packet is non-SEND or SEND. Assuming it accepts the packet, either it may have to initiate a NS (as it may not have neighbor cache entry) and then respond or directly respond. 2) ND packets coming from SEND nodes to non-SEND nodes. Non-send nodes will drop the ND packet as it is protected. The router will pick up this packet and sends the response directly or after querying the non-SEND node. From what i can understand, this seems to require some additional state to be maintained as the router itself may not have the required neighbor cache entry. If you don't want to maintain state, then the response needs to be multicasted. And, i am still not clear on how you will configure the IPsec SPD entries on the SEND router. -mohan > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Mar 10 18:47:27 2003 Received: from albatross.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 SAA21159 for ; Mon, 10 Mar 2003 18:47:27 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2ANkMB3017410; Tue, 11 Mar 2003 00:46:22 +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.2655.55) id GPH5L1AT; Tue, 11 Mar 2003 00:46:22 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2ANkKK22179; Tue, 11 Mar 2003 00:46:20 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2ANjoYl009842; Tue, 11 Mar 2003 00:45:50 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2ANjomC009841; Tue, 11 Mar 2003 00:45:50 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2ANjmYl009837 for ; Tue, 11 Mar 2003 00:45:49 +0100 (MET) Message-ID: <046c01c2e75e$f3b98900$156015ac@T23KEMPF> From: "James Kempf" To: "Jari Arkko" Cc: References: <01ba01c2e4d9$864a2f00$156015ac@T23KEMPF> <3E68FBAB.9070005@kolumbus.fi> <00c901c2e4f5$016baef0$156015ac@T23KEMPF> <3E69B92F.4060200@kolumbus.fi> Subject: Re: Proxy ND? Date: Mon, 10 Mar 2003 15:44:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > I haven't thought of whether this breaks some of the IPsec > processing rules we have. Have you? > Since there is no cryptographic tie between the frame address and the IP address, the host doing proxy ND can set the IP address on the packet to whatever it wants. > I was assuming it contains the PK as well. Yes, it could be big. > Actually, it might make sense for such certs to be distributed using > the DC mechanisms than in the AH packet itself. > Yes. Also, the cert could be self-signed if the host isn't provisioned, since provisioning of hosts is the hard case currently. 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 Tue Mar 11 05:49:31 2003 Received: from albatross.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 FAA15481 for ; Tue, 11 Mar 2003 05:49:30 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2BAmnB3021372; Tue, 11 Mar 2003 11:48:49 +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.2655.55) id FD4KG0FA; Tue, 11 Mar 2003 11:48:48 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2BAmm212598; Tue, 11 Mar 2003 11:48:48 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2BAmJYl018628; Tue, 11 Mar 2003 11:48:19 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2BAmJKK018627; Tue, 11 Mar 2003 11:48:19 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from albatross.wise.edt.ericsson.se ([193.180.251.49]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2BAmIYl018620 for ; Tue, 11 Mar 2003 11:48:18 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2BAmGB3021171; Tue, 11 Mar 2003 11:48:16 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 11 Mar 2003 11:48:16 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053807FEF730@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Pekka Nikander'" , "'SEND WG'" Subject: RE: psreq issue#1: Should draft-psreq discuss solutions at all? Date: Tue, 11 Mar 2003 11:48:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk > Now, on the light of this, I am solicitating well grounded > opinions on whether the next version of the draft should > include any text about solutions? > > If no, should the existing text be just removed or should > something else to be done to it. > > If yes, is the existing level of illustrative talk about > solutions appropriate, or should there be more/less > text? => I think "yes". I think having examples of solutions makes it easier to put things in context. Of course the problem is referencing these solutions in an RFC because later some of these drafts will expire. But you can usually find them anyway so I would say keep them. > > Additionally, if yes, should there be more informative > references to the possible solution approaches, or is the > current practice of mentioning or briefly describing the > solution approaches appropriate? => I think a very brief summary highlighting the main features should suffice. Hesham -------------------------------------------------------------------- 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 Mar 11 06:09:20 2003 Received: from albatross.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 GAA15827 for ; Tue, 11 Mar 2003 06:09:19 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2BB8wB3026811; Tue, 11 Mar 2003 12:08:58 +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.2655.55) id FDVNT1V8; Tue, 11 Mar 2003 12:08:57 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2BB8vK11417; Tue, 11 Mar 2003 12:08:57 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2BB8cYl021083; Tue, 11 Mar 2003 12:08:38 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2BB8cEv021082; Tue, 11 Mar 2003 12:08:38 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2BB8bYl021078 for ; Tue, 11 Mar 2003 12:08:37 +0100 (MET) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id F15DF1C; Tue, 11 Mar 2003 13:18:44 +0200 (EET) Message-ID: <3E6DC3BF.6030807@nomadiclab.com> Date: Tue, 11 Mar 2003 13:08:47 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030220 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG , Craig Metz Subject: psreq issue #11: Usage of the term "trust" 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 In the current draft we write: It should be noted that the term "trust" is used here in a rather non-technical and loose manner. The most appropriate interpretation is to consider it as an expression of an organizational or collective belief, i.e., an expression of commonly shared beliefs about the future behavior of the other involved parties. Conversely, the term "trust relationship" denotes a mutual a priori relationship between the involved organizations or parties where the parties believe that the other parties will behave correctly even in the future. A trust relationship makes it possible to configure authentication and authorization information between the parties, while the lack of such a relationship makes it impossible to pre-configure such information. Craig Metz comments on this (issue #11): Please DO NOT use the term trust in this loose manner. One of the single greatest problems I see in the security field is one of communication. More specifically, it's often the case that two people miscommunicate because they use precise terms for which each of them have slightly different understandings of their meanings. In crypto security, those slight differences are often critical. So it's very important to use the standard definitions strictly AND to provide precise background definitions of those terms also as an added protection against such miscommunication. The whole point of this document is to define trust models, so very rigid uses of to trust, trusted, and trusting are important. Put more simply, terminology is a huge rat hole, don't fall down it. Now, while I personally agree with Craig in the large, I disagree in this specific case. The draft is a problem statement draft, and while it defines trust models, it defines them in business terms, not in technical terms. Thus, I think it *is* appropriate to use the term in a non-technical manner. What comes to the "loose" manner, actually scanning the document for the word trust gives me the impression that it is *not* used in a loose manner any more. Thus, as a document editor, I propose that we resolve this issue simply by removing the words "and loose" from the paragraph above. While this does not change the substance of the document in any way, it seems to better reflect the true nature of the usage of the term in the document. Do you think this proposed resolution is OK? Or are there specific occurances of the words "trust", "trustworthy", or "trusted", which should be qualified better? --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 Tue Mar 11 08:36:58 2003 Received: from albatross.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 IAA18925 for ; Tue, 11 Mar 2003 08:36:57 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2BDanB3012749; Tue, 11 Mar 2003 14:36:49 +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.2655.55) id FDVN4NZ4; Tue, 11 Mar 2003 14:36:49 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2BDamK16971; Tue, 11 Mar 2003 14:36:48 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2BDaQYl008674; Tue, 11 Mar 2003 14:36:26 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2BDaQ91008673; Tue, 11 Mar 2003 14:36:26 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2BDaPYl008669 for ; Tue, 11 Mar 2003 14:36:25 +0100 (MET) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2BDaLQ03326; Tue, 11 Mar 2003 15:36:21 +0200 Date: Tue, 11 Mar 2003 15:36:20 +0200 (EET) From: Pekka Savola To: James Kempf cc: ietf-send@standards.ericsson.net Subject: Re: Send protocol and CGA In-Reply-To: <00a901c2e72a$3c3eda70$156015ac@T23KEMPF> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk On Mon, 10 Mar 2003, James Kempf wrote: > PekkaN and I are currently working with Ericsson and Microsoft in order to get > CGAs released as free IPR for the purposes of SEND, to address the issue that > you mention. We expect the release, should it occur, to be similar to RFC 1822. > Please take some time to look at RFC 1822 and see if it meets your concerns. Of > course, these things take time and we do not expect a complete statement of > release by the SFO meeting. A license similar to RFC1822 would seem sufficiently good to me, at least. Then, a CGA-only approach might be possible. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Mar 11 12:18:42 2003 Received: from albatross.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 MAA28513 for ; Tue, 11 Mar 2003 12:18:41 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2BHDrB3013847; Tue, 11 Mar 2003 18:13:53 +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.2655.55) id GPHJSCQK; Tue, 11 Mar 2003 18:13:53 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2BHDqK24680; Tue, 11 Mar 2003 18:13:52 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2BHDPYl005187; Tue, 11 Mar 2003 18:13:25 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2BHDPIv005186; Tue, 11 Mar 2003 18:13:25 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2BHDNYl005182 for ; Tue, 11 Mar 2003 18:13:23 +0100 (MET) Message-ID: <00e401c2e7f1$4b3a6d10$156015ac@T23KEMPF> From: "James Kempf" To: "Pekka Nikander" , "SEND WG" , "Craig Metz" References: <3E6DC3BF.6030807@nomadiclab.com> Subject: Re: psreq issue #11: Usage of the term "trust" Date: Tue, 11 Mar 2003 09:11: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 I agree with the change you are proposing, and think keeping the word trust is fine. It is being used at a human level, not cyber level, in this draft. jak ----- Original Message ----- From: "Pekka Nikander" To: "SEND WG" ; "Craig Metz" Sent: Tuesday, March 11, 2003 3:08 AM Subject: psreq issue #11: Usage of the term "trust" > In the current draft we write: > > It should be noted that the term "trust" is used here in a rather > non-technical and loose manner. The most appropriate interpretation > is to consider it as an expression of an organizational or > collective belief, i.e., an expression of commonly shared beliefs > about the future behavior of the other involved parties. > Conversely, the term "trust relationship" denotes a mutual a priori > relationship between the involved organizations or parties where the > parties believe that the other parties will behave correctly even in > the future. A trust relationship makes it possible to configure > authentication and authorization information between the parties, > while the lack of such a relationship makes it impossible to > pre-configure such information. > > Craig Metz comments on this (issue #11): > > Please DO NOT use the term trust in this loose manner. One of the > single greatest problems I see in the security field is one of > communication. More specifically, it's often the case that two > people miscommunicate because they use precise terms for which each of > them have slightly different understandings of their meanings. > In crypto security, those slight differences are often critical. > So it's very important to use the standard definitions strictly AND to > provide precise background definitions of those terms also as an > added protection against such miscommunication. > > The whole point of this document is to define trust models, so very > rigid uses of to trust, trusted, and trusting are important. > > Put more simply, terminology is a huge rat hole, don't fall > down it. > > > > Now, while I personally agree with Craig in the large, I disagree > in this specific case. The draft is a problem statement draft, > and while it defines trust models, it defines them in business > terms, not in technical terms. > > Thus, I think it *is* appropriate to use the term in a non-technical > manner. What comes to the "loose" manner, actually scanning the > document for the word trust gives me the impression that it is *not* > used in a loose manner any more. > > Thus, as a document editor, I propose that we resolve this > issue simply by removing the words "and loose" from the paragraph > above. While this does not change the substance of the document > in any way, it seems to better reflect the true nature of the > usage of the term in the document. > > > > Do you think this proposed resolution is OK? Or are there > specific occurances of the words "trust", "trustworthy", or > "trusted", which should be qualified better? > > --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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 Mar 11 14:11:25 2003 Received: from albatross.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 OAA04180 for ; Tue, 11 Mar 2003 14:11:24 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2BJ7PB3029005; Tue, 11 Mar 2003 20:07:25 +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.2655.55) id FDVNWZT8; Tue, 11 Mar 2003 20:07:25 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2BJ7OK27624; Tue, 11 Mar 2003 20:07:24 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2BJ6uYl018591; Tue, 11 Mar 2003 20:06:56 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2BJ6uaQ018590; Tue, 11 Mar 2003 20:06:56 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2BJ6sYl018586 for ; Tue, 11 Mar 2003 20:06:55 +0100 (MET) Message-ID: <01cb01c2e801$26bdf5f0$156015ac@T23KEMPF> From: "James Kempf" To: "Jari Arkko" , "Pekka Savola" Cc: References: <3E6AF513.2020108@kolumbus.fi> Subject: Secruity on Solicits (was: Re: Comments on SEND protocol) Date: Tue, 11 Mar 2003 11:05:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > > 4. Secure Neighbor Discovery Overview > > > > o IPsec AH is used to protect all advertisement messages relating to > > Neighbor and Router discovery. Solicitation messages are not > > protected, as they do not carry any information. > > > > ==> The latter sentence _incorrect_, and seems to be a show-stopper of a > > kind. > > Yes, and this is indeed the biggest problem in the protocol that I know > of at the moment. I think we mention it already in Section 14, by the way, > but we didn't have time to invent a solution. One approach would be to > avoid the solitications with an effect in SEND, but this would increase > the number of messages in typical situations, which would be unfortunate > for e.g. fast movements. More seriously, DAD would not work between two > nodes who are testing the same address at the same time. Also, we wouldn't > like to change the ND protocol as such. > > So what's wrong with just protecting solicitations in the same manner > as advertisements? The reason is tricky. Consider the DAD probes, where > the solicitation message has the unspecified address as a source, and the > solicited node multicast address as a destination. The tested address > appears within the ND packet in the Target Address option. If our > security solution is at the IPsec layer, how can we test that the > tested address and the signature have been associated in the right > way? (Whether that association is through a cert with an address or > via CGA is not relevant, but IPsec needs to access the address which > for now only appears inside the application layer.) > Even if an IPsec header were put on, what would be the IP address of the SA? DAD packets are sent with the unspecified address, as you indicate. This is a problem with the IPsec approach v.s. the ICMP option approach, but we committed to the IPsec approach now so it would be difficult to change. Perhaps we could specify a "Secure Target Address" option that contained the Target Address with a digital signature and the public key? This could be used in the DAD case. In the RS case, the packet is sent to the All Routers Multicast Address, but I believe it can have the link local unicast address of the node. I could also have the unspecified address, so the node could solicit a router before performing DAD, but we could require a node to not use the unspecified address. Or we could allow the "Secure Target Address" option in that case too, to allow the unspecified address. Note that if CGA addresses aren't used, the node receiving an NS with a Secure Target Address option doesn't have any assurance that the sending node has a right to claim the address, unless an authenticatable certificate is also included in the NS. 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 Tue Mar 11 14:20:57 2003 Received: from penguin.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 OAA05442 for ; Tue, 11 Mar 2003 14:20:56 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2BJJYwv022806; Tue, 11 Mar 2003 20:19: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.2655.55) id FDVNW6PY; Tue, 11 Mar 2003 20:19:33 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2BJJXK28162; Tue, 11 Mar 2003 20:19:33 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2BJJMYl020384; Tue, 11 Mar 2003 20:19:22 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2BJJMSG020383; Tue, 11 Mar 2003 20:19:22 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2BJJKYl020379 for ; Tue, 11 Mar 2003 20:19:21 +0100 (MET) Message-ID: <01d101c2e802$e3fdb9b0$156015ac@T23KEMPF> From: "James Kempf" To: "Jari Arkko" , "Pekka Savola" Cc: References: <3E6AFF2C.6000504@kolumbus.fi> Subject: Re: Proxy ND? Date: Tue, 11 Mar 2003 11:17: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 Jari, > But I guess your question is if we can simply provide SEND > for the RD part, and build secure ND from that? For instance, > since the host trusts the router's keys, it would believe an > NA sent by the router for a peer. The tricky part is, however, > getting the router to believe the peer. And it needs to, otherwise > sending an NA signed by the router would be pointless. With > delegation chain discovery, all hosts can trust the router. But > how to get mutual trust? This seems harder, basically something that > would require host certs or CGA. And if you have those, is > there a need for the router to act as a mediator? > Suppose instead of securing ND, SEND simply turns it off. That is, a node establishes a security association with the router and routes all packets through it, regardless of whether they are on the local link or not. So the NS/NA messages are never sent for routing purposes. One issue I can see with this is with DAD. We would have to specify some way for router to do that. I suppose we would have specify some changes to the Neighbor Cache, so that hosts owning addresses (and can prove ownership) renew them like DHCP leases do by sending periodic NAs to the router. The router would have to do proxy ND. As for mutual trust, I agree this is an issue. It would require that hosts be provisioned with their own certificates, something that has so far escaped the Internet world. If CGAs are used, the router can know that the host is authorized to use the address. But this seems like a pretty big change to RFC 2461, so it would be better if we could avoid it. 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 Tue Mar 11 14:21:54 2003 Received: from albatross.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 OAA05558 for ; Tue, 11 Mar 2003 14:21:53 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2BJLSB3000135; Tue, 11 Mar 2003 20:21:28 +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.2655.55) id FDVNW65G; Tue, 11 Mar 2003 20:21:27 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2BJLQ228181; Tue, 11 Mar 2003 20:21:26 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2BJLKYl020519; Tue, 11 Mar 2003 20:21:20 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2BJLKh0020518; Tue, 11 Mar 2003 20:21:20 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2BJLIYl020514 for ; Tue, 11 Mar 2003 20:21:19 +0100 (MET) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11923; Tue, 11 Mar 2003 11:21:14 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2BJLEuK028884; Tue, 11 Mar 2003 14:21:14 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BJLDaj028322; Tue, 11 Mar 2003 14:21:13 -0500 (EST) Message-Id: <200303111921.h2BJLDaj028322@thunk.east.sun.com> From: Bill Sommerfeld To: Pekka Nikander cc: SEND WG , Craig Metz Subject: Re: psreq issue #11: Usage of the term "trust" In-Reply-To: Your message of "Tue, 11 Mar 2003 13:08:47 +0200." <3E6DC3BF.6030807@nomadiclab.com> Reply-to: sommerfeld@east.sun.com Date: Tue, 11 Mar 2003 14:21:13 -0500 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk For what it's worth, I've also suggested being more precise here. "Trust" is itself a rather vague word. I think it's better to use words like "authorization" and "delegation", and specify precisely what is authorized and how authorizations are delegated and.. - Bill -------------------------------------------------------------------- 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 Mar 11 14:24:13 2003 Received: from albatross.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 OAA05949 for ; Tue, 11 Mar 2003 14:24:12 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2BJO1B3000275; Tue, 11 Mar 2003 20:24:01 +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.2655.55) id GPH5T4FN; Tue, 11 Mar 2003 20:24:00 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2BJNx228263; Tue, 11 Mar 2003 20:23:59 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2BJNqYl020621; Tue, 11 Mar 2003 20:23:52 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2BJNqEO020620; Tue, 11 Mar 2003 20:23:52 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2BJNoYl020616 for ; Tue, 11 Mar 2003 20:23:51 +0100 (MET) Message-ID: <01d901c2e803$80a79f10$156015ac@T23KEMPF> From: "James Kempf" To: "Tuomas Aura" , References: Subject: Re: Factoring the spec into digestible pieces (RE: Send protocol and CGA) Date: Tue, 11 Mar 2003 11:22: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 The IPsec RSA transform is a candidate for sectioning off, but so far we have not seen any interest from the IPsec group in this. I pinged Steve Bellovin on it, as there was a draft in IPSEC WG earlier about such a transform (but considerably sketchier than that in the SEND draft) and also Barbara Frasier. Steve said he didn't think there was much interest and Barbara confirmed his observation by not responding to my email. :-) Removing it might slow down progress but I agree that having byte size chunks helps (MIPv6 spec is too big). Let's talk about this at the WG meeting. jak ----- Original Message ----- From: "Tuomas Aura" To: Sent: Sunday, March 09, 2003 9:59 AM Subject: Factoring the spec into digestible pieces (RE: Send protocol and CGA) > Pekka Savola wrote: > > Really, everything related to CGA must be thrown out of the > > base spec, and placed in separate draft(s). I thought this > > was the design decision early on, has it changed or am I > > misunderstanding something? > > I also think that the IPSec extensions should be factored out > into a separate spec. Like CGA, they may have other uses > beyond SEND. > > Let's keep this in small and digestible pieces, and make those > pieces as universally usable as possible. Otherwise, we will > have another giant spec that is impossible to check for > completeness and consistency. (I'm sure Jari knows what > particular prior example I'm thinking of.) > > Tuomas > > -------------------------------------------------------------------- > 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 Tue Mar 11 16:39:39 2003 Received: from penguin.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 QAA13264 for ; Tue, 11 Mar 2003 16:39:38 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2BLd8wv007084; Tue, 11 Mar 2003 22:39:08 +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.2655.55) id GPH54H58; Tue, 11 Mar 2003 22:39:08 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2BLd7K02040; Tue, 11 Mar 2003 22:39:07 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2BLcVYl005781; Tue, 11 Mar 2003 22:38:31 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2BLcV5i005780; Tue, 11 Mar 2003 22:38:31 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from freemail.com.au ([200.252.129.26]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with SMTP id h2BLcPYl005773 for ; Tue, 11 Mar 2003 22:38:26 +0100 (MET) Message-ID: <9049bd5223a7$e3672e8b$4ffb917a@xxwuojmijhax.gj> From: To: Postmaster@standards.ericsson.net Subject: Toner Cartridges For Printer, Copier And Fax Machines Date: Tue, 11 Mar 2003 17:13:58 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_477_F463_89E693E6.7CA06C49" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk ------=_NextPart_477_F463_89E693E6.7CA06C49 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit ------=_NextPart_477_F463_89E693E6.7CA06C49 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit GT TONER SUPPLIES Laser printer and computer supplies 1

GT TONER SUPPLIES
Laser printer and computer supplies
1-888-662-2256
1-866-237-7397

 

Save up to 40% from retail price on laser printer toner cartridges,
copier and fax cartridges

CHECK OUT OUR GREAT PRICES AT THE BOTTOM !

If you received this email on error, please reply to gtts002@cable.net.co with subject: REMOVE... sorry for the inconvenience.

Please forward to the person responsible for purchasing your laser printer supplies

  • Order by phone: Toll free 1-866-237-7397   Toll free 1-888-662-2256

  • Order by email:  gtts002@cable.net.co  subject: ORDER

University and/or School purchase orders WELCOME. (no credit approval required)
Pay by check, c.o.d, or purchase order (net 30 days).

WE ACCEPT ALL MAJOR CREDIT CARDS!

New! HP 4500/4550 series color cartridges in stock!

Our cartridge prices are as follows:
(please order by item number)

Item                Hewlett Packard                   Price

1 -- 92274A Toner Cartridge for LaserJet 4L, 4ML, 4P, 4MP ------------------------$47.50
2 -- C4092A Black Toner Cartridge for LaserJet 1100A, ASE, 3200SE-----------------$45.50
2A - C7115A Toner Cartridge For HP LaserJet 1000, 1200, 3330 ---------------------$55.50
2B - C7115X High Capacity Toner Cartridge for HP LaserJet 1000, 1200, 3330 -------$65.50
3 -- 92295A Toner Cartridge for LaserJet II, IID, III, IIID ----------------------$49.50
4 -- 92275A Toner Cartridge for LaserJet IIP, IIP+, IIIP -------------------------$55.50
5 -- C3903A Toner Cartridge for LaserJet 5P, 5MP, 6P, 6Pse, 6MP, 6Pxi ------------$46.50
6 -- C3909A Toner Cartridge for LaserJet 5Si, 5SiMX, 5Si Copier, 8000 ------------$92.50
7 -- C4096A Toner Cartridge for LaserJet 2100, 2200DSE, 2200DTN ------------------$72.50
8 - C4182X UltraPrecise High Capacity Toner Cartridge for LaserJet 8100 Series---$125.50
9 -- C3906A Toner Cartridge for LaserJet 5L, 5L Xtra, 6Lse, 6L, 6Lxi, 3100se------$42.50
9A - C3906A Toner Cartridge for LaserJet 3100, 3150 ------------------------------$42.50
10 - C3900A Black Toner Cartridge for HP LaserJet 4MV, 4V ------------------------$89.50
11 - C4127A Black Toner Cartridge for LaserJet 4000SE, 4000N, 4000T, 4000TN ------$76.50
11A- C8061A Black Laser Toner for HP LaserJet 4100, 4100N ------------------------$76.50
11B- C8061X High Capacity Toner Cartridge for LJ4100, 4100N ----------------------$85.50
11C- C4127X High Capacity Black Cartridge for LaserJet 4000SE,4000N,4000T,4000TN -$84.50
12 - 92291A Toner Cartridge for LaserJet IIISi, 4Si, 4SiMX -----------------------$57.50
13 - 92298A Toner Cartridge for LaserJet 4, 4 Plus, 4M, 4M Plus, 5, 5se, 5M, 5N --$46.50
14 - C4129X High Capacity Black Toner Cartridge for LaserJet 5000N ---------------$97.50
15 - LASERFAX 500, 700 (FX1) -----------------------------------------------------$49.00
16 - LASERFAX 5000, 7000 (FX2) ---------------------------------------------------$54.00
17 - LASERFAX (FX3) --------------------------------------------------------------$49.00
18 - LASERFAX (FX4) --------------------------------------------------------------$49.00

Item            Hewlett Packard - Color                   Price

C1 -- C4194a Toner Cartridge, Yellow (color lj 4500/4550 series)------------------ $ 89.50
C2 -- C4193a Toner Cartridge, Magenta (color lj 4500/4550 series)----------------- $ 89.50
C3 -- C4192a toner cartridge, cyan (color lj 4500/4550 series)-------------------- $ 89.50
C4 -- c4191a toner cartridge, black (color lj 4500/4550 series)------------------- $ 74.50

Item                    Lexmark                         Price

19 - 1380520 High Yield Black Laser Toner for 4019, 4019E, 4028, 4029, 6, 10, 10L -- $109.50
20 - 1382150 High Yield Toner for 3112, 3116, 4039-10+, 4049- Model 12L,16R, Optra - $109.50
21 - 69G8256 Laser Cartridge for Optra E, E+, EP, ES, 4026, 4026 (6A,6B,6D,6E)  ---- $ 49.00
22 - 13T0101 High Yield Toner Cartridge for Lexmark Optra E310, E312, E312L -------- $ 89.00
23 - 1382625 High-Yield Laser Toner Cartridge for Lexmark Optra S (4059) ----------- $129.50
24 - 12A5745 High Yield Laser Toner for Lexmark Optra T610, 612, 614 (4069) -------- $165.00

Item                Epson                     Price

25 ---- S051009 Toner Cartridge for Epson EPL7000, 7500, 8000+ - $115.50
25A --- S051009 LP-3000 PS 7000 -------------------------------- $115.50
26 ---- AS051011 Imaging Cartridge for ActionLaser-1000, 1500 -- $ 99.50
26A --- AS051011 EPL-5000, EPL-5100, EPL-5200 ------------------ $ 99.50

Item            Panasonic                Price

27 ------Nec series 2 models 90 and 95 ---------------------- $109.50

Item                     Apple                                Price

28 ---- 2473G/A Laser Toner for LaserWriter Pro 600, 630, LaserWriter 16/600 PS - $ 57.50
29 ---- 1960G/A Laser Toner for Apple LaserWriter Select, 300, 310, 360 --------- $ 71.50
30 ---- M0089LL/A Toner Cartridge for Laserwriter 300, 320 (74A) ---------------- $ 52.50
31 ---- M6002 Toner Cartridge for Laserwriter IINT, IINTX, IISC, IIF, IIG (95A) - $ 47.50
31A --- M0089LL/A Toner Cartridge for Laserwriter LS, NT, NTR, SC (75A) --------- $ 55.50
32 ---- M4683G/A Laser Toner for LaserWriter 12, 640PS -------------------------- $ 85.50

Item                Canon                           Price

33 --- Fax CFX-L3500, CFX-4000 CFX-L4500, CFX-L4500IE & IF FX3 ----------- $ 49.50
33A -- L-250, L-260i, L-300 FX3 ------------------------------------------ $ 49.50
33B -- LASER CLASS 2060, 2060P, 4000 FX3 --------------------------------- $ 49.50
34 --- LASER CLASS 5000, 5500, 7000, 7100, 7500, 6000 FX2 ---------------- $ 49.50
34A ---LBP-200V, LBP-8 II, IIR, IIIT, IIIR EP-S--------------------------- $ 49.50
35 --- FAX 5000 FX2 ------------------------------------------------------ $ 49.50
36 --- LASER CLASS 8500, 9000, 9000L, 9000MS, 9500, 9500 MS, 9500 S FX4 -- $ 49.50
36A -- Fax L700,720,760,770,775,777,780,785,790, & L3300 FX1 ------------- $ 49.50
36B -- L-800, L-900 FX4 -------------------------------------------------- $ 49.50
37 --- A30R Toner Cartridge for PC-6, 6RE, 7, 11, 12 --------------------- $ 59.50
38 --- E-40 Toner Cartridge for PC-720, 740, 770, 790,795, 920, 950, 980 - $ 85.50
38A -- E-20 Toner Cartridge for PC-310, 325, 330, 330L, 400, 420, 430 ---- $ 85.50

Item   Xerox    Price

39 ---- 6R900 75A ---- $ 55.50
40 ---- 6R903 98A ---- $ 46.50
41 ---- 6R902 95A ---- $ 49.50
42 ---- 6R901 91A ---- $ 65.50
43 ---- 6R908 06A ---- $ 42.50
44 ---- 6R899 74A ---- $ 47.50
45 ---- 6R928 96A ---- $ 72.50
46 ---- 6R926 27X ---- $ 84.50
47 ---- 6R906 09A ---- $ 92.50
48 ---- 6R907 4MV ---- $ 89.50
49 ---- 6R905 03A ---- $ 46.50

call toll free 1-866-237-7397

30 Day unlimited warranty included on all products
GT Toner Supplies guarantees these cartridges to be free from defects in workmanship and material.

We look forward in doing business with you.

Customer  Satisfaction guaranteed !

If you are ordering by e-mail (subject:order) or c.o.d. please fill out an order
form with the following information:              

phone number
company name
first and last name
street address
city, state zip code         Order Now call toll free 1-866-237-7397

If you are ordering by purchase order please fill out an order form
with the following information:           

purchase order number
phone number
company or school name
shipping address and billing address
city, state zip code         Order Now call toll free 1-866-237-7397

All trade marks and brand names listed above are property of the respective
holders and used for descriptive purposes only.

 9372dDyk3-349jVHX9796UdWI9-163hvSS0524iVZk4-142gndG6647rfYG9-377yGub1013FmLm4-4l74 ------=_NextPart_477_F463_89E693E6.7CA06C49-- -------------------------------------------------------------------- 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 Mar 11 17:04:45 2003 Received: from albatross.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 RAA14393 for ; Tue, 11 Mar 2003 17:04:45 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2BM49B3015958; Tue, 11 Mar 2003 23:04:09 +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.2655.55) id FD4KL105; Tue, 11 Mar 2003 23:04:08 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2BM48202085; Tue, 11 Mar 2003 23:04:08 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2BM3vYl009167; Tue, 11 Mar 2003 23:03:57 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2BM3vtO009163; Tue, 11 Mar 2003 23:03:57 +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 (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2BM3tYl009143 for ; Tue, 11 Mar 2003 23:03:56 +0100 (MET) Received: from sandelman.ottawa.on.ca ([66.114.232.182]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h2BM3XD12601 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 11 Mar 2003 17:03:54 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h2BM3SWi006132 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 11 Mar 2003 14:03:29 -0800 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h2BM3RVw006129 for ; Tue, 11 Mar 2003 14:03:28 -0800 Message-Id: <200303112203.h2BM3RVw006129@marajade.sandelman.ottawa.on.ca> To: SEND WG Subject: Re: psreq issue #11: Usage of the term "trust" In-reply-to: Your message of "Tue, 11 Mar 2003 13:08:47 +0200." <3E6DC3BF.6030807@nomadiclab.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 11 Mar 2003 14:03:27 -0800 From: Michael Richardson Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk >>>>> "Pekka" == Pekka Nikander writes: Pekka> Now, while I personally agree with Craig in the large, I disagree Pekka> in this specific case. The draft is a problem statement draft, Pekka> and while it defines trust models, it defines them in business Pekka> terms, not in technical terms. A compromise is to use a new, nonsense (at least to english speakers) word. Pekka> Do you think this proposed resolution is OK? Or are there Pekka> specific occurances of the words "trust", "trustworthy", or Pekka> "trusted", which should be qualified better? I'm happy with your solution. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -------------------------------------------------------------------- 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 Mar 11 17:14:42 2003 Received: from penguin.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 RAA15022 for ; Tue, 11 Mar 2003 17:14:41 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2BMDkwv010895; Tue, 11 Mar 2003 23:13:46 +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.2655.55) id FD4KLGMP; Tue, 11 Mar 2003 23:13:46 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2BMDjK02887; Tue, 11 Mar 2003 23:13:45 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2BMDZYl009601; Tue, 11 Mar 2003 23:13:35 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2BMDZnk009600; Tue, 11 Mar 2003 23:13:35 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2BMDWYl009596 for ; Tue, 11 Mar 2003 23:13:33 +0100 (MET) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KTFJXVJ88Q9BWJYD@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Wed, 12 Mar 2003 09:11:46 +1100 Received: from kapow.its.monash.edu.au (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 360D42000C; Wed, 12 Mar 2003 09:11:46 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id A24EF2000B; Wed, 12 Mar 2003 09:11:44 +1100 (EST) Date: Wed, 12 Mar 2003 09:11:44 +1100 From: Greg Daley Subject: Re: Secruity on Solicits (was: Re: Comments on SEND protocol) To: James Kempf Cc: Jari Arkko , Pekka Savola , ietf-send@standards.ericsson.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <3E6E5F20.1050204@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <3E6AF513.2020108@kolumbus.fi> <01cb01c2e801$26bdf5f0$156015ac@T23KEMPF> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7BIT Hi James, I'm not sure that a new option is needed. James Kempf wrote: >>>4. Secure Neighbor Discovery Overview >>> >>> o IPsec AH is used to protect all advertisement messages relating to >>> Neighbor and Router discovery. Solicitation messages are not >>> protected, as they do not carry any information. >>> >>>==> The latter sentence _incorrect_, and seems to be a show-stopper of a >>>kind. >> >>Yes, and this is indeed the biggest problem in the protocol that I know >>of at the moment. I think we mention it already in Section 14, by the way, >>but we didn't have time to invent a solution. One approach would be to >>avoid the solitications with an effect in SEND, but this would increase >>the number of messages in typical situations, which would be unfortunate >>for e.g. fast movements. More seriously, DAD would not work between two >>nodes who are testing the same address at the same time. Also, we wouldn't >>like to change the ND protocol as such. >> >>So what's wrong with just protecting solicitations in the same manner >>as advertisements? The reason is tricky. Consider the DAD probes, where >>the solicitation message has the unspecified address as a source, and the >>solicited node multicast address as a destination. The tested address >>appears within the ND packet in the Target Address option. If our >>security solution is at the IPsec layer, how can we test that the >>tested address and the signature have been associated in the right >>way? (Whether that association is through a cert with an address or >>via CGA is not relevant, but IPsec needs to access the address which >>for now only appears inside the application layer.) >> > > > Even if an IPsec header were put on, what would be the IP address of the SA? DAD > packets are sent with the unspecified address, as you indicate. This is a > problem with the IPsec approach v.s. the ICMP option approach, but we committed > to the IPsec approach now so it would be difficult to change. > > Perhaps we could specify a "Secure Target Address" option that contained the > Target Address with a digital signature and the public key? This could be used > in the DAD case. I agree that it's not really possible to protect DAD NS's, although care should be taken by nodes defending their addresses with cryptography, that they are not depleted of resources by doing so. (when we cannot guarantee the' validity of DAD NS's). DAD NA's are likely to be sufficiently secured, especially when CGA is used. As you mention, the src address is unspecified for DAD. All NS packets which don't have a specified source address MUST contain a Source-Link-Layer-Address-Option(SLLAO). This option updates neighbor cache entries by default. If no security is required on solicitations with SLLAO, then existing 'secure' NC entries will be overwritten by unsecured messages. Requiring security on NS's which contain SLLAO avoids the issue of unspecified address. This could allow similar mechanisms to those used for NA to be undertaken, since a unicast source address is available for an SA, and similar updates are made to neighbor cache entries. > In the RS case, the packet is sent to the All Routers Multicast Address, but I > believe it can have the link local unicast address of the node. I could also > have the unspecified address, so the node could solicit a router before > performing DAD, but we could require a node to not use the unspecified address. > Or we could allow the "Secure Target Address" option in that case too, to allow > the unspecified address. > > Note that if CGA addresses aren't used, the node receiving an NS with a Secure > Target Address option doesn't have any assurance that the sending node has a > right to claim the address, unless an authenticatable certificate is also > included in the NS. Similar to the previous suggestion for NS's, RS's SHOULD contain SLLAO if they have a specified source address. It is possible to ensure that no insecure neighbor cache updates are performed solely by requiring security for RS's if SLLAO is present. 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 Wed Mar 12 01:22:33 2003 Received: from albatross.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 BAA27888 for ; Wed, 12 Mar 2003 01:22:33 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2C6IgB3014289; Wed, 12 Mar 2003 07:18:42 +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.2655.55) id GPH5WNDW; Wed, 12 Mar 2003 07:18:41 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2C6IeK16133; Wed, 12 Mar 2003 07:18:40 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2C6HcYl019110; Wed, 12 Mar 2003 07:17:38 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2C6Hcgi019109; Wed, 12 Mar 2003 07:17:38 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from master.marx.pl (master.marx.pl [195.205.47.146]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with SMTP id h2C6HaYl019105 for ; Wed, 12 Mar 2003 07:17:36 +0100 (MET) Received: from 195.205.47.149 by master.marx.pl (MarXpl SMTPD); id s20030312071607.5823; Wed, 12 Mar 2003 07:16:08 Message-ID: <41923-22003331261615343@mta.8796.0098.ga> To: "secured www servers" From: "" Subject: =?windows-1252?Q?=BB=BB=BB=BB_OFFSHORE_HOSTING_=AB=AB=AB=AB?= Date: Wed, 12 Mar 2003 01:16:15 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h2C6HbYl019106 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit *SECURED OFFSHORE HOSTING SERVERS* [Host your website offshore, securely, and privately!] WE WILL NOT SHUT YOU DOWN DUE TO COMPLAINTS! http://www.matrixmailserver.net -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Mar 12 02:47:40 2003 Received: from albatross.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 CAA25493 for ; Wed, 12 Mar 2003 02:47:39 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2C7lBB3006040; Wed, 12 Mar 2003 08:47:11 +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.2655.55) id GPH5XAZJ; Wed, 12 Mar 2003 08:47:10 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2C7l4K18924; Wed, 12 Mar 2003 08:47:04 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2C7kEYl001120; Wed, 12 Mar 2003 08:46:14 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2C7kDq4001113; Wed, 12 Mar 2003 08:46:13 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2C7kCYl001109 for ; Wed, 12 Mar 2003 08:46:12 +0100 (MET) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 9CA151C; Wed, 12 Mar 2003 09:56:19 +0200 (EET) Message-ID: <3E6EE5CF.70807@nomadiclab.com> Date: Wed, 12 Mar 2003 09:46:23 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sommerfeld@east.sun.com Cc: SEND WG , Craig Metz Subject: Re: psreq issue #11: Usage of the term "trust" References: <200303111921.h2BJLDaj028322@thunk.east.sun.com> In-Reply-To: <200303111921.h2BJLDaj028322@thunk.east.sun.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 Bill Sommerfeld wrote: > For what it's worth, I've also suggested being more precise here. > > "Trust" is itself a rather vague word. > > I think it's better to use words like "authorization" and > "delegation", and specify precisely what is authorized and how > authorizations are delegated and.. Bill, Your suggestion would be great. However, I'm afraid I don't have cycles for that right now. Would you like to edit the draft to change the terminology? Anyone else? If not, I'll stick with the t-word in the next version of the draft, and we'll see what the IESG says. Now, what comes to the more technical documents, I really think that we should take care of not using the t-word there. --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 Mar 12 02:58:48 2003 Received: from penguin.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 CAA25686 for ; Wed, 12 Mar 2003 02:58:47 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2C7tMwv016434; Wed, 12 Mar 2003 08:55:22 +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.2655.55) id GPH5XDHG; Wed, 12 Mar 2003 08:55:22 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2C7tLK19246; Wed, 12 Mar 2003 08:55:21 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2C7slYl001703; Wed, 12 Mar 2003 08:54:47 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2C7slWh001702; Wed, 12 Mar 2003 08:54:47 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2C7skYl001698 for ; Wed, 12 Mar 2003 08:54:46 +0100 (MET) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 874421C; Wed, 12 Mar 2003 10:04:54 +0200 (EET) Message-ID: <3E6EE7D2.2090607@nomadiclab.com> Date: Wed, 12 Mar 2003 09:54:58 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Cc: Craig Metz Subject: Re: psreq issue #11: Usage of the term "trust" References: <3E6DC3BF.6030807@nomadiclab.com> <00e401c2e7f1$4b3a6d10$156015ac@T23KEMPF> In-Reply-To: <00e401c2e7f1$4b3a6d10$156015ac@T23KEMPF> 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 > Thus, as a document editor, I propose that we resolve this > issue simply by removing the words "and loose" from the paragraph > above. While this does not change the substance of the document > in any way, it seems to better reflect the true nature of the > usage of the term in the document. > > > > Do you think this proposed resolution is OK? Or are there > specific occurances of the words "trust", "trustworthy", or > "trusted", which should be qualified better? Based on the comments received, I resolved the issue by removing the words "and loose", as I suggested. However, I am not very happy with this resolution. My only defence is that this document is only a problem statement document, and we really want to move forward. Based on my earlier experience, people rarely really come back to the problem statement documents once they have been finished. They work more like a baseline of understanding on what to do. The exact problems to solve tend to fluctuate somewhat during the design process, as people start to understand better what the issue is all about. Thus, in order to save cycles for more important tasks, I won't change the terminology. However, if someone else is willing to do that, I am happy to send the source rfc2xml files for editing. --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 Mar 12 03:37:06 2003 Received: from albatross.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 DAA26199 for ; Wed, 12 Mar 2003 03:37:05 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2C8aDB3021966; Wed, 12 Mar 2003 09:36:13 +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.2655.55) id GZAKD0JC; Wed, 12 Mar 2003 09:36:13 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2C8aC218912; Wed, 12 Mar 2003 09:36:12 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2C8ZkYl007058; Wed, 12 Mar 2003 09:35:46 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2C8ZjcO007057; Wed, 12 Mar 2003 09:35:45 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2C8ZiYl007049 for ; Wed, 12 Mar 2003 09:35:44 +0100 (MET) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 4D4E11C; Wed, 12 Mar 2003 10:45:52 +0200 (EET) Message-ID: <3E6EF16C.2070007@nomadiclab.com> Date: Wed, 12 Mar 2003 10:35:56 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Cc: Craig Metz Subject: psreq issue #13: part I: The relationship of SEND and access control 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 I am in the process of resolving issue #13. Part of this issue seems to be the relationship between SEND and access control. To make the current situation clear, I am adding the following paragraph to the Introduction section: Note that the SEND WG charter limits the scope of the working group to secure Neighbor Discovery functions. Furthermore, the charter explicitly mentions zero configuration as a fundamental goal behind Neighbor discovery. Together, these starting points imply that any network level access control functionality falls beyond the scope of this work. Is that OK to everybody? (Please refrain from discussing the relationship between SEND and access control on this thread. That is an important issue, and it would be good to have a separate thread of discussion for it. This thread should only discuss things directly related to psreq issue #13. Thank you.) --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 Mar 12 04:24:29 2003 Received: from penguin.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 EAA27072 for ; Wed, 12 Mar 2003 04:24:29 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2C9Kdwv013208; Wed, 12 Mar 2003 10:20:39 +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.2655.55) id FDVN6BW4; Wed, 12 Mar 2003 10:20:38 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2C9Kc220580; Wed, 12 Mar 2003 10:20:38 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2C9JsYl012299; Wed, 12 Mar 2003 10:19:54 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2C9JsFe012298; Wed, 12 Mar 2003 10:19:54 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2C9JrYl012294 for ; Wed, 12 Mar 2003 10:19:53 +0100 (MET) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id D7E331C; Wed, 12 Mar 2003 11:30:00 +0200 (EET) Message-ID: <3E6EFBC4.4070805@nomadiclab.com> Date: Wed, 12 Mar 2003 11:20:04 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Cc: Craig Metz Subject: psreq issue #13: part II: Assessment criteria 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 I am in the process of resolving issue #13. The second part of the comment concerned the qualities of the potential solutions in the various trust models. Since I could not figure out how to exactly apply the comment to the current document structure, I ended up adding a new section, Assessment criteria. 5. Assessment criteria for solutions In this section we discuss a few criteria that may be used to assess the quality of solutions. This list is not meant to be exhaustive. Rather than that, it represents a collection of qualities people paid attention at during the drafting of this document. Zero configuration. The original Neighbor Discovery protocol was carefully designed to support zero configuration. The secure protocol should support zero configuration to the extend possible. Access control. It should be possible to use the solution both in scenarios where the devices need to gain access permission to access the network before running Neighbor Discovery, and in scenarios where the devices first gain access to a local network and run Neighbor Discovery, and are then later subject to access control for accessing some resources. Possession of keys. The solutions should be evaluated in respect to the which parties possess keys and other valuable information, and on the threats created if these parties disclose this information to unauthorized parties. For example, the solution should limit the damage caused if an authorized client discloses its private key to an attacker, either intentionally or as a consequence of a security breach. Scalability. The solutions should be evaluated in respect to the number of keys, security associations, and other items used. It is desirable that these numbers grow at most linearly with resepect to the number of nodes. Is this OK? Are there other important, general level criteria that should be added to this 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 Mar 12 04:45:56 2003 Received: from albatross.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 EAA27401 for ; Wed, 12 Mar 2003 04:45:55 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2C9fOB3016408; Wed, 12 Mar 2003 10:41:24 +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.2655.55) id GPHJWHB7; Wed, 12 Mar 2003 10:41:24 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2C9fNK24022; Wed, 12 Mar 2003 10:41:23 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2C9f4Yl014516; Wed, 12 Mar 2003 10:41:04 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2C9f4Mj014515; Wed, 12 Mar 2003 10:41:04 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2C9f3Yl014511 for ; Wed, 12 Mar 2003 10:41:03 +0100 (MET) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 87FB01C; Wed, 12 Mar 2003 11:51:11 +0200 (EET) Message-ID: <3E6F00BB.8010601@nomadiclab.com> Date: Wed, 12 Mar 2003 11:41:15 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Cc: Craig Metz Subject: Re: psreq issue#24: trust models References: <3E6C400A.8090409@nomadiclab.com> In-Reply-To: <3E6C400A.8090409@nomadiclab.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 Pekka Nikander wrote: > http://www.tml.hut.fi/~pnr/SEND/issues/issue24.txt > What is the feeling of the WG? Should we adopt > Craig's proposal, or stick with the current structure? Based on the replies I received I am keeping the current structure. --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 Mar 12 05:06:15 2003 Received: from albatross.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 FAA27800 for ; Wed, 12 Mar 2003 05:06:14 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2CA4XB3024892; Wed, 12 Mar 2003 11:04:33 +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.2655.55) id FDVN63WN; Wed, 12 Mar 2003 11:04:33 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2CA4WK24985; Wed, 12 Mar 2003 11:04:32 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2CA4EYl018075; Wed, 12 Mar 2003 11:04:14 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2CA4E21018074; Wed, 12 Mar 2003 11:04:14 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2CA4DYl018070 for ; Wed, 12 Mar 2003 11:04:13 +0100 (MET) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 0EB381C for ; Wed, 12 Mar 2003 12:14:21 +0200 (EET) Message-ID: <3E6F0629.10609@nomadiclab.com> Date: Wed, 12 Mar 2003 12:04:25 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: psreq issues now addressed + going forward 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 Folks, I have now tried to address the issues raised on the psreq draft during the WG LC to the best I could. The issues and their resolution can be found at http://www.tml.hut.fi/~pnr/SEND/issues.html A brief version is copied below. Four of the issues were rejected: 2, 9, 21, and 24. #2 was rejected since I didn't find anything specific in it that I could have edited into the document. #9 was rejected since it was decided to keep solutions talk in the draft (at least for now). #21 was rejected since it was clearly out of the scope #24 was rejected by working group consensus Two of the issues involved resolution that I an not particularly happy with: #1 and #11. I will take these explicitly up in the WG meeting. The rest were resolved by adding text to clarify the relevant section of the draft, or (in the case of #17) removing text that did not contribute much value and only created confusion. The new draft is available at the interim web page at http://www.tml.hut.fi/~pnr/SEND/ I will send the draft to the repositories immediately once draft updates are again accepted. We have 10 minute slot for covering these at San Francisco. I am planning to use 3 minutes to describe the process and the result, and the remaining 7 minutes for the issues about solutions (issue#1) and the t-word, "trust" (issue#11). However, it would be better if we could properly deal with them already on the list, and save a few minutes for the initial solution draft. Our intention is to deliver the draft to the IESG immediately after the San Francisco meeting. --Pekka Nikander # Status Description of the issue -------------------------------------------------------------------------- 1 Resolved Should the document talk about solutions at all? 2 Rejected Clarify the scope of the work 3 Added text Discuss the shortcomings of current key distribution 4 Adopted Clarify the issue about key distribution 5 Added text Clarify L2 issues in Section 3.2 6 Added text Clarify operator certification capability in 4.1.1 7 Added text Should the document talk about solutions in 4.2.1? 8 Added text Add reference to secure DHCP in Section 4.2.6 9 Rejected Remove mitigation approaches from 4.3.1 10 Added text Clarify the meaning of '+' in Section 4.4. 11 Resolved Use the term "trust" more carefully 12 Added text Clarify the corporate intranet vs. secure L2 reasoning 13 Added text Clarify the role of parties in each trust model 14 Added text Expand section 3.3 about ad hoc networks 15 Adopted Add flooding DoS as a separate threat category 16 Added text Clarify when you learn bindings from Solicitions 17 Del'd text Clarify the issue with subnet router anycast address 18 Adopted Recommend refusal of override bit? 19 Adopted Recommend that only /64 on-link prefixes are accepted 20 Adopted New subthreat: flooding host's routing table 21 Rejected Add a note about DDNS access controls 22 Adopted Add a note that small hop limits should not be accepted 23 Moved->#2 Clarify wording about what the scope of SEND work 24 Rejected Replace the current 3 trust scenarios 25 Added text Add descriptions for replay attacks 26 Added text 4.1.3 Do not limit the number of addresses in DAD? -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Mar 12 08:22:46 2003 Received: from albatross.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 IAA02865 for ; Wed, 12 Mar 2003 08:22:45 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2CDLrB3002389; Wed, 12 Mar 2003 14:21: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.2655.55) id GPH55J2B; Wed, 12 Mar 2003 14:21:53 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2CDLq229147; Wed, 12 Mar 2003 14:21:52 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2CDLFYl012118; Wed, 12 Mar 2003 14:21:15 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2CDLEsE012117; Wed, 12 Mar 2003 14:21:14 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2CDLDYl012113 for ; Wed, 12 Mar 2003 14:21:13 +0100 (MET) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h2CDLwCq008359; Wed, 12 Mar 2003 06:22:03 -0700 (MST) Received: [from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id GAA01605; Wed, 12 Mar 2003 06:21:02 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h2CDHhg22423; Wed, 12 Mar 2003 07:17:44 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 5054E2EC95; Wed, 12 Mar 2003 14:17:45 +0100 (CET) Message-ID: <3E6F3378.9070400@nal.motlabs.com> Date: Wed, 12 Mar 2003 14:17:44 +0100 From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Cc: Pekka Savola, Subject: Re: Send protocol and CGA References: <3E69B71C.6010501@kolumbus.fi> In-Reply-To: <3E69B71C.6010501@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 wrote: > However, at least Ericsson is in the process of preparing an IPR > and licensing statement relating to SEND. Hopefully other companies > will do the same. Hi Jari, since this came up here, I reply here, but it is more relevant to the IPR wg. My personal hope is that I would like to see other companies spend as much time selling the IETF ideas to their IPD as they spend in selling their company's ideas to IETF. Of course, that is an internal activity that I can't really see, but from what I see at the IETF public lists and in cooperative projects with other companies I could easily deduce a striking difference. Just two cents. -- Message Classification: GBU -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Mar 12 12:09:33 2003 Received: from albatross.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 MAA11583 for ; Wed, 12 Mar 2003 12:09:33 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2CH85B3006035; Wed, 12 Mar 2003 18:08:05 +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.2655.55) id FDVN0Q93; Wed, 12 Mar 2003 18:08:04 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2CH84213789; Wed, 12 Mar 2003 18:08:04 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2CH71Yl009722; Wed, 12 Mar 2003 18:07:01 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2CH71SH009721; Wed, 12 Mar 2003 18:07:01 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2CH6xYl009715 for ; Wed, 12 Mar 2003 18:07:00 +0100 (MET) Message-ID: <009101c2e8b9$919af2c0$286015ac@T23KEMPF> From: "James Kempf" To: "Pekka Nikander" , "SEND WG" Cc: "Craig Metz" References: <3E6EF16C.2070007@nomadiclab.com> Subject: Re: psreq issue #13: part I: The relationship of SEND and access control Date: Wed, 12 Mar 2003 09:05:21 -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 That is the intent. Access control is not in the charter. jak ----- Original Message ----- From: "Pekka Nikander" To: "SEND WG" Cc: "Craig Metz" Sent: Wednesday, March 12, 2003 12:35 AM Subject: psreq issue #13: part I: The relationship of SEND and access control > I am in the process of resolving issue #13. > > Part of this issue seems to be the relationship between SEND > and access control. To make the current situation clear, > I am adding the following paragraph to the Introduction section: > > Note that the SEND WG charter limits the scope of the working > group to secure Neighbor Discovery functions. Furthermore, the > charter explicitly mentions zero configuration as a fundamental > goal behind Neighbor discovery. Together, these starting points > imply that any network level access control functionality falls > beyond the scope of this work. > > Is that OK to everybody? > > (Please refrain from discussing the relationship between > SEND and access control on this thread. That is an > important issue, and it would be good to have a separate > thread of discussion for it. This thread should only > discuss things directly related to psreq issue #13. > Thank you.) > > --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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Mar 12 12:19:43 2003 Received: from penguin.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 MAA12005 for ; Wed, 12 Mar 2003 12:19:43 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2CHG4wv000280; Wed, 12 Mar 2003 18:16:04 +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.2655.55) id GPH57TJ6; Wed, 12 Mar 2003 18:16:03 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2CHG3213953; Wed, 12 Mar 2003 18:16:03 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2CHFvYl011053; Wed, 12 Mar 2003 18:15:57 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2CHFvLj011052; Wed, 12 Mar 2003 18:15:57 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2CHFtYl011044 for ; Wed, 12 Mar 2003 18:15:55 +0100 (MET) Message-ID: <009d01c2e8ba$d0ba8140$286015ac@T23KEMPF> From: "James Kempf" To: "Pekka Nikander" , "SEND WG" Cc: "Craig Metz" References: <3E6EFBC4.4070805@nomadiclab.com> Subject: Re: psreq issue #13: part II: Assessment criteria Date: Wed, 12 Mar 2003 09:14:16 -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 General comment: I had been thinking that the assessment of the solution would regress against the requirements, in the sense of how the protocol blocked the threats in the threats draft. I don't see a need for any detailed requirement list, the threats make that clear.What's below seem like high level goals, and I would phrase them as such (i.e. goals rather than assessment criteria). Also, I would formulate an overall goal of attempting to maintain fidelity with the base ND design goals in RFC 2461. It probably doesn't hurt to re-iterate those here, but it should be made clear that it is just a re-iteration. Editorial comments: > 5. Assessment criteria for solutions > > In this section we discuss a few criteria that may be used to assess > the quality of solutions. This list is not meant to be exhaustive. > Rather than that, it represents a collection of qualities people paid > attention at during the drafting of this document. > I think the final sentence is unnecessary. It is always the case that something may be left out. See general comments about how to beef up the introduction. > Zero configuration. The original Neighbor Discovery protocol was > carefully designed to support zero configuration. The secure > protocol should support zero configuration to the extend possible. ^^^^^ extent > > Access control. It should be possible to use the solution both in > scenarios where the devices need to gain access permission to > access the network before running Neighbor Discovery, and in > scenarios where the devices first gain access to a local network > and run Neighbor Discovery, and are then later subject to access > control for accessing some resources. > > Possession of keys. The solutions should be evaluated in respect to > the which parties possess keys and other valuable information, and > on the threats created if these parties disclose this information > to unauthorized parties. For example, the solution should limit > the damage caused if an authorized client discloses its private > key to an attacker, either intentionally or as a consequence of a > security breach. > Isn't it true that any security solution should exhibit this property? If so, is there a real need to restate it here? > Scalability. The solutions should be evaluated in respect to the > number of keys, security associations, and other items used. It > is desirable that these numbers grow at most linearly with > resepect to the number of nodes. > Again, I think this is a basic scalability goal and I question the need to restate it. The Seamoby WG became hung up and spent months discussing exactly how to quantify scalability. I'd rather not see that happen here. This design, as an extension of the base ND design, should have the same scalability properties, the security part as well. 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 Mar 12 14:32:45 2003 Received: from albatross.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 OAA17581 for ; Wed, 12 Mar 2003 14:32:44 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2CJV8B3027359; Wed, 12 Mar 2003 20:31: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.2655.55) id GPH58K5G; Wed, 12 Mar 2003 20:31:08 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2CJV6217209; Wed, 12 Mar 2003 20:31:06 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2CJUbYl027343; Wed, 12 Mar 2003 20:30:37 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2CJUb6a027342; Wed, 12 Mar 2003 20:30:37 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2CJUaYl027335 for ; Wed, 12 Mar 2003 20:30:36 +0100 (MET) Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 12D301C; Wed, 12 Mar 2003 21:40:33 +0200 (EET) Message-ID: <3E6F8ADD.90005@nomadiclab.com> Date: Wed, 12 Mar 2003 21:30:37 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Cc: SEND WG , Craig Metz Subject: Re: psreq issue #13: part II: Assessment criteria References: <3E6EFBC4.4070805@nomadiclab.com> <009d01c2e8ba$d0ba8140$286015ac@T23KEMPF> In-Reply-To: <009d01c2e8ba$d0ba8140$286015ac@T23KEMPF> 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 James Kempf wrote: > General comment: > > I had been thinking that the assessment of the solution would regress against > the requirements, in the sense of how the protocol blocked the threats in the > threats draft. I don't see a need for any detailed requirement list, the threats > make that clear.What's below seem like high level goals, and I would phrase them > as such (i.e. goals rather than assessment criteria). Also, I would formulate an > overall goal of attempting to maintain fidelity with the base ND design goals in > RFC 2461. It probably doesn't hurt to re-iterate those here, but it should be > made clear that it is just a re-iteration. I have no problem leaving the new section completely out. I just tried to incorporate Craig's comment, filed as issue#13. I'll do whatever the WG feels is the right thing. --Pekka -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Mar 12 15:48:03 2003 Received: from penguin.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 PAA21571 for ; Wed, 12 Mar 2003 15:48:02 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2CKlWwv027108; Wed, 12 Mar 2003 21:47:32 +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.2655.55) id GZAKJGLS; Wed, 12 Mar 2003 21:47:31 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2CKlVK26610; Wed, 12 Mar 2003 21:47:31 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2CKl5Yl006211; Wed, 12 Mar 2003 21:47:05 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2CKl5oJ006210; Wed, 12 Mar 2003 21:47:05 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2CKl3Yl006202 for ; Wed, 12 Mar 2003 21:47:04 +0100 (MET) Message-ID: <01d101c2e8d8$4f5ed470$286015ac@T23KEMPF> From: "James Kempf" To: "Pekka Nikander" Cc: "SEND WG" , "Craig Metz" References: <3E6EFBC4.4070805@nomadiclab.com> <009d01c2e8ba$d0ba8140$286015ac@T23KEMPF> <3E6F8ADD.90005@nomadiclab.com> Subject: Re: psreq issue #13: part II: Assessment criteria Date: Wed, 12 Mar 2003 12:45:26 -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 IMHO, I think a single paragraph with a statement of basic goals would be sufficient. jak ----- Original Message ----- From: "Pekka Nikander" To: "James Kempf" Cc: "SEND WG" ; "Craig Metz" Sent: Wednesday, March 12, 2003 11:30 AM Subject: Re: psreq issue #13: part II: Assessment criteria > James Kempf wrote: > > General comment: > > > > I had been thinking that the assessment of the solution would regress against > > the requirements, in the sense of how the protocol blocked the threats in the > > threats draft. I don't see a need for any detailed requirement list, the threats > > make that clear.What's below seem like high level goals, and I would phrase them > > as such (i.e. goals rather than assessment criteria). Also, I would formulate an > > overall goal of attempting to maintain fidelity with the base ND design goals in > > RFC 2461. It probably doesn't hurt to re-iterate those here, but it should be > > made clear that it is just a re-iteration. > > I have no problem leaving the new section completely out. > I just tried to incorporate Craig's comment, filed as issue#13. > > I'll do whatever the WG feels is the right thing. > > --Pekka > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Mar 12 22:57:55 2003 Received: from penguin.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 WAA06622 for ; Wed, 12 Mar 2003 22:57:54 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2D3v4wv014584; Thu, 13 Mar 2003 04:57:04 +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.2655.55) id FDV3CT65; Thu, 13 Mar 2003 04:57:03 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2D3uuK10054; Thu, 13 Mar 2003 04:56:56 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2D3uXYl006651; Thu, 13 Mar 2003 04:56:33 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2D3uXX3006643; Thu, 13 Mar 2003 04:56:33 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2D3uVYl006636 for ; Thu, 13 Mar 2003 04:56:32 +0100 (MET) Date: Wed, 12 Mar 2003 19:56:31 -0800 Subject: comments on send-ipsec-00 From: Alper Yegin To: SEND WG Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I just finished reading the draft. Here are some questions/comments: - This is a simple, and possibly a dumb question: In what type of networks are we concerned about unauthorized nodes sending bogus router advertisements? Possibly in public access networks, right? Couldn't we simply prevent client hosts from sending RAs by installing filters on the enforcement points (like APs in WLAN hotspots)? Any RA sent on the radio network can be dropped. Sure it is none of the business of the L2 bridge to do that from an architectural point of view, but from a practical point of view...... - "If (DAD) clashes are detected after three tries, the node is probably under attack, so it should shut down and report the situation to an administrator." Isn't DAD mechanism protected by CGAs as well? How can the attacker produce the right cryptographic information to claim 3 different IP addresses in a row? - Can the routers still send unsolicited advertisements that can be verified by hosts with different Trusted Roots? Or, do they have to unicast a different advertisement to each host? - "One effect of this is that secure hosts can not communicate with insecure hosts using link-local addresses, and vice versa." Can an insecure host and SEND-secured host still detect DAD collision on their link-local addresses? If not, then we end up duplicate link-local addresses on the same link, and this is a no good. - "An attacker may still be able to prevent valid responses or requests from reaching the intended recipient. As a result both participants are forced to believe that no address collision exists, when there in fact is." How can the attacker do that? Is it a MitM physically separating victims? Thanks in advance. alper -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Mar 12 23:29:27 2003 Received: from albatross.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 XAA07421 for ; Wed, 12 Mar 2003 23:29:27 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2D4SeB3027404; Thu, 13 Mar 2003 05:28:40 +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.2655.55) id GPH50Z7X; Thu, 13 Mar 2003 05:28:40 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2D4SZK10742; Thu, 13 Mar 2003 05:28:36 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2D4SFYl013332; Thu, 13 Mar 2003 05:28:15 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2D4SFLC013331; Thu, 13 Mar 2003 05:28:15 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2D4SDYl013327 for ; Thu, 13 Mar 2003 05:28:13 +0100 (MET) Date: Wed, 12 Mar 2003 20:28:08 -0800 Subject: Re: psreq issue #13: part I: The relationship of SEND and access control From: Alper Yegin To: Pekka Nikander , SEND WG CC: Craig Metz Message-ID: In-Reply-To: <3E6EF16C.2070007@nomadiclab.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pekka, > Note that the SEND WG charter limits the scope of the working > group to secure Neighbor Discovery functions. Furthermore, the > charter explicitly mentions zero configuration as a fundamental > goal behind Neighbor discovery. Together, these starting points > imply that any network level access control functionality falls > beyond the scope of this work. I don't know if these two points really imply your conclusion, but you can say "Network access authentication and access control are outside the scope of SEND protocol". alper -------------------------------------------------------------------- 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 Mar 13 04:17:20 2003 Received: from penguin.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 EAA24718 for ; Thu, 13 Mar 2003 04:17:19 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2D9GIwv014424; Thu, 13 Mar 2003 10:16:18 +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.2655.55) id GPH6B532; Thu, 13 Mar 2003 10:16:17 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2D9G6K18941; Thu, 13 Mar 2003 10:16:06 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2D9FRYl020750; Thu, 13 Mar 2003 10:15:27 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2D9FRTO020749; Thu, 13 Mar 2003 10:15:27 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from albatross.wise.edt.ericsson.se ([193.180.251.49]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2D9FQYl020721 for ; Thu, 13 Mar 2003 10:15:26 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2D9ChB3026071; Thu, 13 Mar 2003 10:12:43 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 13 Mar 2003 10:12:43 +0100 Message-ID: From: "Jari Arkko (LMF)" To: "'Pekka Nikander'" , SEND WG Subject: RE: psreq issue #13: part II: Assessment criteria Date: Thu, 13 Mar 2003 10:12:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk > Is this OK? Are there other important, general level criteria > that should be added to this list? How about efficiency in some form? I care a lot about not introducing a large number of additional messages, for instance. I guess scalability covers this partially (e.g. prevents us to use a new RS-RA pair for every new host) but it may not be completely sufficient. 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 Thu Mar 13 04:20:52 2003 Received: from penguin.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 EAA24792 for ; Thu, 13 Mar 2003 04:20:52 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2D9KWwv015846; Thu, 13 Mar 2003 10:20:32 +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.2655.55) id GZAKMNTW; Thu, 13 Mar 2003 10:20:31 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2D9KU209225; Thu, 13 Mar 2003 10:20:30 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2D9KLYl021161; Thu, 13 Mar 2003 10:20:21 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2D9KLsB021160; Thu, 13 Mar 2003 10:20:21 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2D9KKYl021156 for ; Thu, 13 Mar 2003 10:20:20 +0100 (MET) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 15FE91C; Thu, 13 Mar 2003 11:30:28 +0200 (EET) Message-ID: <3E704D62.2090005@nomadiclab.com> Date: Thu, 13 Mar 2003 11:20:34 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Cc: SEND WG , Craig Metz Subject: Re: psreq issue #13: part I: The relationship of SEND and access control References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Alper Yegin wrote: > Hi Pekka, > > >> Note that the SEND WG charter limits the scope of the working >> group to secure Neighbor Discovery functions. Furthermore, the >> charter explicitly mentions zero configuration as a fundamental >> goal behind Neighbor discovery. Together, these starting points >> imply that any network level access control functionality falls >> beyond the scope of this work. > > > I don't know if these two points really imply your conclusion, but > you can say "Network access authentication and access control are outside > the scope of SEND protocol". I changed the paragraph to read as follows: Note that the SEND WG charter limits the scope of the working group to secure Neighbor Discovery functions. Furthermore, the charter explicitly mentions zero configuration as a fundamental goal behind Neighbor discovery. Network access authentication and access control are outside the scope of this work. Ok to everybody? --Pekka -------------------------------------------------------------------- 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 Mar 13 04:46:48 2003 Received: from albatross.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 EAA25433 for ; Thu, 13 Mar 2003 04:46:48 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2D9krB3008296; Thu, 13 Mar 2003 10:46:53 +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.2655.55) id GPHJ89WZ; Thu, 13 Mar 2003 10:46:52 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2D9kpK20975; Thu, 13 Mar 2003 10:46:51 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2D9kWYl024449; Thu, 13 Mar 2003 10:46:32 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2D9kW4I024448; Thu, 13 Mar 2003 10:46:32 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2D9kVYl024443 for ; Thu, 13 Mar 2003 10:46:31 +0100 (MET) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id CC4421C; Thu, 13 Mar 2003 11:56:38 +0200 (EET) Message-ID: <3E705384.8090803@nomadiclab.com> Date: Thu, 13 Mar 2003 11:46:44 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Cc: SEND WG , Craig Metz Subject: Re: psreq issue #13: part II: Assessment criteria References: <3E6EFBC4.4070805@nomadiclab.com> <009d01c2e8ba$d0ba8140$286015ac@T23KEMPF> <3E6F8ADD.90005@nomadiclab.com> <01d101c2e8d8$4f5ed470$286015ac@T23KEMPF> In-Reply-To: <01d101c2e8d8$4f5ed470$286015ac@T23KEMPF> 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 James Kempf wrote: > IMHO, I think a single paragraph with a statement of basic goals would be > sufficient. I removed the new section, and replaced it with a single paragraph in the introduction. The new introduction reads as below. Everybody happy? --Pekka 1. Introduction The IPv6 Neighbor Discovery RFC2461 [3] and Address Autoconfiguration RFC2462 [4] mechanisms are used by nodes in an IPv6 network to learn the local topology, including the IP to MAC address mappings for the local nodes, the IP and MAC addresses of the routers present in the local network, and the routing prefixes served by the local routers. The current specifications suggest that IPsec AH RFC2402 [2] may be used to secure the mechanisms, but does not specify how. It appears that using current AH mechanisms is problematic due to key management problems [11]. To solve the problem, the Secure Neighbor Discovery (SEND) working group was chartered in fall 2002. The goal of the working group is to define protocol support for securing IPv6 Neighbor Discovery without requiring excessive manual keying. The purpose of this document is to define the types of networks in which the Secure IPv6 Neighbor Discovery mechanisms are expected to work, and the threats that the security protocol(s) must address. To fulfill this purpose, this document first defines three different trust models, roughly corresponding to secured corporate intranets, public wireless access networks, and pure ad hoc networks. After that, a number of threats are discussed in the light of these trust models. The threat catalog is aimed to be exhaustive, but it is likely that some threats are still missing. Thus, ideas for new threats to consider are solicited. 1.1 Remarks Note that the SEND WG charter limits the scope of the working group to secure Neighbor Discovery functions. Furthermore, the charter explicitly mentions zero configuration as a fundamental goal behind Neighbor discovery. Network access authentication and access control are outside the scope of this work. During the discussions while preparing this document, the following aspects that may help to evaluate the eventual solutions were mentioned. Zero configuration Interaction with access control solutions Scalability Efficiency However, The main evaluation criteria is formed by the trust models and threat lists. [[This document occasionally discusses solution proposals, such as CGA [10] and ABK [9]. However, the discussion is solely for illustrative purposes. It is meant to give the readers a more concrete idea of some possible solutions. It does NOT indicate any preference on solutions on the behalf of the authors or the working group. In this version of this draft, all "solution talk" is enclosed in double brackets, just like this paragraph.]] It should be noted that the term "trust" is used here in a rather non-technical manner. The most appropriate interpretation is to consider it as an expression of an organizational or collective belief, i.e., an expression of commonly shared beliefs about the future behavior of the other involved parties. Conversely, the term "trust relationship" denotes a mutual a priori relationship between the involved organizations or parties where the parties believe that the other parties will behave correctly even in the future. A trust relationship makes it possible to configure authentication and authorization information between the parties, while the lack of such a relationship makes it impossible to pre-configure such information. -------------------------------------------------------------------- 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 Mar 13 12:15:59 2003 Received: from penguin.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 MAA09290 for ; Thu, 13 Mar 2003 12:15:58 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2DHAqwv018245; Thu, 13 Mar 2003 18:10:52 +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.2655.55) id GPHKBVJS; Thu, 13 Mar 2003 18:10:52 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2DHAp224540; Thu, 13 Mar 2003 18:10:51 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2DHAUYl019898; Thu, 13 Mar 2003 18:10:30 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2DHAUW8019897; Thu, 13 Mar 2003 18:10:30 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2DHASYl019890 for ; Thu, 13 Mar 2003 18:10:29 +0100 (MET) Message-ID: <00ea01c2e983$38622960$286015ac@T23KEMPF> From: "James Kempf" To: "Pekka Nikander" Cc: "SEND WG" , "Craig Metz" References: <3E6EFBC4.4070805@nomadiclab.com> <009d01c2e8ba$d0ba8140$286015ac@T23KEMPF> <3E6F8ADD.90005@nomadiclab.com> <01d101c2e8d8$4f5ed470$286015ac@T23KEMPF> <3E705384.8090803@nomadiclab.com> Subject: Re: psreq issue #13: part II: Assessment criteria Date: Thu, 13 Mar 2003 09:08:51 -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 looks good. jak ----- Original Message ----- From: "Pekka Nikander" To: "James Kempf" Cc: "SEND WG" ; "Craig Metz" Sent: Thursday, March 13, 2003 1:46 AM Subject: Re: psreq issue #13: part II: Assessment criteria > James Kempf wrote: > > IMHO, I think a single paragraph with a statement of basic goals would be > > sufficient. > > I removed the new section, and replaced it with a single paragraph > in the introduction. The new introduction reads as below. > > Everybody happy? > > --Pekka > > > 1. Introduction > > The IPv6 Neighbor Discovery RFC2461 [3] and Address Autoconfiguration > RFC2462 [4] mechanisms are used by nodes in an IPv6 network to learn > the local topology, including the IP to MAC address mappings for the > local nodes, the IP and MAC addresses of the routers present in the > local network, and the routing prefixes served by the local routers. > The current specifications suggest that IPsec AH RFC2402 [2] may be > used to secure the mechanisms, but does not specify how. It appears > that using current AH mechanisms is problematic due to key management > problems [11]. > > To solve the problem, the Secure Neighbor Discovery (SEND) working > group was chartered in fall 2002. The goal of the working group is > to define protocol support for securing IPv6 Neighbor Discovery > without requiring excessive manual keying. > > The purpose of this document is to define the types of networks in > which the Secure IPv6 Neighbor Discovery mechanisms are expected to > work, and the threats that the security protocol(s) must address. To > fulfill this purpose, this document first defines three different > trust models, roughly corresponding to secured corporate intranets, > public wireless access networks, and pure ad hoc networks. After > that, a number of threats are discussed in the light of these trust > models. The threat catalog is aimed to be exhaustive, but it is > likely that some threats are still missing. Thus, ideas for new > threats to consider are solicited. > > 1.1 Remarks > > Note that the SEND WG charter limits the scope of the working group > to secure Neighbor Discovery functions. Furthermore, the charter > explicitly mentions zero configuration as a fundamental goal behind > Neighbor discovery. Network access authentication and access control > are outside the scope of this work. > > During the discussions while preparing this document, the following > aspects that may help to evaluate the eventual solutions were > mentioned. > > Zero configuration > > Interaction with access control solutions > > Scalability > > Efficiency > > However, The main evaluation criteria is formed by the trust models > and threat lists. > > [[This document occasionally discusses solution proposals, such as > CGA [10] and ABK [9]. However, the discussion is solely for > illustrative purposes. It is meant to give the readers a more > concrete idea of some possible solutions. It does NOT indicate any > preference on solutions on the behalf of the authors or the working > group. In this version of this draft, all "solution talk" is > enclosed in double brackets, just like this paragraph.]] > > It should be noted that the term "trust" is used here in a rather > non-technical manner. The most appropriate interpretation is to > consider it as an expression of an organizational or collective > belief, i.e., an expression of commonly shared beliefs about the > future behavior of the other involved parties. Conversely, the term > "trust relationship" denotes a mutual a priori relationship between > the involved organizations or parties where the parties believe that > the other parties will behave correctly even in the future. A trust > relationship makes it possible to configure authentication and > authorization information between the parties, while the lack of such > a relationship makes it impossible to pre-configure such information. > > > > -------------------------------------------------------------------- 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 Mar 13 13:11:08 2003 Received: from penguin.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 MAA09289 for ; Thu, 13 Mar 2003 12:15:58 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2DHAuwv018259; Thu, 13 Mar 2003 18:10:56 +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.2655.55) id GPHKBVJ6; Thu, 13 Mar 2003 18:10:56 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2DHAsK08190; Thu, 13 Mar 2003 18:10:55 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2DHAJYl019883; Thu, 13 Mar 2003 18:10:19 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2DHAJF2019882; Thu, 13 Mar 2003 18:10:19 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2DHAHYl019877 for ; Thu, 13 Mar 2003 18:10:18 +0100 (MET) Message-ID: <00e001c2e983$2d7d7720$286015ac@T23KEMPF> From: "James Kempf" To: "Pekka Nikander" , "Alper Yegin" Cc: "SEND WG" , "Craig Metz" References: <3E704D62.2090005@nomadiclab.com> Subject: Re: psreq issue #13: part I: The relationship of SEND and access control Date: Thu, 13 Mar 2003 09:08:31 -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 let's print it... jak ----- Original Message ----- From: "Pekka Nikander" To: "Alper Yegin" Cc: "SEND WG" ; "Craig Metz" Sent: Thursday, March 13, 2003 1:20 AM Subject: Re: psreq issue #13: part I: The relationship of SEND and access control > Alper Yegin wrote: > > Hi Pekka, > > > > > >> Note that the SEND WG charter limits the scope of the working > >> group to secure Neighbor Discovery functions. Furthermore, the > >> charter explicitly mentions zero configuration as a fundamental > >> goal behind Neighbor discovery. Together, these starting points > >> imply that any network level access control functionality falls > >> beyond the scope of this work. > > > > > > I don't know if these two points really imply your conclusion, but > > you can say "Network access authentication and access control are outside > > the scope of SEND protocol". > > I changed the paragraph to read as follows: > > Note that the SEND WG charter limits the scope of the working > group to secure Neighbor Discovery functions. Furthermore, the > charter explicitly mentions zero configuration as a fundamental > goal behind Neighbor discovery. Network access authentication > and access control are outside the scope of this work. > > Ok to everybody? > > --Pekka > > > -------------------------------------------------------------------- > 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 Mar 14 00:35:04 2003 Received: from albatross.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 AAA03990 for ; Fri, 14 Mar 2003 00:35:04 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2E5XQB3008641; Fri, 14 Mar 2003 06:33:26 +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.2655.55) id GPHK1PW3; Fri, 14 Mar 2003 06:33:26 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2E5XOK27650; Fri, 14 Mar 2003 06:33:24 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2E5WdYl001828; Fri, 14 Mar 2003 06:32:39 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2E5WdII001827; Fri, 14 Mar 2003 06:32:39 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from outgoing3.themail.com ([216.204.151.37]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2E5WbYl001823; Fri, 14 Mar 2003 06:32:37 +0100 (MET) Date: Fri, 14 Mar 2003 06:32:37 +0100 (MET) From: barr_ibechris@themail.com Message-Id: <200303140532.h2E5WbYl001823@sw.ericsson.se> Received: from mail.TheMail.com [216.204.151.240] by outgoing3.themail.com (SMTPD32-6.06) id A86C5747024E; Fri, 14 Mar 2003 00:28:12 -0500 Received-From: mail.TheMail.com To: barr_ibechris@themail.com Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk g,Marc.Blanchet@viagenie.qc.ca,idn@ops.ietf.org,idn-request@ops.ietf.org,ogud@ogud.com,namedroppers@ops.ietf.org,namedroppers-request@ops.ietf.org,dnssec@cafax.se,dnssec-request@cafax.se,keydist@cafax.se,keydist-request@cafax.se,tbrunner@omneon.com,ifmib@ietf.org,rdroms@cisco.com,dhcwg@ietf.org,Richard_Woundy@cable.comcast.com,jf.mule@cablelabs.com,ipcdn@ietf.org,fkastenholz@juniper.net,a.herrera@rogers.com,iporpr@ietf.org,iporpr-request@ietf.org,jerry.chu@sun.com,bill@strahm.net,ipoverib@ietf.org,ipoverib -rFrom: barr_ibechris@themail.com Subject: best regards. X-Priority: 3 Authorized-User: barr_ibechris@themail.com IP-Address: 212.100.72.142 Reply-To: barr_ibechris@post.com MIME-Version: 1.0 Content-type: text/plain Message-Id: <200303140028109.SM00275@mail.TheMail.com> Date: Fri, 14 Mar 2003 00:38:25 -0500 Attn: Sir, I am Barrister Christian Ibe, a solicitor at law. I am the personal attorney to Mr. Mark Hedstrom, who used to work with Shell-pentrolum Development Company in Nigeria. Here after shall be referred to as my client. On the 21st of April 2000, my client, his wife and their Three children were involved in a car accident along sagumu Express road. All occupants of the vehicle unfortunately Lost their lives. Since then I have made several enquires To their embassy to locate any of my clients extended Relatives. This has also proved unsuccessful. Hence I Contacted you. I have contacted you to assist in repatriating the money and Property left behind by my client before they get Confiscated or declared unserviceable by the company where this Huge deposits were lodge. Particularly, the Standard united bank Africa which the finance company Where the deceased had an account valued at about $17,210,000.00 (seventeen million, two hundred and ten thousand united states dollars). The Standard United bank for Africa has issued me a notice to provide the next of kin of The deceased or have the account confiscated within a shot Period of time. Since I have been unsuccessful in locating the relatives for Over two years now I seek your consent to present you as the Next of kin of the deceased, so that the proceeds of this Account valued at $17,210,000.00 (seventeen million, two hundred and ten thousand united states dollars) can be paid to you, and then both of us can share the money 60% to me and 40% to You. I have all necessary legal documents that can be used To backup any claim we may make. All I require is your Honest cooperation to enable this deal through. I guarantee that this will be executed under a legitimate Arrangement that will protect you from any breach of the Law. Please get in touch with my email and send to me your Telephone and fax numbers to enable us further about this Transaction. Best regards, Barr. Christian Ibe. __________________________________________________________________ TheMail.com - Full featured premium email you can count on. Sign-up today at http://www.themail.com/ -------------------------------------------------------------------- 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 Mar 18 11:14:01 2003 Received: from albatross.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 LAA15464 for ; Tue, 18 Mar 2003 11:14:00 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2IGBMB3006607; Tue, 18 Mar 2003 17:11:22 +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.2655.55) id GZALSPNZ; Tue, 18 Mar 2003 17:11:22 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2IGBJK01505; Tue, 18 Mar 2003 17:11:19 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2IGAfYl027703; Tue, 18 Mar 2003 17:10:41 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2IGAfAx027702; Tue, 18 Mar 2003 17:10:41 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from abc193359.com ([193.194.160.192]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with SMTP id h2IGAQYl027689 for ; Tue, 18 Mar 2003 17:10:30 +0100 (MET) Message-Id: <200303181610.h2IGAQYl027689@sw.ericsson.se> From: "Dr.Moses" Reply-To: drmoses_e@englishexpert.com To: ietf-send@standards.ericsson.net Date: Tue, 18 Mar 2003 16:10:59 +0000 Subject: URGENT BUSINESS ASSISTANCE X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h2IGAeYl027699 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by fnatte.sw.ericsson.se id h2IGBJK01505 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA15464 5 RIDER HAGGARD CLOSE, JO, BORG SOUTH AFRICA. (HIGHLY CONFIDENTIAL) Ref: TRANSFER OF ($ 152,000.000.00 USD ONE HUNDRED AND FIFTY TWO MILLION DOLLARS) Dear Sir, We want to transfer to overseas ($ 152,000.000.00 USD)One hundred and Fifty two million United State Dollars) from a Prime Bank in Africa, I want to ask you to quietly look for a reliable and honest person who will be capable and fit to provide either an existing bank account or to set up a new Bank a/c immediately to receive this money, even an empty a/c can serve to receive this money, as long as you will remain honest to me till the end for this important business trusting in you and believing in God that you will never let me down either now or in future. I am DR. MOSES O. EKWONWA.the Auditor General of prime Banks, during the course of our auditing I Discovered a floating fund in an account opened In the bank in 1990 and since 1993 nobody has Operated on this account again, after going through some old files in the records I discovered that the owner of the account died without a [heir] hence the money is floating and if I do not remit this money out urgently it will be forfeited for nothing. the owner of this account is Mr. Allan P.Seaman, a foreigner, and an industrialist, and he died since 1993. And no other person knows about this account or any thing concerning it, the account has no other Beneficiary and my investigation proved to me as well that Allan P. Seaman until his death was the manager Diamond Safari [pty]. SA. We will start the first transfer with fifty two million [$52,000.000] upon successful transaction without any disappoint from your side, we shall re-apply for the payment of the remaining rest amount to your account, The amount involved is (USD152M) One hundred and Fifty two million United States Dollars, only I want to first transfer $52,000.000 [fifty two million United States Dollar from this money into a safe foreigners account abroad before the rest, but I don't know any foreigner, I am only contacting you as a foreigner because this money can not be approved to a local person here, without valid international foreign passport, but can only be approved to any foreigner with valid international passport or drivers license and foreign a/c because the money is in us dollars and the former owner of the a/c Mr. Allan P. Seaman is a foreigner too, [and the money can only be approved into a foreign a/c. However, we will sign a binding agreement, to bind us together I got your ! contact address through Internet when I’m looking for person or company who will assist me, I am revealing this to you with believe in God that you will never let me Down in this business, you are the first and the only person that I am contacting for this business, so please reply urgently so that I will inform you the next step to take urgently. Send also your private telephone and fax number including the full details of the account to be used for the deposit. I want us to meet face to face to build confidence and to sign a binding agreement that will bind us together before transferring the money to any account of your choice where the fund will be safe. Before we fly to your country for withdrawal, sharing and investments. I need your full co-operation to make this work fine. because the management is ready to approve this payment to any foreigner who has correct information of this account, which I will give to you, upon your positive response and once I am convinced that you are capable and will meet up with instruction of a key bank official who is deeply involved with me in this business. I need your strong assurance that you will never, never let me down. With my influence and the position of the bank official we can transfer this money to any foreigner’s reliable account which you can provide with assurance that this money will be intact pending our physical arrival in your country for sharing.The bank official will destroy all documents of transaction immediately we receive this money leaving no trace to any place and to build confidence you can come immediately to discuss with me face to face after which I will make this remittance in your presence and three of us will fly to your country at least two days ahead of the money going into the account. I will apply for annual leave to get visa immediately I hear from you that you are ready to act and receive this fund in your account. I will use my position and influence to obtain all legal approvals for onward transfer of this money to your account with appropriate clearance from the relevant ministries and foreign exchange departments. At the conclusion of this business, you will be given 35% of the total amount, 60% will be for me, while 5% will be for expenses both parties might have incurred during the process of transferring. I look forward to your earliest reply . Yours truly, Dr.Moses -------------------------------------------------------------------- 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 Mar 18 13:33:00 2003 Received: from penguin.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 NAA22736 for ; Tue, 18 Mar 2003 13:32:59 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2IILPHQ022608; Tue, 18 Mar 2003 19:21:25 +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.2655.55) id FDVP3Z71; Tue, 18 Mar 2003 19:21:25 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2IILO223342; Tue, 18 Mar 2003 19:21:24 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2IIJjYl013468; Tue, 18 Mar 2003 19:19:45 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2IIJj1H013467; Tue, 18 Mar 2003 19:19:45 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2IIJiYl013463 for ; Tue, 18 Mar 2003 19:19:44 +0100 (MET) Received: from [193.229.5.108] by fep20-app.kolumbus.fi with ESMTP id <20030318181943.MQMJ8208.fep20-app.kolumbus.fi@[193.229.5.108]>; Tue, 18 Mar 2003 20:19:43 +0200 From: To: CC: Subject: Re: CGA draft and paper Date: Tue, 18 Mar 2003 20:19:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20030318181943.MQMJ8208.fep20-app.kolumbus.fi@[193.229.5.108]> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Tuomas Aura wrote: > http://www.ietf.org/internet-drafts/draft-aura-cga-00.txt I like this draft a lot. In particular, I like the two-step construction of the addresses in order to make care-of address construction efficient. A few minor comments: * Introduction: is there a reference to someone using CGAs for opportunistic IPsec? * Why MD5 and not SHA1? * Section 6, "(These DoS attacks can be prevented if the IPv6 ND messages are authenticated with CGA addresses.)" It might make sense to clarify that legitimate collisions can still occur. 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 Mar 18 13:47:45 2003 Received: from albatross.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 NAA23530 for ; Tue, 18 Mar 2003 13:47:44 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2IIaJbh004099; Tue, 18 Mar 2003 19:36:19 +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.2655.55) id GPH7NMT5; Tue, 18 Mar 2003 19:36:19 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2IIaI223621; Tue, 18 Mar 2003 19:36:18 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2IIYkYl015199; Tue, 18 Mar 2003 19:34:46 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2IIYk2p015198; Tue, 18 Mar 2003 19:34:46 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2IIYjYl015194 for ; Tue, 18 Mar 2003 19:34:45 +0100 (MET) Received: from [193.229.5.108] by fep20-app.kolumbus.fi with ESMTP id <20030318183445.MRYL8208.fep20-app.kolumbus.fi@[193.229.5.108]>; Tue, 18 Mar 2003 20:34:45 +0200 From: To: CC: Subject: Ericsson IPR statement Date: Tue, 18 Mar 2003 20:34:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20030318183445.MRYL8208.fep20-app.kolumbus.fi@[193.229.5.108]> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit FYI: The below IPR statement concerning draft-ietf-send-ipsec-00.txt has been sent to the IETF secretariat. Jari ---- License statement IETF- CGA PATENT LICENSE UNDERTAKING In the SEND Working Group in the Internet Engineering Task Force (IETF), the proposal "draft-ietf-send-ipsec-00.txt" (http://search.ietf.org/internet-drafts/draft-ietf-send-ipsec-00.txt) dated February 2003 has been made by Jari Arkko at Ericsson Research as well as co-authors from DoCoMo, Microsoft and SUN Microsystems. In the following, said submission and any future revision of said submission is referred to as "the CGA submission". Ericsson's general patent license statement (http://www.ietf.org/ietf/IPR/ERICSSON-General) also applies to the CGA submission. In addition, for the CGA submission, if said submission is included in the IETF SEND standard and Ericsson has patents that are essential to the implementation of such included submission in said standard, Ericsson shall not assert any such patent against any company or legal entity using said patents in the IETF SEND standard. The Ericsson non-assertion is conditional upon such company or legal entity not asserting any patents within the IETF SEND standard against Ericsson. For all other purposes Ericsson's general patent license statement as referred to above, shall apply. ---------------------------------------------------------------------- -------------------------------------------------------------- Malin Gullstrand, M. Sc. E. E. Licensing Manager IPR & Licensing; Ericsson AB Phone: +46 8 719 94 85 Mobile: +46 70 593 5921 -------------------------------------------------------------------- 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 Mar 18 14:37:27 2003 Received: from penguin.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 OAA26163 for ; Tue, 18 Mar 2003 14:37:26 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2IJaEHQ000622; Tue, 18 Mar 2003 20:36:14 +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.2655.55) id GPHLCDSG; Tue, 18 Mar 2003 20:36:10 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2IJa7K08278; Tue, 18 Mar 2003 20:36:07 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2IJZfYl022574; Tue, 18 Mar 2003 20:35:41 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2IJZf6i022573; Tue, 18 Mar 2003 20:35:41 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2IJZdYl022569 for ; Tue, 18 Mar 2003 20:35:40 +0100 (MET) Received: from mail6.microsoft.com ([157.54.6.196]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 18 Mar 2003 11:32:31 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 18 Mar 2003 11:32:26 -0800 Received: from 157.54.5.25 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 Mar 2003 11:32:28 -0800 Received: from RED-MSG-09.redmond.corp.microsoft.com ([157.54.12.7]) by INET-HUB-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Tue, 18 Mar 2003 11:32:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: CGA draft and paper Date: Tue, 18 Mar 2003 11:32:27 -0800 Message-ID: Thread-Topic: CGA draft and paper thread-index: AcLr560Rd7aBegFNRSSwv24tzIyr2wBnLh8w From: "Tuomas Aura" To: "SEND WG" , "Jari Arkko" X-OriginalArrivalTime: 18 Mar 2003 19:32:29.0555 (UTC) FILETIME=[1D2A7430:01C2ED85] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h2IJZeYl022570 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: 16 March 2003 06:27 > To: Tuomas Aura > Cc: SEND WG > > Tuomas Aura wrote: > > > http://www.ietf.org/internet-drafts/draft-aura-cga-00.txt > > I like this draft a lot. In particular, I like the two-step > construction of the addresses in order to make care-of address > construction efficient. > > A few minor comments: > > * Introduction: is there a reference to someone using CGAs for > opportunistic IPsec? No. I just think it is the right thing to do. I should probably remove references to uses beyond SEND and just say that there are several. > > * Why MD5 and not SHA1? Because an MD5 hash is 128 bits long --> easier to write the formula for bitwise AND and OR with an IPv6 address. Really, there is no other reason. My first goal has been to make the spec readable and unambiguous. > > * Section 6, "(These DoS attacks can be prevented if the IPv6 > ND messages are authenticated with CGA addresses.)" It might > make sense to clarify that legitimate collisions can still > occur. Ok. > > 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 Mar 18 14:41:25 2003 Received: from albatross.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 OAA26368 for ; Tue, 18 Mar 2003 14:41:25 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2IJeHbh011557; Tue, 18 Mar 2003 20:40:17 +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.2655.55) id GPHLC1D0; Tue, 18 Mar 2003 20:40:16 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2IJeF225203; Tue, 18 Mar 2003 20:40:15 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2IJe5Yl022810; Tue, 18 Mar 2003 20:40:05 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2IJe5id022809; Tue, 18 Mar 2003 20:40:05 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2IJe4Yl022805 for ; Tue, 18 Mar 2003 20:40:04 +0100 (MET) Received: from [193.229.5.109] by fep02-app.kolumbus.fi with ESMTP id <20030318194004.JRJS4145.fep02-app.kolumbus.fi@[193.229.5.109]>; Tue, 18 Mar 2003 21:40:04 +0200 From: To: , CC: Subject: Re: factoring the spec into digestible pieces Date: Tue, 18 Mar 2003 21:40:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20030318194004.JRJS4145.fep02-app.kolumbus.fi@[193.229.5.109]> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Tuomas Aura wrote: > I also think that the IPSec extensions should be factored out > into a separate spec. Like CGA, they may have other uses beyond SEND. > Let's keep this in small and digestible pieces, and make those pieces as universally usable as possible. One possible approach is to describe the basic protocol pieces in separate drafts, then have one main SEND draft to show how they are used together. For instance, * Delegation chain discovery protocol * IPsec asymmentric extension (refs: CGA addresses) * CGA addresses * Secure ND (refs: all of the above) The last one would be basically sections 4, 8-12 of the current spec. One problem with this approach is that I think Pekka S wanted to separate the CGA parts not just in terms of the technical pieces, but also in terms of security considerations etc. But perhaps this could be dealt with by clearly separating the security properties in the last document for the following four cases: (a) Only CGA addresses available (b) Only trusted root for routers available (c) Trusted root available for both hosts and routers (d) CGA and trusted root available 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 Mar 18 15:32:39 2003 Received: from albatross.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 PAA28936 for ; Tue, 18 Mar 2003 15:32:38 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2IKVWbh018718; Tue, 18 Mar 2003 21:31:32 +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.2655.55) id FDVPPP3Z; Tue, 18 Mar 2003 21:31:32 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2IKVV226374; Tue, 18 Mar 2003 21:31:31 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2IKVCYl029397; Tue, 18 Mar 2003 21:31:12 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2IKVCSJ029396; Tue, 18 Mar 2003 21:31:12 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2IKVBYl029392 for ; Tue, 18 Mar 2003 21:31:11 +0100 (MET) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2IKV8B13698; Tue, 18 Mar 2003 22:31:08 +0200 Date: Tue, 18 Mar 2003 22:31:08 +0200 (EET) From: Pekka Savola To: jari.arkko@kolumbus.fi cc: tuomaura@microsoft.com, Subject: Re: factoring the spec into digestible pieces In-Reply-To: <20030318194004.JRJS4145.fep02-app.kolumbus.fi@[193.229.5.109]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk On Tue, 18 Mar 2003 jari.arkko@kolumbus.fi wrote: > > I also think that the IPSec extensions should be factored out > > into a separate spec. Like CGA, they may have other uses beyond SEND. > > Let's keep this in small and digestible pieces, and make those pieces as universally usable as possible. > > One possible approach is to describe the basic protocol > pieces in separate drafts, then have one main SEND draft > to show how they are used together. For instance, > > * Delegation chain discovery protocol > * IPsec asymmentric extension (refs: CGA addresses) > * CGA addresses > * Secure ND (refs: all of the above) I'm having a bit difficulties visualizing what would go to each part. > The last one would be basically sections 4, 8-12 of the > current spec. One problem with this approach is that I > think Pekka S wanted to separate the CGA parts not just > in terms of the technical pieces, but also in terms of > security considerations etc. But perhaps this could be > dealt with by clearly separating the security properties > in the last document for the following four cases: > > (a) Only CGA addresses available > (b) Only trusted root for routers available > (c) Trusted root available for both hosts and routers > (d) CGA and trusted root available What I think could be preferable is to have a separation where the SEND core protocol does not discuss CGA at all and has only an informative reference to CGA mechanisms. So, I was in support of a "stronger" separation, pending the resolution of IPR issues. If docs were split when there are no IPR-specific CGA concerns, the separation would likely be different. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Mar 18 19:00:49 2003 Received: from albatross.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 TAA07231 for ; Tue, 18 Mar 2003 19:00:48 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2INxKbh011663; Wed, 19 Mar 2003 00:59:20 +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.2655.55) id GPHLD1KW; Wed, 19 Mar 2003 00:59:20 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2INxGK16113; Wed, 19 Mar 2003 00:59:16 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2INwhYl022693; Wed, 19 Mar 2003 00:58:43 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2INwgOx022692; Wed, 19 Mar 2003 00:58:42 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2INweYl022688 for ; Wed, 19 Mar 2003 00:58:41 +0100 (MET) Message-ID: <011001c2edaa$0fb33060$906015ac@T23KEMPF> From: "James Kempf" To: "Pekka Savola" , Cc: , References: Subject: Re: factoring the spec into digestible pieces Date: Tue, 18 Mar 2003 15:56: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 So it sounds to me like we should keep the document in one piece if we can get the IPR resolved. If not, we should split out CGAs and simply have a reference to them. As a practical matter, I think keeping as much as makes sense in a single spec is a better approach, since it will make advancing easier. The only other part I can think of that I see makes sense to split out is the RSA Transform. A reason for splitting might be that it could be useful for other purposes. But it might make slow the spec down. jak ----- Original Message ----- From: "Pekka Savola" To: Cc: ; Sent: Tuesday, March 18, 2003 12:31 PM Subject: Re: factoring the spec into digestible pieces > On Tue, 18 Mar 2003 jari.arkko@kolumbus.fi wrote: > > > I also think that the IPSec extensions should be factored out > > > into a separate spec. Like CGA, they may have other uses beyond SEND. > > > Let's keep this in small and digestible pieces, and make those pieces as universally usable as possible. > > > > One possible approach is to describe the basic protocol > > pieces in separate drafts, then have one main SEND draft > > to show how they are used together. For instance, > > > > * Delegation chain discovery protocol > > * IPsec asymmentric extension (refs: CGA addresses) > > * CGA addresses > > * Secure ND (refs: all of the above) > > I'm having a bit difficulties visualizing what would go to each part. > > > The last one would be basically sections 4, 8-12 of the > > current spec. One problem with this approach is that I > > think Pekka S wanted to separate the CGA parts not just > > in terms of the technical pieces, but also in terms of > > security considerations etc. But perhaps this could be > > dealt with by clearly separating the security properties > > in the last document for the following four cases: > > > > (a) Only CGA addresses available > > (b) Only trusted root for routers available > > (c) Trusted root available for both hosts and routers > > (d) CGA and trusted root available > > What I think could be preferable is to have a separation where the SEND > core protocol does not discuss CGA at all and has only an informative > reference to CGA mechanisms. > > So, I was in support of a "stronger" separation, pending the resolution of > IPR issues. > > If docs were split when there are no IPR-specific CGA concerns, the > separation would likely be different. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 Mar 18 19:17:00 2003 Received: from albatross.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 TAA07549 for ; Tue, 18 Mar 2003 19:17:00 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2J0G6bh013755; Wed, 19 Mar 2003 01:16:06 +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.2655.55) id FDVPQNT7; Wed, 19 Mar 2003 01:16:05 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2J0G4201454; Wed, 19 Mar 2003 01:16:04 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2J0FqYl028705; Wed, 19 Mar 2003 01:15:52 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2J0FqEH028704; Wed, 19 Mar 2003 01:15:52 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2J0FpYl028700 for ; Wed, 19 Mar 2003 01:15:51 +0100 (MET) Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA21150; Tue, 18 Mar 2003 17:15:47 -0700 (MST) Received: from sun.com (vpn-129-150-17-65.SFBay.Sun.COM [129.150.17.65]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h2J0FjP19417; Wed, 19 Mar 2003 01:15:45 +0100 (MET) Message-ID: <3E77B89A.5070000@sun.com> Date: Wed, 19 Mar 2003 01:23:54 +0100 From: gabriel montenegro Reply-To: gab@sun.com User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tuomas Aura CC: SEND WG , Jari Arkko Subject: Re: CGA draft and paper References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Tuomas Aura wrote: >>* Introduction: is there a reference to someone using CGAs for >> opportunistic IPsec? > > > No. I just think it is the right thing to do. I should probably > remove references to uses beyond SEND and just say that there > are several. Specifically for Opportunistic Encryption: Opportunistic Encryption for IPv6 * Inria Technical Report (October 2002) o http://www.inria.fr/rrrt/rr-4568.html and ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-laganier-ike-ipv6-cga-00.txt >>* Why MD5 and not SHA1? > > > Because an MD5 hash is 128 bits long --> easier to write the formula > for bitwise AND and OR with an IPv6 address. Really, there is no other > reason. My first goal has been to make the spec readable and > unambiguous. The question, which I can't really answer, is if the weaknesses in MD5 are more applicable here than they are, for example, in hmac-sha-1. -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 Tue Mar 18 19:32:48 2003 Received: from albatross.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 TAA08459 for ; Tue, 18 Mar 2003 19:32:47 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2J0Vsbh015375; Wed, 19 Mar 2003 01:31:54 +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.2655.55) id GPH7390N; Wed, 19 Mar 2003 01:31:54 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2J0Vr201873; Wed, 19 Mar 2003 01:31:53 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2J0VYYl000475; Wed, 19 Mar 2003 01:31:34 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2J0VYMT000474; Wed, 19 Mar 2003 01:31:34 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2J0VWYl000470 for ; Wed, 19 Mar 2003 01:31:33 +0100 (MET) Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11941 for ; Tue, 18 Mar 2003 16:31:31 -0800 (PST) Received: from sun.com (vpn-129-150-17-65.SFBay.Sun.COM [129.150.17.65]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h2J0VTP20703; Wed, 19 Mar 2003 01:31:29 +0100 (MET) Message-ID: <3E77BC4B.7020402@sun.com> Date: Wed, 19 Mar 2003 01:39:39 +0100 From: gabriel montenegro Reply-To: gab@sun.com User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: cryptographic layering enforcement for SeND? 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 I just mentioned this at the meeting. In our drafty draft you'll find a description of the CLE mechanism in which one can secure the binding between two given addresses by deriving both of them from the same hash output of the hash(PK). In the SeND case, these two would be the IP addr and the link-layer address. The advantage is that it is a way to increawse the security beyond the 62 bit limit without any additional work when creating the addresses. It may also have additional advantages in the transition scenario in which you may end up with the confusing scenario of one MAC address for both the "send" and "non-send" link. -gabriel ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-montenegro-send-cga-rr-01.txt -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Mar 19 02:46:18 2003 Received: from albatross.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 CAA15390 for ; Wed, 19 Mar 2003 02:46:16 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2J7hgbh010353; Wed, 19 Mar 2003 08:43:42 +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.2655.55) id GPH7RCNL; Wed, 19 Mar 2003 08:43:42 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2J7hdK29380; Wed, 19 Mar 2003 08:43:39 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2J7hCYl003739; Wed, 19 Mar 2003 08:43:12 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2J7hCP2003738; Wed, 19 Mar 2003 08:43:12 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2J7h9Yl003734 for ; Wed, 19 Mar 2003 08:43:10 +0100 (MET) Date: Tue, 18 Mar 2003 23:43:09 -0800 Subject: Re: factoring the spec into digestible pieces From: Alper Yegin To: James Kempf , Pekka Savola , CC: , Message-ID: In-Reply-To: <011001c2edaa$0fb33060$906015ac@T23KEMPF> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit I'm still not sure if this is a good idea. As I was saying at the meeting, there are two independent problems here. One is about proving address ownership, the other is about proving authority to send router advertisements. The solutions should be separable. So that deployments can replace any one of them, or choose to address one but not the other. For example, some deployments might be interested in using the address ownership part, and rely on some filtering to prevent unauthorized RAs. Unless we include a language in the spec that says "an implementation may support part A, or part B, or both to be compliant with this spec", how can we say something is compliant with tihs RFCxxxx. This is a bit strange. As for advancing in the IETF process, I think independent solutions that are separately drafted have better chances of advancing faster. I think the key is not to create dependency between them. my 0.02 cents. alper > So it sounds to me like we should keep the document in one piece if we can get > the IPR resolved. If not, we should split out CGAs and simply have a reference > to them. > > As a practical matter, I think keeping as much as makes sense in a single spec > is a better approach, since it will make advancing easier. The only other part > I > can think of that I see makes sense to split out is the RSA Transform. A > reason > for splitting might be that it could be useful for other purposes. But it > might > make slow the spec down. > > jak > > ----- Original Message ----- > From: "Pekka Savola" > To: > Cc: ; > Sent: Tuesday, March 18, 2003 12:31 PM > Subject: Re: factoring the spec into digestible pieces > > >> On Tue, 18 Mar 2003 jari.arkko@kolumbus.fi wrote: >>>> I also think that the IPSec extensions should be factored out >>>> into a separate spec. Like CGA, they may have other uses beyond SEND. >>>> Let's keep this in small and digestible pieces, and make those pieces as > universally usable as possible. >>> >>> One possible approach is to describe the basic protocol >>> pieces in separate drafts, then have one main SEND draft >>> to show how they are used together. For instance, >>> >>> * Delegation chain discovery protocol >>> * IPsec asymmentric extension (refs: CGA addresses) >>> * CGA addresses >>> * Secure ND (refs: all of the above) >> >> I'm having a bit difficulties visualizing what would go to each part. >> >>> The last one would be basically sections 4, 8-12 of the >>> current spec. One problem with this approach is that I >>> think Pekka S wanted to separate the CGA parts not just >>> in terms of the technical pieces, but also in terms of >>> security considerations etc. But perhaps this could be >>> dealt with by clearly separating the security properties >>> in the last document for the following four cases: >>> >>> (a) Only CGA addresses available >>> (b) Only trusted root for routers available >>> (c) Trusted root available for both hosts and routers >>> (d) CGA and trusted root available >> >> What I think could be preferable is to have a separation where the SEND >> core protocol does not discuss CGA at all and has only an informative >> reference to CGA mechanisms. >> >> So, I was in support of a "stronger" separation, pending the resolution of >> IPR issues. >> >> If docs were split when there are no IPR-specific CGA concerns, the >> separation would likely be different. >> >> -- >> Pekka Savola "You each name yourselves king, yet the >> Netcore Oy kingdom bleeds." >> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >> >> -------------------------------------------------------------------- >> To unsubscribe from this list, send email with "UNSUBSCRIBE" in the >> body to . >> Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html >> -------------------------------------------------------------------- >> > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Mar 19 07:47:27 2003 Received: from albatross.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 HAA19751 for ; Wed, 19 Mar 2003 07:47:26 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2JCjfbh009844; Wed, 19 Mar 2003 13:45:42 +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.2655.55) id FDVPVHPC; Wed, 19 Mar 2003 13:45:41 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2JCje228590; Wed, 19 Mar 2003 13:45:40 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2JCjBYl011351; Wed, 19 Mar 2003 13:45:11 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2JCjBuc011338; Wed, 19 Mar 2003 13:45:11 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from aol.com ([218.76.246.17]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with SMTP id h2JChnYl010936; Wed, 19 Mar 2003 13:44:01 +0100 (MET) Received: from [43.142.185.29] by rly-xr02.nikavo.net with smtp; Wed, 19 Mar 2003 22:52:25 +1000 Received: from unknown (HELO rly-xr02.nikavo.net) (78.251.215.47) by rly-yk05.pesdets.com with esmtp; 20 Mar 2003 08:45:19 -1100 Received: from unknown (HELO q4.quickslow.com) (48.211.31.111) by rly-xr02.nikavo.net with asmtp; Wed, 19 Mar 2003 21:38:13 -0100 Received: from unknown (HELO hd.ressort.net) (133.244.52.162) by sparc.zubilam.net with asmtp; Wed, 19 Mar 2003 20:31:07 +0700 Reply-To: "Jason Donovan" Message-ID: <001e01b04c6b$6365a6c2$0ea81ba4@ftpktl> From: "Jason Donovan" To: Peter.Jackson@standards.ericsson.net Subject: We should meet up soon!..... Date: Wed, 19 Mar 2003 21:47:49 +0600 MiME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00D7_44D13D5A.E0050C26" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Internet Mail Service (5.5.2650.21) Importance: Normal Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk ------=_NextPart_000_00D7_44D13D5A.E0050C26 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0iI0ZG RkZGRiIgdGV4dD0iI0ZGRkZGRiIgbGVmdG1hcmdpbj0iMCIgdG9wbWFyZ2lu PSIwIiBtYXJnaW53aWR0aD0iMCIgbWFyZ2luaGVpZ2h0PSIwIiBsaW5rPSIj RkYzMzMzIiB2bGluaz0iI0ZGRkZGRiIgYWxpbms9IiNGRkZGRkYiPg0KPGRp diBhbGlnbj0iY2VudGVyIj48Yj48YnI+DQogIDxmb250IGNvbG9yPSIjMDA2 NkZGIiBzaXplPSI0IiBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNl cmlmIj5UaGlzIHNpdGUgDQogIGlzPGJyPg0KICA8Zm9udCBjb2xvcj0iI0ZG MzMzMyI+QUJTT0xVVEVMWSBGUkVFITwvZm9udD48L2ZvbnQ+PC9iPjxicj4N CjwvZGl2Pg0KPHRhYmxlIHdpZHRoPSI2MzYiIGNlbGxzcGFjaW5nPSIwIiBj ZWxscGFkZGluZz0iMCIgaGVpZ2h0PSIyNjEiIGFsaWduPSJjZW50ZXIiIGJn Y29sb3I9IiM2Nzc4RUIiPg0KICA8dHI+DQogICAgPHRkIGFsaWduPSJjZW50 ZXIiIHZhbGlnbj0ibWlkZGxlIiBiZ2NvbG9yPSI0QkE0RjAiIGhlaWdodD0i MjY4Ij4gPGZvbnQgZmFjZT0iVGFob21hLCBWZXJkYW5hIiBzaXplPSI2Ij48 Yj5GUkVFIA0KICAgICAgU0VYPGZvbnQgZmFjZT0iVmVyZGFuYSwgQXJpYWws IEhlbHZldGljYSwgc2Fucy1zZXJpZiI+IDwvZm9udD48L2I+PC9mb250Pjxm b250IGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2Vy aWYiPjxmb250IHNpemU9IjYiPjxiPjxmb250IHNpemU9IjUiPk9OIA0KICAg ICAgVEhFIFdFQjwvZm9udD48L2I+PC9mb250PjwvZm9udD4gDQogICAgICA8 dGFibGUgd2lkdGg9IjYzNSIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5n PSIwIiBoZWlnaHQ9IjIyNyIgYWxpZ249ImNlbnRlciI+DQogICAgICAgIDx0 cj4gDQogICAgICAgICAgPHRkIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0ibWlk ZGxlIiBiZ2NvbG9yPSI4QkNGRjIiIGhlaWdodD0iMjM2Ij4NCiAgICAgICAg ICAgIDxwPjxmb250IGZhY2U9IlRhaG9tYSwgVmVyZGFuYSIgc2l6ZT0iNSI+ PGI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVmVyZGFuYSwgQXJpYWwsIEhlbHZl dGljYSwgc2Fucy1zZXJpZiIgY29sb3I9IiMwMDMzOTkiPkZyZWUgDQogICAg ICAgICAgICAgIFBpY3R1cmVzICogRnJlZSBNb3ZpZXMgKiBGcmVlIEdhbWVz ICogRnJlZSBDaGF0PGJyPg0KICAgICAgICAgICAgICA8YnI+DQogICAgICAg ICAgICAgIGFuZCBtb3N0IGltcG9ydGFudGx5Li4uPGJyPg0KICAgICAgICAg ICAgICA8YnI+DQogICAgICAgICAgICAgIDwvZm9udD48Zm9udCBmYWNlPSJW ZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBjb2xvcj0i IzAwMzM5OSI+RlJFRSANCiAgICAgICAgICAgICAgRU5UUlkhPGJyPg0KICAg ICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgIDwvZm9udD48L2I+PC9m b250Pjxmb250IGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNh bnMtc2VyaWYiIHNpemU9IjIiIGNvbG9yPSIjMDAzMzk5Ij48Yj5XZWJjYW1z LCANCiAgICAgICAgICAgICAgTGl2ZWNoYXQgYW5kIE1vdmllcyBhbGwgRlJF RSByaWdodCBub3cgZm9yIHlvdSE8L2I+PC9mb250PjwvcD4NCiAgICAgICAg ICAgIDwvdGQ+DQogICAgICAgIDwvdHI+DQogICAgICA8L3RhYmxlPg0KICAg ICAgDQogICAgPC90ZD4NCiAgPC90cj4NCjwvdGFibGU+DQo8ZGl2IGFsaWdu PSJjZW50ZXIiPjxicj4NCiAgPGI+PGZvbnQgY29sb3I9IiNGRjMzMzMiPjxh IGhyZWY9Imh0dHA6Ly9yZC55YWhvby5jb20vKmh0dHA6Ly93d3cuZnJlZWFk dWx0ZXVyb3BlLmNvbS9pbmRleC5waHA/SUQ9MiI+Q0xJQ0sgDQogIEhFUkUg VE8gSk9JTiBGT1IgRlJFRSBSSUdIVCBOT1c8L2E+PC9mb250PjwvYj48L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4= -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- ------=_NextPart_000_00D7_44D13D5A.E0050C26-- From jari.arkko@lmf.ericsson.se Wed Mar 19 09:40:56 2003 Received: from albatross.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 JAA21509 for ; Wed, 19 Mar 2003 09:40:55 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2JEdkbh015003; Wed, 19 Mar 2003 15:39:46 +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.2655.55) id HH7GF6MD; Wed, 19 Mar 2003 15:39:46 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2JEdiK05707; Wed, 19 Mar 2003 15:39:44 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2JEdDYl025512; Wed, 19 Mar 2003 15:39:13 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2JEdDX8025511; Wed, 19 Mar 2003 15:39:13 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2JEdCYl025507 for ; Wed, 19 Mar 2003 15:39:12 +0100 (MET) Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id DDAF61C; Wed, 19 Mar 2003 16:49:15 +0200 (EET) Message-ID: <3E78811C.9000904@nomadiclab.com> Date: Wed, 19 Mar 2003 06:39:24 -0800 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Cc: James Kempf , Pekka Savola , jari.arkko@kolumbus.fi, tuomaura@microsoft.com, ietf-send@standards.ericsson.net Subject: Re: factoring the spec into digestible pieces References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Alper, Alper Yegin wrote: > I'm still not sure if this is a good idea. > As I was saying at the meeting, there are two independent problems here. One > is about proving address ownership, the other is about proving authority to > send router advertisements. The solutions should be separable. So that > deployments can replace any one of them, or choose to address one but not > the other. For example, some deployments might be interested in using the > address ownership part, and rely on some filtering to prevent unauthorized > RAs. Unless we include a language in the spec that says "an implementation > may support part A, or part B, or both to be compliant with this spec", how > can we say something is compliant with tihs RFCxxxx. This is a bit strange. > > As for advancing in the IETF process, I think independent solutions that are > separately drafted have better chances of advancing faster. I think the key > is not to create dependency between them. My sensing of the floor yesterday was that nobody (except perhaps you) really did see any compelling reason to split the document for any other reason but the CGA IPR. In any case, there was no consensus how exactly do the split, if it going to be done. There were several proposals, and none of them got any larger support. We can always do the split later. I think that we will eventually need a split, but I am still hoping that it would be necessary only after we have published the first version as a PS. --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 Mar 19 12:10:45 2003 Received: from albatross.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 MAA26216 for ; Wed, 19 Mar 2003 12:10:44 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2JHAKbh019547; Wed, 19 Mar 2003 18:10:20 +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.2655.55) id HH6M80P9; Wed, 19 Mar 2003 18:10:20 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2JHAJK13700; Wed, 19 Mar 2003 18:10:19 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2JH9iYl014358; Wed, 19 Mar 2003 18:09:44 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2JH9iBU014357; Wed, 19 Mar 2003 18:09:44 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2JH9gYl014353 for ; Wed, 19 Mar 2003 18:09:43 +0100 (MET) Date: Wed, 19 Mar 2003 09:09:33 -0800 Subject: Re: factoring the spec into digestible pieces From: Alper Yegin To: Pekka Nikander CC: James Kempf , Pekka Savola , , , Message-ID: In-Reply-To: <3E78811C.9000904@nomadiclab.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pekka, > Alper, > > Alper Yegin wrote: >> I'm still not sure if this is a good idea. >> As I was saying at the meeting, there are two independent problems here. One >> is about proving address ownership, the other is about proving authority to >> send router advertisements. The solutions should be separable. So that >> deployments can replace any one of them, or choose to address one but not >> the other. For example, some deployments might be interested in using the >> address ownership part, and rely on some filtering to prevent unauthorized >> RAs. Unless we include a language in the spec that says "an implementation >> may support part A, or part B, or both to be compliant with this spec", how >> can we say something is compliant with tihs RFCxxxx. This is a bit strange. >> >> As for advancing in the IETF process, I think independent solutions that are >> separately drafted have better chances of advancing faster. I think the key >> is not to create dependency between them. > > My sensing of the floor yesterday was that nobody (except > perhaps you) Yes, I know :) But this really doesn't answer my points above. Maybe I should ask the question another way: why do they have to be in the same document? > really did see any compelling reason to split > the document for any other reason but the CGA IPR. In any > case, there was no consensus how exactly do the split, if > it going to be done. There were several proposals, and none > of them got any larger support. > > We can always do the split later. I think that we will eventually > need a split, but I am still hoping that it would be necessary > only after we have published the first version as a PS. I don't think we want to have both combined and split versions of the specs. This is both time costly and possible cause of problems for implementors and deployment. If you think it should be split eventually, I'd say it is better done at the beginning. my o.o2 cents. alper -------------------------------------------------------------------- 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 Mar 20 15:31:46 2003 Received: from penguin.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 PAA04807 for ; Thu, 20 Mar 2003 15:31:45 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2KKQhHQ008312; Thu, 20 Mar 2003 21:26:43 +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.2655.55) id HH5MLJG0; Thu, 20 Mar 2003 21:26:44 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2KKQh214098; Thu, 20 Mar 2003 21:26:43 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2KKQ5Yl017924; Thu, 20 Mar 2003 21:26:05 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2KKQ54g017923; Thu, 20 Mar 2003 21:26:05 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from dms3 (customer-148-233-4-115.uninet.net.mx [148.233.4.115] (may be forged)) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2KKQ1Yl017916 for ; Thu, 20 Mar 2003 21:26:03 +0100 (MET) Received: from mx1.mail.yahoo.com (200-158-44-227.dsl.telesp.net.br [200.158.44.227]) by dms3 (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with ESMTP id OAA17519; Thu, 20 Mar 2003 14:18:25 -0600 From: ba_ribbe@yahoo.com Message-ID: <0000078b3474$00000989$00005587@mx1.mail.yahoo.com> To: Subject: Getting Older6671 Date: Thu, 20 Mar 2003 15:24:40 -1700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Reply-To: ba_ribbe@yahoo.com Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Flexible business... Did you know that 2-4 hours a day working at a computer can provide the cash to pay for a Brand New Lincoln Navigator by Summer? What about a Mercedes? The really big Mercedes might take an extra month or two. Or a one month First Class Cruise around the world? Or a year of college for one of the kids? The catch: it's work. If work doesn't bother you, Get info about the hottest (and coolest) new business by sending a message to elaine.morriss@talk21.com and say "Provide data." -------------------------------------------------------------------- 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 Mar 20 19:08:27 2003 Received: from penguin.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 TAA15048 for ; Thu, 20 Mar 2003 19:08:26 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2L08GHQ000874; Fri, 21 Mar 2003 01:08:16 +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.2655.55) id HH5MMD8P; Fri, 21 Mar 2003 01:08:16 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2L08EK18026; Fri, 21 Mar 2003 01:08:14 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2L07eYl016581; Fri, 21 Mar 2003 01:07:40 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2L07dDW016578; Fri, 21 Mar 2003 01:07:39 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2L07bYl016570 for ; Fri, 21 Mar 2003 01:07:37 +0100 (MET) Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 6E6BD1C for ; Fri, 21 Mar 2003 02:17:38 +0200 (EET) Message-ID: <3E7A57D4.50001@nomadiclab.com> Date: Thu, 20 Mar 2003 16:07:48 -0800 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: Draft SEND WG meeting notes Content-Type: multipart/mixed; boundary="------------060706070403040704090601" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk This is a multi-part message in MIME format. --------------060706070403040704090601 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Please find attached notes from the Tuesday's WG meeting. If there is anything to be corrected, please send your corrections before Tuesday, March 25th. I will submit the notes to secretariat after that. --Pekka Nikander --------------060706070403040704090601 Content-Type: text/plain; name="notes.txt" Content-Disposition: inline; filename="notes.txt" Content-Transfer-Encoding: 7bit Securing Neighbor Discovery WG (send) Tuesday, March 18 at 1545-1645 =============================== CHAIRS: James Kempf Pekka Nikander AGENDA: 5 min. - Agenda discussion, chairs The agenda was accepted. The chairs later on changed it so that the second last item, interaction with PANA / DHCP, was moved after the last item, draft status and schedule. 10 min. - Last Call Issues as resolved for draft-ietf-send-psreq.txt, Pekka Nikander Pekka Nikander went over the issues raised during the WG last call. Most of the issues were minor. However, there were two larges issues, worth spending some face-to-face time. The fist issue centered around using the term "trust". Currently the draft uses the term trusts, trusted, trustworthy etc in multiple place. However, it would be better to replace the word with more specific words, e.g. "delegation", "authorized", etc. Pekka described how the word is used right now, but also told that he is not very happy with the current resolution of the issue. Bill Sommerfeld came up and promised to come up with alternate wording suggestion by the end of next week (March 28th). It was decided that if Bill comes up with an acceptable alternate wording, that will be incorporated to the next version of the draft. Otherwise the current wording will be used. The other problematic issue was that the current draft discusses a nummber of possible solutions. Even though these solutions are only used for illustrative purposes, some people had been raised the question on the mailing list whether a problem statement document should include this kind of text at all. The discussion at the mailing list has inconclusive. James Kempf (taking his chair hat off) supposed that the solutions text should be left in the draft, after all, as examples. Bill Sommerfeld supported that, and Alper Yegin (who had raised the issue originally) agreed that the solutions can stay in as long as it is explained that they are just examples. Thus, the decision was to keep the solutions in the text. 10 min. - Self Signed Certificates for CGAs, Tuomas Aura (presented by Pekka Nikander) Pekka Nikander presented Tuomas Aura's slides on his generic draft on using Cryptographically generated IPv6 addresses (CGA). (See the slides). Pekka told that as far as he knows, the idea is covered by IPR at least by Ericsson and possibly Microsoft. Ericsson has recently released the IPR on this; the statement has been posted to the mailing list and is available at the IETF IPR page. The chairs are discussing the issue with Microsoft now. Hesham Soliman asked whether is the IPR on the CGA idea, or on specific applications? Pekka replied that as far as he knows, the IPRs cover the CGA idea itself. One of the biggest technical problems with CGA so far has been the fact that the IPv6 address structure limits the hash length into 62 bits, which is somewhat insecure. The basic idea in draft-aura-cga-00.txt a method for removing this 64 bit limit by introducing a security parameter (sec) and a seconnd hash (see the slides). With this technique, the cost of address generation and the cost of attacks are increased, keeping their ratio 2^59, but the cost of verification remains constant. Furthermore, the additional cost possibly imposed at address generation can be divided over multiple addresses, since the second hash is independent on the routing prefix and can therefore be used multiple times. In addition to solving the problem with short hash lengths the draft provides exacts algorithms and formats for using CGA addresses. After the presentation Jari Arkko went to the microphone and expressed that he liked this draft, and that it looks good for fast mobility. 20 min. - Open Issues on draft-ietf-send-ipsec-00.txt, Jari Arkko (see slides) The Design Team has now worked on a solution for some time now, and the draft represents a snapshot of the current thinking. Jari first went through the overall design, and the continued to the most important issues with the document. The first issue with the document is that it has somewhat broad scope, describing several more or less indipendent techniques, and it looks like the final draft might become quite large. Furthermore, since CGA is covered by IPRs, it may be necessary to split the CGA dependent portions of the draft out. James Kempf opinioned that if the Working Group is able to get the CGA IPR released, the draft does not have to be split. A split could slow down the process. Thus, all parts should go together. Bill Sommerfeld seconded that splitting out CGA makes sense. Alper Yegin said that since there are two independent problems and solutions, Neighbor Discovery and Router Discovery, it makes sense to split, so that one or the other part can be replaced with alternative methods when they are available. After some discussion the chairs declared consensus on that if CGA IPR not resolved, we need to split CGA as a separate part. Otherwise, we'll go with one draft, since there doesn't seem to be any compelling reason to split, and there seems to be different suggestions for splitting, without any single one getting any larger support. The second open issue considered the presented transition scheme. The basic idea in the transition scheme is to view the link as two separate logical links, one being secured with SEND and the other one not. Alper Yegin noted that there is a problem with DAD when some nodes do not support SEND. That can lead to colliding link-local IPv6 addresses. Erik Nordmark noted that the two colliding addresses should be considered to be on two separate links, so no problem. However, this might require implementation considerations. Pekka Savola noted that possibley one could also look at the G bit. Erik Nordmark continued that what doesn't work in this case is that DAD is not going to detect two identical mac addresses being same. This has some disadvantages. In general, it looks like the transition scheme has still some open issues and requires more consideration. The next open issues considered solicitations. Some soliciations have side effects, and therefore they should be secured. However, some solicitations use unassigned source address, and therefore it is very hard to secure them with CGA. Dave Thaler said that there is clearly a threat with the solicitations, the solution should handle it. Additionally, the requirements draft should talk about this threat. It was agreed that the requirements draft must be updated to handle this. 5 min. - Draft Status and Schedule, chairs James Kempf discussed the draft status and schedule (see slides). There was no discussion. 10 min. - Interaction with PANA / DHCP, chairs The final item considered interaction with SEND and PANA and DHCP. Pekka Nikander described some possible scenarios, mainly made to give people something to think about. (see slides) Bernard Aboba said that passing PANA created keys between various parties is not a good idea. The overall system looks very complex, and analysing it would be a nightmare. Parijat Mishra said that in his opinion this is a good idea. If we don't do this, we'll end up with too many keys. Bill Sommerfelds reaction was similar to that of Bernard. There is gotta be a better way. Erik Nordmark said that a short write up on what kind of problems we are solving here would be useful. --------------060706070403040704090601-- -------------------------------------------------------------------- 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 Mar 20 19:46:56 2003 Received: from albatross.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 TAA15978 for ; Thu, 20 Mar 2003 19:46:55 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2L0k0bh027026; Fri, 21 Mar 2003 01:46:00 +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.2655.55) id HH7GTBNQ; Fri, 21 Mar 2003 01:46:01 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2L0jxK18902; Fri, 21 Mar 2003 01:45:59 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2L0jZYl021520; Fri, 21 Mar 2003 01:45:35 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2L0jZsL021519; Fri, 21 Mar 2003 01:45:35 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2L0jXYl021494 for ; Fri, 21 Mar 2003 01:45:33 +0100 (MET) Date: Thu, 20 Mar 2003 16:45:34 -0800 Subject: CGA... From: Alper Yegin To: SEND WG , Francis Dupont Message-ID: In-Reply-To: <200303210020.h2L0Kpof062003@givry.rennes.enst-bretagne.fr> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h2L0jYYl021507 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by fnatte.sw.ericsson.se id h2L0jxK18902 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA15978 I hope Francis does not mind me forwarding this message here.... I think the following point is worth discussing on the SEND ML: => BTW I strongly disagree about this idea that CGAs provide any kind of authentication. I think, CGAs provide "proof of authorization to use an IPv6 address", but yes, I agree, it doesn't "authenticate" host or anything. I think what SEND needs is the former. Maybe I'm stating the obvious here, but I just wanted to make sure we separate authentication and authorization in this context. On the other hand, protecting the router advertisements part of SEND involves both authentication and authorization of access routers. alper ------ Forwarded Message From: Francis Dupont Date: Fri, 21 Mar 2003 01:20:51 +0100 To: Julien Laganier Cc: Samita Chakrabarti , ipng@sunroof.eng.sun.com, erik.nordmark@Sun.COM, samita@eng.sun.com Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API In your previous mail you wrote: Le Vendredi 21 Mars 2003 00:39, Francis Dupont a écrit : => you should avoid French in this list (:-). It is expected that most applications should work fine without tuning the => this is exactly the assumption I strongly disagree with. source address selection algorithm. If an application cannot work fine with system-wide defaults, then the develloper should be aware of that, and may choose to use this API. I guess that what your point here is that end users may want to tune the behavior of many applications they use without modyfing them. I believe it is a different problem. => this is the problem we have to solve. Do you want to recompile your mozilla in order to add a new parameter for home/care-of choice, for instance to use the best option when you know where is a Web server... Moreover, defining this policy in the environment may not be sufficiently fine-grained for a lot of applications: A single application may want to send packets using both its CoA and HoA as a source address, or both its TMP and Public, etc. => the policy in the environment has the same capability than your proposal when the environment can be changed from applications. And this is the usual case. An example of that is an application that first use a TMP address, and after authentication switch to a PUB address. Same thing with CGA that allows ownership-authentication => BTW I strongly disagree about this idea that CGAs provide any kind of authentication. but is not always supported by both peers, so you can revert to a non-CGA if authentication fails. However, your proposition of having an environment "thing" that tweak the source address selection for applications that does not use this API sounds good to me, but I believe this is not the scope of this document. => so write another more useful one? Seriously I believe that all the tuning stuff, including your knobs, the policy table and other things like the DNS search list (a global one makes no sense as quoted today), should be in an environment "thing" with a standard way to manage it. Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ------ End of Forwarded Message -------------------------------------------------------------------- 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 Mar 20 20:37:05 2003 Received: from albatross.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 UAA17980 for ; Thu, 20 Mar 2003 20:37:04 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2L1b9bh002940; Fri, 21 Mar 2003 02:37:09 +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.2655.55) id HH5MMN91; Fri, 21 Mar 2003 02:37:09 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2L1b3K20517; Fri, 21 Mar 2003 02:37:03 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2L1amYl027183; Fri, 21 Mar 2003 02:36:48 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2L1amEv027182; Fri, 21 Mar 2003 02:36:48 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2L1alYl027177 for ; Fri, 21 Mar 2003 02:36:47 +0100 (MET) Received: from [193.229.5.109] by fep02-app.kolumbus.fi with ESMTP id <20030321013646.EDOR4145.fep02-app.kolumbus.fi@[193.229.5.109]>; Fri, 21 Mar 2003 03:36:46 +0200 From: To: CC: Subject: Re: CGA... Date: Fri, 21 Mar 2003 3:36:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20030321013646.EDOR4145.fep02-app.kolumbus.fi@[193.229.5.109]> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit I agree that CGAs provide authorization, and only that. (The other side of the issue is that authentication may not be very useful for ND.) 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 Mar 21 00:53:06 2003 Received: from albatross.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 AAA22665 for ; Fri, 21 Mar 2003 00:53:06 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2L5rDbh002321; Fri, 21 Mar 2003 06:53:14 +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.2655.55) id HH7G4FZ3; Fri, 21 Mar 2003 06:53:13 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2L5rAK26167; Fri, 21 Mar 2003 06:53:10 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2L5qcYl008739; Fri, 21 Mar 2003 06:52:38 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2L5qcn4008738; Fri, 21 Mar 2003 06:52:38 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2L5qaYl008734 for ; Fri, 21 Mar 2003 06:52:36 +0100 (MET) Date: Thu, 20 Mar 2003 21:52:42 -0800 Subject: Re: CGA... From: Alper Yegin To: CC: Message-ID: In-Reply-To: <20030321013646.EDOR4145.fep02-app.kolumbus.fi@[193.229.5.109]> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > I agree that CGAs provide authorization, and only > that. > > (The other side of the issue is that authentication may > not be very useful for ND.) Do you care to elaborate this a bit? How are we getting the hosts to trust the router advertisements without involving any authentication? alper -------------------------------------------------------------------- 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 Mar 21 11:48:55 2003 Received: from albatross.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 LAA18566 for ; Fri, 21 Mar 2003 11:48:55 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2LGjRbi012644; Fri, 21 Mar 2003 17:45:38 +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.2655.55) id HK14G5SK; Fri, 21 Mar 2003 17:45:23 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2LGjK220796; Fri, 21 Mar 2003 17:45:20 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2LGicYl028759; Fri, 21 Mar 2003 17:44:38 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2LGibnL028758; Fri, 21 Mar 2003 17:44:37 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2LGiaYl028754 for ; Fri, 21 Mar 2003 17:44:36 +0100 (MET) Received: from [193.229.5.108] by fep20-app.kolumbus.fi with ESMTP id <20030321164436.DNLA8208.fep20-app.kolumbus.fi@[193.229.5.108]>; Fri, 21 Mar 2003 18:44:36 +0200 From: To: CC: Subject: Re: CGA... Date: Fri, 21 Mar 2003 18:44:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20030321164436.DNLA8208.fep20-app.kolumbus.fi@[193.229.5.108]> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > How are we getting the hosts to trust the router advertisements without > involving any authentication? Well, when I said that authentication may not be so useful for ND I meant primarily the neighbor (not router) discovery part. In there, it may not be very useful for you to know that I am jari@arkko.com, because that doesn't help you deciding that I would somehow be allowed to defend a particular IP address or an IID in DAD, for instance. As long as you know that I am allowed to *do* something, you don't need to know *who* I am. For router discovery we currently use a cert based approach where authentication is involved. It seems more like a mandatory side-effect of the used scheme rather than a fundamental requirement, however. And it is not enough: we also need to know that foobar.operator.com really is allowed to be a *router* for the given operator, not just e.g. a web server, CPE box completely outside the control of the operator, etc. In fact, this seems to be an issue in draft-send-ipsec-00.txt; it probably should define some sort of certificate extension to authorize the use of the certificate for claiming right to be a router... 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 Mar 21 12:13:37 2003 Received: from penguin.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 MAA19215 for ; Fri, 21 Mar 2003 12:13:36 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2LHDOHQ006094; Fri, 21 Mar 2003 18:13:24 +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.2655.55) id HK14HC22; Fri, 21 Mar 2003 18:13:24 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2LHDNK21717; Fri, 21 Mar 2003 18:13:23 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2LHD5Yl002429; Fri, 21 Mar 2003 18:13:05 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2LHD57k002428; Fri, 21 Mar 2003 18:13:05 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2LHD3Yl002424 for ; Fri, 21 Mar 2003 18:13:03 +0100 (MET) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22406; Fri, 21 Mar 2003 10:12:59 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2LHCw9P015979; Fri, 21 Mar 2003 12:12:58 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LHCwaj008271; Fri, 21 Mar 2003 12:12:58 -0500 (EST) Message-Id: <200303211712.h2LHCwaj008271@thunk.east.sun.com> From: Bill Sommerfeld To: jari.arkko@kolumbus.fi cc: alper@docomolabs-usa.com, ietf-send@standards.ericsson.net Subject: Re: CGA... In-Reply-To: Your message of "Fri, 21 Mar 2003 18:44:36 +0200." <20030321164436.DNLA8208.fep20-app.kolumbus.fi@[193.229.5.108]> Reply-to: sommerfeld@east.sun.com Date: Fri, 21 Mar 2003 12:12:58 -0500 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk > > How are we getting the hosts to trust the router advertisements without > > involving any authentication? > > As long as you > know that I am allowed to *do* something, you don't need to > know *who* I am. Well, arguably, the router discovery approach we've proposed is, in a sense, a use of "authorization certificates" rather than "authentication certificates". > it probably should define some sort of certificate extension to > authorize the use of the certificate for claiming right to be a > router... It's far from clear that we need to use x.509/pkix format certificates, as they carry along a lot of baggage which doesn't solve the problem we're interested in. And, in any event, I owe the WG a writeup on how to use DNSSEC-format signed blobs for this purpose.. - Bill -------------------------------------------------------------------- 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 Mar 21 13:42:22 2003 Received: from albatross.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 NAA22135 for ; Fri, 21 Mar 2003 13:42:21 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2LIg0bi027747; Fri, 21 Mar 2003 19:42:00 +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.2655.55) id HKFWX6XH; Fri, 21 Mar 2003 19:42:00 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2LIfw223501; Fri, 21 Mar 2003 19:41:58 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2LIfMYl013086; Fri, 21 Mar 2003 19:41:22 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2LIfMBt013085; Fri, 21 Mar 2003 19:41:22 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2LIfKYl013081 for ; Fri, 21 Mar 2003 19:41:21 +0100 (MET) Message-ID: <00dc01c3680b$3039f720$8b6015ac@T23KEMPF> From: "James Kempf" To: , Cc: , References: <200303211712.h2LHCwaj008271@thunk.east.sun.com> Subject: Re: CGA... Date: Thu, 21 Aug 2003 10:26:49 -0700 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 ----- > It's far from clear that we need to use x.509/pkix format > certificates, as they carry along a lot of baggage which doesn't solve > the problem we're interested in. > > And, in any event, I owe the WG a writeup on how to use DNSSEC-format > signed blobs for this purpose.. > Having a smaller certificate size would be really useful to help reduce problems with fragmentation. On the local link, this isn't a problem because the path MTU discovery should be pretty accurate, but in tunnels, for example from a Mobile IP Home Agent, it could be a problem. 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 Mar 21 14:01:32 2003 Received: from albatross.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 OAA22659 for ; Fri, 21 Mar 2003 14:01:31 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2LJ1dbh000221; Fri, 21 Mar 2003 20:01:39 +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.2655.55) id HMMRQASM; Fri, 21 Mar 2003 20:01:39 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2LJ1bK24898; Fri, 21 Mar 2003 20:01:37 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2LJ1KYl016321; Fri, 21 Mar 2003 20:01:20 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2LJ1KqK016320; Fri, 21 Mar 2003 20:01:20 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2LJ1HYl016316 for ; Fri, 21 Mar 2003 20:01:18 +0100 (MET) Date: Fri, 21 Mar 2003 11:01:25 -0800 Subject: Re: CGA... From: Alper Yegin To: CC: Message-ID: In-Reply-To: <20030321164436.DNLA8208.fep20-app.kolumbus.fi@[193.229.5.108]> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit >> How are we getting the hosts to trust the router advertisements without >> involving any authentication? > > Well, when I said that authentication may not be so useful > for ND I meant primarily the neighbor (not router) discovery > part. Thanks for the clarification. > In there, it may not be very useful for you to know "it may not be needed" is more accurate I believe. > that I am jari@arkko.com, because that doesn't help you > deciding that I would somehow be allowed to defend a particular > IP address or an IID in DAD, for instance. As long as you > know that I am allowed to *do* something, you don't need to > know *who* I am. If the mechanisms used can prevent you from abusing your authorization, then yes, we don't care who you are. This is especially good model for privacy. Let me give a counter example. When a client is authorized to gain network access, we still want to know who they are. This is because although they are authorized to send and receive IP packets, they are not authorized to send router advertisements [send problem!]. Since there is the possibility of this authorization abuse, we want to authenticate them as well so that we can identify them if they don't behave. [there are obvious other reasons for authenticating clients for network access....] > For router discovery we currently use a cert based approach > where authentication is involved. It seems more like a mandatory > side-effect of the used scheme rather than a fundamental > requirement, however. And it is not enough: we also need to > know that foobar.operator.com really is allowed to be a *router* > for the given operator, not just e.g. a web server, CPE box > completely outside the control of the operator, etc. In fact, > this seems to be an issue in draft-send-ipsec-00.txt; it probably > should define some sort of certificate extension to authorize > the use of the certificate for claiming right to be a router... Sounds like additional requirement on the certs. alper -------------------------------------------------------------------- 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 Mar 25 09:31:55 2003 Received: from penguin.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 JAA13853 for ; Tue, 25 Mar 2003 09:31:54 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2PEV0HR001233; Tue, 25 Mar 2003 15:31:18 +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.2655.55) id HMMSLTSD; Tue, 25 Mar 2003 15:31:00 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2PEUs216061; Tue, 25 Mar 2003 15:30:54 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2PETvYl024170; Tue, 25 Mar 2003 15:29:57 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2PETvf2024169; Tue, 25 Mar 2003 15:29:57 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2PETuYl024163 for ; Tue, 25 Mar 2003 15:29:56 +0100 (MET) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 2F4AD24; Tue, 25 Mar 2003 16:40:01 +0200 (EET) Message-ID: <3E8067F7.8010005@nomadiclab.com> Date: Tue, 25 Mar 2003 16:30:15 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: minutes@ietf.org Cc: SEND WG Subject: Minutes for the SEND WG meeting at San Francisco Content-Type: multipart/mixed; boundary="------------040306030803080102030207" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk This is a multi-part message in MIME format. --------------040306030803080102030207 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Please find enclosed the minutes for the SEND WG meeting at San Francisco. Thanks to the note takers, Alper Yegin and JimHeyock Choi. --Pekka Nikander --------------040306030803080102030207 Content-Type: text/plain; name="send_minutes.txt" Content-Disposition: inline; filename="send_minutes.txt" Content-Transfer-Encoding: 7bit Securing Neighbor Discovery WG (send) Tuesday, March 18 at 1545-1645 =============================== CHAIRS: James Kempf Pekka Nikander 5 min. - Agenda discussion, chairs The agenda was accepted. The chairs later on changed it so that the second last item, interaction with PANA / DHCP, was moved after the last item, draft status and schedule. 10 min. - Last Call Issues as resolved for draft-ietf-send-psreq.txt, Pekka Nikander Pekka Nikander went over the issues raised during the WG last call. Most of the issues were minor. However, there were two larges issues, worth spending some face-to-face time. The first issue centered around using the term "trust". Currently the draft uses the term trusts, trusted, trustworthy, etc., in multiple places. However, it would be better to replace the word with more specific words, e.g. "delegation", "authorized", etc. Pekka described how the word is used right now, but also told that he is not very happy with the current resolution of the issue. Bill Sommerfeld came up and promised to come up with alternate wording suggestion by the end of next week (March 28th). It was decided that if Bill comes up with an acceptable alternate wording, that will be incorporated to the next version of the draft. Otherwise the current wording will be used. The other problematic issue was that the current draft discusses a number of possible solutions. Even though these solutions are only used for illustrative purposes, some people had been raised the question on the mailing list whether a problem statement document should include this kind of text at all. The discussion at the mailing list has inconclusive. James Kempf (taking his chair hat off) suggested that the solutions text should be left in the draft, after all, as examples. Bill Sommerfeld supported that, and Alper Yegin (who had raised the issue originally) agreed that the solutions can stay in as long as it is explained that they are just examples. Thus, the decision was to keep the solutions in the text. 10 min. - Self Signed Certificates for CGAs, Tuomas Aura (presented by Pekka Nikander) Pekka Nikander presented Tuomas Aura's slides on his generic draft on using Cryptographically generated IPv6 addresses (CGA). (See the slides). Pekka told that as far as he knows, the idea is covered by IPR at least by Ericsson and possibly by Microsoft. Ericsson has recently released the IPR on this; the statement has been posted to the mailing list and is available at the IETF IPR page. The chairs are discussing the issue with Microsoft now. Hesham Soliman asked whether is the IPR on the CGA idea, or on specific applications? Pekka replied that as far as he knows, the IPRs cover the CGA idea itself. One of the biggest technical problems with CGA so far has been the fact that the IPv6 address structure limits the hash length into 62 bits, which is somewhat insecure. The basic idea in draft-aura-cga-00.txt a method for removing this 64 bit limit by introducing a security parameter (sec) and a seconnd hash (see the slides). With this technique, the cost of address generation and the cost of attacks are increased, keeping their ratio 2^59, but the cost of verification remains constant. Furthermore, the additional cost possibly imposed at address generation can be divided over multiple addresses, since the second hash is independent on the routing prefix and can therefore be used multiple times. In addition to solving the problem with short hash lengths the draft provides exacts algorithms and formats for using CGA addresses. After the presentation Jari Arkko went to the microphone and expressed that he liked this draft, that he likes the idea of generating two separate hashes, and that it looks good for fast mobility. 20 min. - Open Issues on draft-ietf-send-ipsec-00.txt, Jari Arkko (see slides) The Design Team has worked on a solution for some time now, and the draft represents a snapshot of the current thinking. Jari first went through the overall design, and the continued to the most important issues with the document. The first issue with the document is that it has somewhat broad scope, describing several more or less independent techniques, and it looks like the final draft might become quite large. Furthermore, since CGA is covered by IPRs, it may be necessary to split the CGA dependent portions of the draft out. James Kempf opinioned that if the Working Group is able to get the CGA IPR released, the draft does not have to be split. A split could slow down the process. Thus, all parts should go together. Bill Sommerfeld seconded that splitting out CGA makes sense. Alper Yegin said that since there are two independent problems and solutions, Neighbor Discovery and Router Discovery, it makes sense to split, so that one or the other part can be replaced with alternative methods when they are available. After some discussion the chairs declared consensus on that if CGA IPR not resolved, we need to split CGA as a separate part. Otherwise, we'll go with one draft, since there doesn't seem to be any compelling reason to split, and there seems to be different suggestions for splitting, without any single one getting any larger support. The second open issue considered the presented transition scheme. The basic idea in the transition scheme is to view the link as two separate logical links, one being secured with SEND and the other one not. Alper Yegin noted that there is a problem with DAD when some nodes do not support SEND. That can lead to colliding link-local IPv6 addresses. Erik Nordmark noted that the two colliding addresses should be considered to be on two separate links, so no problem. However, this might require implementation considerations. Pekka Savola noted that possibley one could also look at the G bit. Erik Nordmark continued that what doesn't work in this case is that DAD is not going to detect two identical mac addresses being same. This has some disadvantages. In general, it looks like the transition scheme has still some open issues and requires more consideration. The next open issues considered solicitations. Some soliciations have side effects, and therefore they should be secured. However, some solicitations use unassigned source address, and therefore it is very hard to secure them with CGA. Dave Thaler said that there is clearly a threat with the solicitations, the solution should handle it. Additionally, the requirements draft should talk about this threat. It was agreed that the requirements draft must be updated to handle this. The overall plan is to run the Design Team for another couple of months to resolve the remaining technical issues. At the same time, the chairs continue talking to the IPR holders on CGA, to get the IPR released specifically for SEND. 5 min. - Draft Status and Schedule, chairs James Kempf discussed the draft status and schedule (see slides). There was no discussion. 10 min. - Interaction with PANA / DHCP, chairs The final item considered interaction with SEND and PANA and DHCP. Pekka Nikander described some possible scenarios, mainly made to give people something to think about. (see slides) Bernard Aboba said that passing PANA created keys between various parties is not a good idea. The overall system looks very complex, and analysing it would be a nightmare. Parijat Mishra said that in his opinion this is a good idea. If we don't do this, we'll end up with too many keys. Bill Sommerfelds reaction was similar to that of Bernard. There is gotta be a better way. Erik Nordmark said that a short write up on what kind of problems we are solving here would be useful. --------------040306030803080102030207-- -------------------------------------------------------------------- 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 Mar 25 14:51:33 2003 Received: from albatross.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 OAA28231 for ; Tue, 25 Mar 2003 14:51:33 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2PJpTbh023646; Tue, 25 Mar 2003 20:51:29 +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.2655.55) id HKFXVC15; Tue, 25 Mar 2003 20:51:27 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2PJpLK16941; Tue, 25 Mar 2003 20:51:21 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2PJooYl003370; Tue, 25 Mar 2003 20:50:50 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2PJoolb003369; Tue, 25 Mar 2003 20:50:50 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2PJomYl003359 for ; Tue, 25 Mar 2003 20:50:48 +0100 (MET) Date: Tue, 25 Mar 2003 11:51:02 -0800 Subject: Re: comments on send-ipsec-00 From: Alper Yegin To: SEND WG Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I had sent the message below prior to IETF, but haven't seen any response on the ML. Does any one of the SEND authors care to respond? Thanks. alper > Hello, > > I just finished reading the draft. Here are some questions/comments: > > - This is a simple, and possibly a dumb question: In what type of networks are > we concerned about unauthorized nodes sending bogus router advertisements? > Possibly in public access networks, right? Couldn't we simply prevent client > hosts from sending RAs by installing filters on the enforcement points (like > APs in WLAN hotspots)? Any RA sent on the radio network can be dropped. Sure > it is none of the business of the L2 bridge to do that from an architectural > point of view, but from a practical point of view...... > > - "If (DAD) clashes are detected > after three tries, the node is probably under attack, so it should > shut down and report the situation to an administrator." > > Isn't DAD mechanism protected by CGAs as well? How can the attacker produce > the right cryptographic information to claim 3 different IP addresses in a > row? > > - Can the routers still send unsolicited advertisements that can be verified > by hosts with different Trusted Roots? Or, do they have to unicast a different > advertisement to each host? > > - "One effect of this is that secure hosts can not communicate with > insecure hosts using link-local addresses, and vice versa." Can an insecure > host and SEND-secured host still detect DAD collision on their link-local > addresses? If not, then we end up duplicate link-local addresses on the same > link, and this is a no good. > > - "An attacker may still be able to > prevent valid responses or requests from reaching the intended > recipient. As a result both participants are forced to believe that > no address collision exists, when there in fact is." > How can the attacker do that? Is it a MitM physically separating victims? > > Thanks in advance. > > alper -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Mar 26 18:55:29 2003 Received: from penguin.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 SAA23423 for ; Wed, 26 Mar 2003 18:55:28 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2QNt3Y9005234; Thu, 27 Mar 2003 00:55:04 +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.2655.55) id HMLGN89W; Thu, 27 Mar 2003 00:55:01 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2QNsw214546; Thu, 27 Mar 2003 00:54:58 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2QNsDYl009663; Thu, 27 Mar 2003 00:54:13 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2QNsDrb009662; Thu, 27 Mar 2003 00:54:13 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from leapster.dwerryhouse.com.au (www.teledurecords.com [203.30.75.104]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2QNsBYl009654 for ; Thu, 27 Mar 2003 00:54:12 +0100 (MET) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 56963146BA; Thu, 27 Mar 2003 10:54:09 +1100 (EST) Date: Thu, 27 Mar 2003 10:54:09 +1100 From: "Nick 'Sharkey' Moore" To: ietf-send@standards.ericsson.net Subject: Re: comments on send-ipsec-00 Message-ID: <20030326235409.GB18363@zoic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk On Wed, Mar 12, 2003 at 07:56:31PM -0800, Alper Yegin wrote: > > - "If (DAD) clashes are detected > after three tries, the node is probably under attack, so it should > shut down and report the situation to an administrator." > > Isn't DAD mechanism protected by CGAs as well? How can the attacker produce > the right cryptographic information to claim 3 different IP addresses in a > row? This is a real interesting one. I referred to a Dave Barry quote a couple of times at IETF: "I want a laptop so small and light that sometimes I accidentally suck it up one of my nostrils. I also would like to have a cell phone that enabled me to jam the cell phones of people around me." -- Dave Barry I'm not sure we can help with the first bit right now, but I think the second will be pretty easy for people to manage, simply by sending bogus NAs. I've started looking at this based on a CGA/SENDlike approach, but it is kind of tricky. -----N -- Nick 'Sharkey' Moore Research Fellow, CTIE Tel: +61 3 9905 3707 Monash University, Australia Fax: +61 3 9905 5358 -------------------------------------------------------------------- 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 Mar 27 00:27:29 2003 Received: from penguin.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 AAA03442 for ; Thu, 27 Mar 2003 00:27:29 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2R5R4Y9014504; Thu, 27 Mar 2003 06:27:05 +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.2655.55) id HMMS6BZD; Thu, 27 Mar 2003 06:27:05 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2R5QuK26215; Thu, 27 Mar 2003 06:26:56 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2R5QMYl003306; Thu, 27 Mar 2003 06:26:22 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2R5QMUd003305; Thu, 27 Mar 2003 06:26:22 +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.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2R5QLYl003301 for ; Thu, 27 Mar 2003 06:26:21 +0100 (MET) Received: from kolumbus.fi ([62.248.170.100]) by fep20-app.kolumbus.fi with ESMTP id <20030327052620.IUJH8208.fep20-app.kolumbus.fi@kolumbus.fi>; Thu, 27 Mar 2003 07:26:20 +0200 Message-ID: <3E828B4E.8020203@kolumbus.fi> Date: Thu, 27 Mar 2003 07:25:34 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Nick 'Sharkey' Moore" CC: ietf-send@standards.ericsson.net, Alper Yegin Subject: Re: comments on send-ipsec-00 References: <20030326235409.GB18363@zoic.org> In-Reply-To: <20030326235409.GB18363@zoic.org> 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 Nick 'Sharkey' Moore wrote: > On Wed, Mar 12, 2003 at 07:56:31PM -0800, Alper Yegin wrote: > >>- "If (DAD) clashes are detected >> after three tries, the node is probably under attack, so it should >> shut down and report the situation to an administrator." >> >>Isn't DAD mechanism protected by CGAs as well? How can the attacker produce >>the right cryptographic information to claim 3 different IP addresses in a >>row? > > > This is a real interesting one. I referred to a Dave Barry quote > a couple of times at IETF: > > "I want a laptop so small and light that sometimes I > accidentally suck it up one of my nostrils. I also would > like to have a cell phone that enabled me to > jam the cell phones of people around me." -- Dave Barry > > I'm not sure we can help with the first bit right now, but I think > the second will be pretty easy for people to manage, simply by > sending bogus NAs. > > I've started looking at this based on a CGA/SENDlike approach, > but it is kind of tricky. The situation is a bit unclear in the current document, mainly because of the lack of protection for NSs (discussed separately). However, theoretically the situation is as follows: * DAD probes (NS) can be protected with CGAs exactly in the same manner as regular Neighbor Advertisements. * This will enable the receiver to check whether the sender truly owns the addresses, or is just claiming to be. So we can prevent the attack. * Still, even if the sender owns the address it is possible that we have an accidental clash. Thus we can't avoid DAD with CGA, with still have to do it and still have to give up some tried addresses. And its best to construct the protocol so that it gives up after three tries, because it may be up against the NSA "SEND Breake" machine ;-) But note that this is very different from simply listening in on any unsupported claim that the addresss is in use. 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 Thu Mar 27 10:37:15 2003 Received: from albatross.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 KAA03729 for ; Thu, 27 Mar 2003 10:37:15 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2RFXZbh023864; Thu, 27 Mar 2003 16:33:35 +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.2655.55) id HMMTAWDM; Thu, 27 Mar 2003 16:33:28 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2RFXJK25462; Thu, 27 Mar 2003 16:33:19 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2RFWkYl029532; Thu, 27 Mar 2003 16:32:46 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2RFWjY3029531; Thu, 27 Mar 2003 16:32:45 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from web14810.mail.yahoo.com (web14810.mail.yahoo.com [216.136.224.231]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with SMTP id h2RFWiYl029527 for ; Thu, 27 Mar 2003 16:32:44 +0100 (MET) Message-ID: <20030327153243.75531.qmail@web14810.mail.yahoo.com> Received: from [65.213.193.49] by web14810.mail.yahoo.com via HTTP; Thu, 27 Mar 2003 07:32:43 PST Date: Thu, 27 Mar 2003 07:32:43 -0800 (PST) From: CAITR Reply-To: info@caitr.org Subject: Internetworking 2003: Call for Papers To: ietf-send@standards.ericsson.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-114494581-1048779163=:74500" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk --0-114494581-1048779163=:74500 Content-Type: text/plain; charset=us-ascii Dear Colleagues: Our sincere apologies if you receive multiple copies of this announcement. CONFERENCE ANNOUNCEMENT AND CALL FOR PRESENTATIONS Internetworking 2003 June 22-24, 2003 San Jose, California In technical cooperation with IEEE, IFIP, and ACM (Pending) Internetworking 2003 Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following: - Voice over IP (VoIP) - IP Video Conferencing - Storage Area Networks (SANs) - Unicast and Multicast Routing and Convergence - QoS Routing - Network Security and Service Integration - Operational Support Systems - Virtual Private Networks - Internetworking Wireless LANs and 3G Wireless Networks - IP-based Infrastructure for Wireless Networks - Internetworking IP and Optical Networks - Internetworking MPLS with Legacy ATM and Frame Relay Networks - Transition from IPv4 to IPv6 and interworking - Pervasive Computing - High Speed Transport Layer Protocols - Peer to Peer Networking and Grid Computing - Video Teleconferencing (VTC) - 802.11 Hotspots The Internetworking 2003 event in June will include participation from industry, government agencies, and academia. If you need additional technical information, please contact the Technical Cochairs Professor Maurice GAGNAIRE , or Daniel Awduche . --0-114494581-1048779163=:74500 Content-Type: text/html; charset=us-ascii

Dear Colleagues:

Our sincere apologies if you receive multiple copies of this announcement.

     CONFERENCE ANNOUNCEMENT AND CALL FOR PRESENTATIONS

                   Internetworking 2003
                      June 22-24, 2003
                   San Jose, California
      In technical cooperation with IEEE, IFIP, and ACM (Pending)


Internetworking 2003 Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following:

- Voice over IP (VoIP)
- IP Video Conferencing
- Storage Area Networks (SANs)
- Unicast and Multicast Routing and Convergence
- QoS Routing
- Network Security and Service Integration
- Operational Support Systems
- Virtual Private Networks
- Internetworking Wireless LANs and 3G Wireless Networks
- IP-based Infrastructure for Wireless Networks
- Internetworking IP and Optical Networks
- Internetworking MPLS with Legacy ATM and Frame Relay Networks
- Transition from IPv4 to IPv6 and interworking
- Pervasive Computing
- High Speed Transport Layer Protocols
- Peer to Peer Networking and Grid Computing
- Video Teleconferencing (VTC)
- 802.11 Hotspots


The Internetworking 2003 event in June will include participation from industry, government agencies, and academia. If you need additional technical information, please contact the Technical Cochairs Professor Maurice GAGNAIRE <gagnaire@enst.fr>, or Daniel Awduche <Awduche@awduche.com>.

--0-114494581-1048779163=:74500-- -------------------------------------------------------------------- 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 Sat Mar 29 23:28:31 2003 Received: from albatross.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 XAA08137 for ; Sat, 29 Mar 2003 23:28:30 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2U4RKUE011225; Sun, 30 Mar 2003 06:27:20 +0200 (MEST) 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.2655.55) id HKFY55WD; Sun, 30 Mar 2003 06:27:21 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h2U4RH218032; Sun, 30 Mar 2003 06:27:17 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h2U4QPYl001293; Sun, 30 Mar 2003 06:26:25 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h2U4QPFd001292; Sun, 30 Mar 2003 06:26:25 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from master.marx.pl (master.marx.pl [195.205.47.146]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with SMTP id h2U4QNYl001285 for ; Sun, 30 Mar 2003 06:26:24 +0200 (MET DST) Received: from 195.205.47.149 by master.marx.pl (MarXpl SMTPD); id s20030330062617.4662; Sun, 30 Mar 2003 06:26:17 Message-ID: <41575-2200330304235466@464543446789> From: "The Walker's" To: "ietf-send@standards.ericsson.net" Subject: your business opportunity? info please Date: Sat, 29 Mar 2003 22:23:05 -0600 MIME-Version: 1.0 Content-type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h2U4QOYl001289 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Hi! I'd like more info on your business opportunity. I am using a friend's computer. You cannot email me. Please phone me back so we can chat at 866-638-6463. Thank you very much! Annie -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html --------------------------------------------------------------------