From winninglottery22@yahoo.co.uk Wed Jun 9 09:35:21 2004 Received: from secure.echo-server.net (delta.echo-server.net [66.246.62.174] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14409 for ; Wed, 9 Jun 2004 09:35:21 -0400 (EDT) Received: from nobody by secure.echo-server.net with local (Exim 4.34) id 1BY395-0008I8-DX; Wed, 09 Jun 2004 09:29:35 -0400 Subject: FROM: THE PRIZE AWARD DEPARTMENT From: WINNER2004 X-Priority: 3 (Normal) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: RLSP Mailer Message-Id: Date: Wed, 09 Jun 2004 09:29:35 -0400 X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - secure.echo-server.net X-AntiAbuse: Original Domain - lists.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [99 99] / [47 12] X-AntiAbuse: Sender Address Domain - yahoo.co.uk Content-Transfer-Encoding: 7bit FROM: THE PRIZE AWARD DEPARTMENT WORLDWIDE PREMIER LOTTO, UK Congratulations Category A prize winner! You have been selected as one of two winners of the Worldwide Premier Lotto UK computer ballot draws and thus will be a privileged recipient of the grand draw prize of £ 7,500,000 (Seven million five hundred thousand Great Britain Pounds only). Winning File Reference number for your prize is WWPL/UK/ 61-812084; ticket number 003-214-34/A. We in the Worldwide Premier Lotto UK is by this program, launching our model computer balloting lottery draws, developed and designed to satisfy the cravings of the ever growing number of participants in our various lottery programs. With funds accrued exclusively from previous draws, payouts to all winners are guaranteed and will be transferred in record time. After randomly selecting 15,000 participants from an initial database of 300,000 emails and zoning all participants by their respective continents from across the globe, we produced an extensive list from which you have emerged as one of the winners of the Grand Draw prize. To ensure a smooth collection of your winnings, the transfer of your prize is to be handled by our Prize Transfer agents. You are to contact our agents by email and/or fax within a week of receiving this notice. Please find full contact details below: Mr. Simon Perchard Finance Director Link Finance and Trust Ltd. 20 - 24 St. Leonard's Road Windsor SL4 3BB, United Kingdom Great Britain Fax: +44 7092812692 FOREIGN SERVICE NUMBER: +8821646655614 Email: sperchard7@link-fin-trust-uk.com Also find all other relevant winning lottery information below: Draw Serial No: 35/751346 Batch No: 06-A852 Zonal Draw No: A2-003 Grand Draw No: 12099 You are seriously advised to keep all winning lottery information and numbers from the public in line with our company security protocol to avoid double claiming and unwarranted abuse of this program by unscrupulous individuals. Please direct all further correspondences and queries to your respective category Prize Transfer handlers. Congratulations once again from the Worldwide Premier Lotto family. Sincerely, Jansen Arent International Promotions Manager WORLDWIDE PREMIER LOTTO, UK. FAX: +44 7092813189. ___________________________________________________________________________ Mail sent from WebMail service at PHP-Nuke Powered Site Zomi Information Networkr - http://zomi.info From jari.arkko@lmf.ericsson.se Thu Jun 10 03:14:15 2004 Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09710 for ; Thu, 10 Jun 2004 03:14:15 -0400 (EDT) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5A7EDPA003580 for ; Thu, 10 Jun 2004 09:14:14 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 10 Jun 2004 09:14:13 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id L79QB75W; Thu, 10 Jun 2004 09:14:13 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i5A7ECXA013857; Thu, 10 Jun 2004 09:14:12 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i5A7D5It021063; Thu, 10 Jun 2004 09:13:05 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i5A7D5pm021061; Thu, 10 Jun 2004 09:13:05 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i5A7D3It021043 for ; Thu, 10 Jun 2004 09:13:03 +0200 (MET DST) Received: from kolumbus.fi ([80.186.217.250]) by fep01-app.kolumbus.fi with ESMTP id <20040610071303.VDWK4346.fep01-app.kolumbus.fi@kolumbus.fi> for ; Thu, 10 Jun 2004 10:13:03 +0300 Message-ID: <40C80908.3010106@kolumbus.fi> Date: Thu, 10 Jun 2004 10:08:56 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: IESG comments on ndopt draft Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 10 Jun 2004 07:14:13.0431 (UTC) FILETIME=[8881D470:01C44EBA] Content-Transfer-Encoding: 7bit There are two DISCUSS comments, see https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1340&filename=draft-ietf-send-ndopt I have sent in a response, see below. The IESG is meeting today, so a quick response was needed. Further discussion may be needed however, so WG comments on the issues & better responses are very welcome. --Jari > Executive summary: 1) I agree with the authorization model > comments, but I thought this was what we were doing. Maybe > its a text issue, if this was not apparent from the spec. > 2) There were a number of specific suggestions and corrections, > most of which seem like something we should adopt. 3) In > some cases I have presented a reason, such as DoS-avoidance, > for the behaviour that was asked about. 4) I think our > deployment model is suitable for mobile situations, and it > has been considered in the design; there is not much text > explaining about it however. > >>> [2004-06-09] I'm very concerned that the authorization model used by the authors is incorrect. Several of the following comments, including the most serious ones, are based on that belief. >>> >>> Section 4 says "A host and a router must have at least one common trust anchor before the host can adopt the router as its default router." I don't know what it means to "have ... a common trust anchor", but the relationships are different. The host must believe that the chain of authorizations, from the anchor to the router, identifies a node that is *authorized* to route packets for this link. > > > But this is my understanding as well! Is there a text problem > if this was not made clear in the spec? Note: some of the authors > of the spec have been extremely focused on authorization in > their work, so it could be that some text has been missed as > "obvious". > >>> That has nothing to do with whether or not the host in some way trusts the anchor for other purposes. To give a concrete example, > > > Agree 100%! > >>> since router certificates are tied to the addressing structure they're presumably rooted at an RIR. That will be true of virutally all > > > They could be rooted at an RIR, but while waiting for that to > happen, they could also be rooted at your home/company/ISP that > you trust. > >>> router certificates describing public address space, including the routers belonging to EvilHackerDudes.example.org. The fact that I'll trust the certificates from routers for MyCompany.example.com doesn't mean that I'll trust the evil ones. While trust anchors may suffice, the spec must mandate some sort of user (or configuration) interface to describe a full chain of authorized certificates. In some situations, these may not be address certificates. A user sitting in a public hot spot may be willing to trust the owner of the hotspot -- say, via a standard commercial identity certificate, of the type used today on the Web -- without regard to the particular addresses being advertised or assigned. > > > If I understand the above correctly, I believe this is close to > what we have already specified. We would like the addresses for > the routers to appear in the certificates, but we actually do > allow (per configuration) that plain certificates be used as well. > See Section 7.3 and "Unconstrained" certificates. > > Summarizing, I believe the intent -- maybe not the text? -- > of the specification was that whatever trust roots are > configured, they are strictly for SEND purposes only. That > is, we do realize that there's a difference in authorizing > for different tasks. That does not preclude the possibility > of a user trusting the same certificate for different purposes, > however. We also allow for a configuration of a multiple > certificates, and address-less certificates. In conclusion, > I think I agree with the comments that were made, but it is > unclear to what, if anything, in the specification needs > to be changed. > >>> 5.2.2: Clarify that options after the signature option MUST always be ignored (or the packet dropped); in this context, it's ambiguous if such options are only dropped for purposes of signature verification. > > > Ok. > >>> 5.2.4 says that the IPv6 header is covered by the signature. 5.2.1 says that the ICMPv6 header is covered, as well as the source and destination addresses. Which is it? > > > Seems like a discrepancy. I think both headers should be covered. > >>> 5.3.4.2: A 1-hour DELTA value seems amazingly high. Kerberos uses 5 minutes. > > > We could lower it to the Kerberos value. > >>> 6.2.1: Per my comments on Section 4, I'm not convinced that a trust anchor is useful. > > > See my reply above. > >>> 6.2.6: Why does it say that "hosts SHOULD NOT store certificates" under certain conditions? Certificates are self-validating. Ones that aren't part of a chain may be useless, and it may be advantageous under certain conditions to discard them, but strongly advising their discard seems wrong -- if you have the storage (and a good search algorithm), possessing them is useful because it can avoid the need to solicit or receive them later. > > > The reason relates to the specific order we have required the > certificates be sent, and guarding against denial-of-service > attacks relating to memory usage. At the point where we say > "SHOULD NOT store", we know that the other side either did > not follow the spec or has a root we can't verify to. > > But we could have missed something. > >>> 8: The spec says that nodes SHOULD have an option to restrict them to secure NDP messages only. What is the default value for this option? > > > The default value is accepting both secure and non-secure NDP. > There's a specific (and quite secure) way to deal with both. See > Section 8. > >>> Comment: >>> [2004-06-09] Given that there are implementations of this spec, it would be nice to include an appendix giving typical packet lengths, especially for messages with certificates. > > > I think we could do that. > >>> Ted Hardie: >>> Discuss: >>> [2004-06-08] I guess I have a fundamental design question. The draft describes part of the >>> underlying logic in section 6.1 as: >>> >>> >>> The certificate chain of a router terminates in a Router >>> Authorization Certificate that authorizes a specific IPv6 node to act >>> as a router. Because authorization chains are not a common practice >>> in the Internet at the time this specification was written, the chain >>> MUST consist of standard Public Key Certificates (PKC, in the sense >>> of [19]). The certificate chain MUST start from the identity of a >>> trust anchor that is shared by the host and the router. This allows >>> the host to anchor trust for the router's public key in the trust >>> anchor. Note that there MAY be multiple certificates issued by a >>> single trust anchor. >>> >>> One of the common use cases for V6 is in mobile networks, where it >>> may be common for a terminal to operate in a network operated >>> by a provider to whom the user has no direct relationship. Managing >>> the trust anchors in this instance looks to be a fairly hard problem. >>> The draft doesn't seem to address this part of the problem >>> directly, though there is a bit of text on how fast hand-off may enable >>> one router to pass data on the next router along. >>> >>> Have I missed something here in the way of context or text? > > > I don't think you missed any text, but this has certainly been > considered in the design. First, there are two parts in the > authorization problem related to ND: address ownership for > nodes and the authorization of some nodes to be routers. We > have solved the address part using CGAs, a zero-config scheme > which works well in any type of roaming situation. The other > part, routers, can not, as far as we know, be solved completely > without some amount of configuration or infrastructure. However, > the deployment model we are thinking of seems to work well even > in a roaming scenario. Or so we think at least. > > Here's the idea: a node that moves around probably has a > subscription with one or several operators that provides service in > several locations. Either by themselves or through roaming > relationships. Now, what is needed is that the mobile node > gets a SEND root certificate from his operator(s). This > certificate is not the one that is needed for access in > a specific location X, but rather the root of such certificates. > Then if you go to location X, the mobile node will get the > local router's certificate and verify that it can be traced > back to the root certificate. > > We also realize that deploying certificates can be troublesome. > However, in the case of SEND the problem is not quite as > bad as creating a global infrastructure. In particular, > > o SEND can operate (securely) from the start, even > when, say, just your personal home network supports > it but not other locations. > > o SEND requires certificates only for routers, not > for all nodes (see CGA above). > > o SEND certificate hierarchies can be specific to > your home/company/ISP/ISP roaming group, and > do not need to be global. -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From steven_kone20@yahoo.fr Tue Jun 15 15:44:22 2004 Received: from emztd97.com ([196.201.64.238]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12263 for ; Tue, 15 Jun 2004 15:44:19 -0400 (EDT) Message-Id: <200406151944.PAA12263@ietf.org> From: "FROM :STEPHEN KONE" Reply-To: stephen_kone20@yahoo.fr To: send-archive@ietf.org Date: Tue, 15 Jun 2004 13:44:22 +0200 Subject: FROM :STEPHEN KONE/CONTACT EMAIL/ stephen_kone20@yahoo.fr X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable FROM =3ASTEPHEN KONE TEL =3A =28+225=29 07 94 40 72=2E ABIDJAN=2C IVORY COAST WEST-AFRICA CONTACT EMAIL=2F stephen=5Fkone20=40yahoo=2Efr DEAREAST=2C PERMIT ME TO INFORM YOU OF MY DESIRE OF GOING INTO BUSINESS RELATIONSHIP WITH YOU=2E I PRAYED OVER IT AND I WAS CONVINCED AND BELEIVE THAT YOU WILL NOT SEAT ON MY MONEY OR CHEAT ME AFTER THE MONEY IS TRANSFERRED TO YOU=2E I AM STEPHEN KONE=2CTHE ONLY CHILD OF LATE MR AND MRS =2E JOSEPH KONE=2EMY FATHER WAS A VERY WEALTHY COCOA MERCHANT BASED IN ABIDJAN=2CTHE ECONOMIC CAPITAL OF IVORY COAST BEFORE HE WAS POISONED TO DEATH BY HIS BUSINESS ASSOCIATES ON ONE OF THEIR OUTING TO DISCUSS ON A BUSINESS=2E WHEN MY MOTHER DIED ON THE 21ST OCTOBER 1984=2C MY FATHER TOOK ME SO SPECIAL BECAUSE I AM MOTHERLESS=2EBEFORE THE DEATH OF MY FATHER ON 29TH JUNE 2003 IN A PRIVATE HOSPITAL HERE IN ABIDJAN=2E HE SECRET LY CALLED ME ON HIS BEDSIDE AND TOLD ME THAT HE HAS A SUM OF US$ 16=2C500=2C000=2E=28SIXTEEN MILLION FIVE HUNDRED THOUSAND=2CUNITED STATES DOLLARS=29LEFT IN A SUSPENCE ACCOUNT IN A BANK HERE IN ABIDJAN=2C HE USED MY NAME AS HIS ONLY SON FOR THE NEXT OF KIN IN DEPOSIT OF THE FUND=2EHE ALSO EXPLAINED TO ME THAT IT WAS BECAUSE OF THIS WEALTH THAT HE WAS POISONED BY HIS BUSINESSASSOCIATES=2E THAT I SHOULD SEEK FOR A FOREIGN PARTNER IN A COUNTRY OF MY CHOICE WHERE I WILL TRANSFER THIS MONEY AND USE IT FOR INVESTMENT PURPOSE=2C=28SUCH AS REAL ESTATE MANAGEMENT=2E SIR=2EI AM HONOURABLY SEEKING YOUR ASSISTANCE IN THE FOLLOWING WAYS=2E 1=29TO PROVIDE A BANK ACCOUNT WHERE THIS MONEY WOULD BE TRANSFERRED TO 2=29TO SERVE AS THE GUARDIAN OF THIS FUND SINCE I AM A BOY OF 19 YEARS=2E 3=29TO MAKE ARRANGEMENT FOR ME TO COME OVER TO YOUR COUNTRY AFTER THE MONEY HAS BEEN TRANSFERRED=2E MOREOVER=2C SIR=2C I AM WILLING TO OFFER YOU 15% OF THE TOTAL SUM AS COMPENSATION FOR YOUR EFFORT=2FINPUT AFTER THE SUCCESSFUL TRANSFER OF THIS FUND TO YOUR NORMINATED ACCOUNT OVERSEAS=2E FURTHERMOIRE=2C YOU CAN INDICATE YOUR OPTION TOWARDS ASSISTING ME AS I BELIEVE THAT THIS TRANSACTION WOULD BE CONCLUDED WITHIN SEVEN =287=29 DAYS YOU SIGNIFY INTEREST TO ASSIST ME ACCORDING TO THE LAWYER THAT WILL HELP US=2E MUCH WORRIED TO HEAR FROM YOU SOON=2E THANKS AND GOD BLESS FROM STEPHEN KONE=2E PLEASE I WILL NEED YOUR CALL SO THAT I CAN TALK WITH YOU=2CI AM WAITING FOR YOUR CALL=2E CALL=2F+225 079 440 72=2E From jari.arkko@lmf.ericsson.se Thu Jun 17 16:42:19 2004 Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12753 for ; Thu, 17 Jun 2004 16:42:19 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5HKgJPA018776 for ; Thu, 17 Jun 2004 22:42:20 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 17 Jun 2004 22:42:18 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MFZY42L0; Thu, 17 Jun 2004 22:42:18 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i5HKgHXA020362; Thu, 17 Jun 2004 22:42:17 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i5HKf8It023660; Thu, 17 Jun 2004 22:41:08 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i5HKf8MJ023659; Thu, 17 Jun 2004 22:41:08 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i5HKf6It023655 for ; Thu, 17 Jun 2004 22:41:06 +0200 (MET DST) Message-ID: <01df01c454ab$82424b20$2b6115ac@dcml.docomolabsusa.com> From: "James Kempf" To: Subject: Progress on NDOPTS Draft Date: Thu, 17 Jun 2004 13:41:45 -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 X-OriginalArrivalTime: 17 Jun 2004 20:42:18.0974 (UTC) FILETIME=[9508CFE0:01C454AB] Content-Transfer-Encoding: 7bit Folks, The IESG has completed its review of the NDOPTS draft, and, as Jari's email of last week mentioned, there were some specific issues raised. The issues have been recorded on the issues list Web page: http://www.arkko.com/publications/send/issues/ Tuomas, Jari, and I had a teleconference this morning together with the IESG members Steve Bellovin, Margaret Wasserman, and Russ Housley to talk about the issues. We have some suggested resolutions included in the issues list, and Jari will be working over the next couple weeks to update the draft accordingly. If you have any comments on the issues, please send email to the list, identifying the issue number in the Subject: line. Thanx. 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 beloige6@freenet.de Mon Jun 21 02:23:34 2004 Received: from atmail (mail.beernchips.com [207.36.209.96]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12574 for ; Mon, 21 Jun 2004 02:23:32 -0400 (EDT) Received: from [127.0.0.1] (helo=affinity-dedica) by atmail with esmtp (Exim 4.01) id 1BcIAN-00007s-00; Mon, 21 Jun 2004 02:20:27 -0400 Content-Disposition: inline Content-Transfer-Encoding: binary Mime-Version: 1.0 From: Belo Ige To: b Subject: project introduction Reply-To: beloige6@freenet.de Content-Type: text/html; X-Mailer: AtMail Pro . - http://webbasedemail.com/ X-Origin: 213.255.198.51 Message-Id: Date: Mon, 21 Jun 2004 02:20:27 -0400 Content-Transfer-Encoding: binary

Dear Partner to be,

 

 

It is my great pleasure in writing you this letter on behalf of my colleagues and myself.

 

I am Dr. Belo Ige,Divisional  Controller and Chairman of the Project review and monitoring committee of the Federal Airport Aviation pf Nigeria(FAAN).This agency is an arm of the Federal Ministry of Aviation in charge of the execution,implementation and ofcourse,the review of all capital projects in our Airports across the country.

 

My colleagues and I  in the FAAN are currently in need of a foreign partner with whose bank account we shall transfer the sum of Forty Nine Million Five Hundred Thosand United States Dollars($49.5m).

 

To do this, we will need your cooperation as a foreigner who could front to receive the fund on our behalf.

 

SOURCE OF FUND: The amount represents a percentage of the total contract value executed on behalf of my parastatal by a foreign contracting firm which we over-invoiced. Though the actual contract value has been paid to the original contractor, leaving a balance to the tune of the amount aforementioned, which we have in principle secured approval to remit by telegraphic transfer (T.T) to any bank account,you will provide.

 

PROCEDURE:This is because as top civil servants, we are not allowed by law of the land to own or operate bank accounts outside our country for now,we are therefore seeking your assistance in providing a company's account or any other offshore bank account into which we can remit this money($49.5m) by acting as acting as a sub contractor to the original contractor.These shall involve some form of of documentations.

 

I have the authority of my partners to propose that should you be willing to assist us in the transaction, your share of the sum will be 25% of the  $49.5million,70% for us while the balance of 5% will be set aside for refund of all expenses incurred during the process of the transaction.

 

The transaction, although discrete, is legitimate and there is no risk or legal disadvantages either to ourselves or yourself now or in the future as we have put in place perfect mchineries that will ensure a hitch free transfer into your account upon acceptance.

 

The transfer will be effected to your account within ten-fourteen (10-14) working days as soon as you furnish me with the suitable bank and company details together with all your contact numbers.

 

Expecting your response and thank you for your cooperation as you and I will open verbal telephone conversation as soon as I receive your positive response and caontact details.

 

Sincerely,

 

 

Dr.Belo Ige

(Chairman,review panel)



---- Message sent from Breakfast Network Productions, Inc. - http://www.breakfastnetwork.com From jari.arkko@lmf.ericsson.se Mon Jun 28 07:21:27 2004 Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25680 for ; Mon, 28 Jun 2004 07:21:26 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5SBLQWR006733 for ; Mon, 28 Jun 2004 13:21:26 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 28 Jun 2004 13:21:25 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MFZ6B9N0; Mon, 28 Jun 2004 13:21:25 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i5SBLOXA022376; Mon, 28 Jun 2004 13:21:24 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i5SBKMIt021551; Mon, 28 Jun 2004 13:20:22 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i5SBKMm3021548; Mon, 28 Jun 2004 13:20:22 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i5SBKKIt021527 for ; Mon, 28 Jun 2004 13:20:21 +0200 (MET DST) Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 28 Jun 2004 13:20:18 +0200 Received: from PXPELLAFOL ([10.193.161.74]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6713); Mon, 28 Jun 2004 13:20:18 +0200 From: "Jean-Michel COMBES" To: Subject: Problem of interaction between SEND(CGA) and the IPv6 mobility Date: Mon, 28 Jun 2004 13:20:18 +0200 Organization: France Telecom R&D Message-ID: <012701c45d01$e4a05600$4aa1c10a@rd.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-OriginalArrivalTime: 28 Jun 2004 11:20:18.0376 (UTC) FILETIME=[E4892480:01C45D01] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id i5SBKLIt021533 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Hi, IMO, it would be necessary to add a warning in the Security Considerations section regarding the interaction between SEND(CGA) and the IPv6 mobility protocols. *** Problem *** This problem concerns the following IPv6 mobility protocols: - MIPv6 [3] - HMIPv6 [4] - FMIPv6 [5] - NEMO [6] For each of these protocols, the "mobility manager" (HA for MIPv6 and NEMO, MAP for HMIPv6, PAR for FMIPv6) may have to intercept the packets for the Mobile to tunnel them to its real location. To do such a thing, the "mobile manager" uses NDP. As example, from RFC 3775: "In order to do this, when a node begins serving as the home agent it MUST multicast onto the home link a Neighbor Advertisement message [12] on behalf of the mobile node. For the home address specified in the Binding Update, the home agent sends a Neighbor Advertisement message [12] to the all-nodes multicast address on the home link, to advertise the home agent's own link-layer address for this IP address on behalf of the mobile node. If the Link-Layer Address Compatibility (L) flag has been specified in the Binding Update, the home agent MUST do the same for the link-local address of the mobile node." The others IPv6 mobility protocols use exactly the same mechanism. (This mechanism is not clear in FMIPv6 but it is pretty sure this is the same mechanism) So, if SEND(CGA) is used, the "mobility manager" MUST have the private key (associated to the public key used to generated the CGA address) used by the Mobile to sign its ND packets. *** References *** [1] draft-ietf-send-ndopt-05.txt, "SEcure Neighbor Discovery (SEND)", J. Arkko (Editor)/J. Kempf/B. Sommerfeld/B. Zill/P. Nikander, April 2004 [2] draft-ietf-send-cga-06, "Cryptographically Generated Addresses (CGA)", T. Aura, April 2004 [3] RFC 3775, "Mobility Support in IPv6", D. Johnson/C. Perkins/J. Arkko, June 2004 [4] draft-ietf-mipshop-hmipv6-02.txt, "Hierarchical Mobile IPv6 mobility management (HMIPv6)", H. Soliman/C. Catelluccia/K. El Malki/L.Bellier, June 2004 [5] draft-ietf-mipshop-fast-mipv6-01.txt, "Fast Handovers for Mobile IPv6", R. Koodli (Editor), January 2004 [6] draft-ietf-nemo-basic-support-03.txt, "Network Mobility (NEMO) Basic Support Protocol", V. Devarapalli/R. Wakikawa/A. Petrescu/P. Thubert, June 2004 Regards. JMC. France Telecom - R&D Division - MAPS/NSS Jean-Michel COMBES, Internet/Intranet Security E-Mail: jeanmichel.combes@francetelecom.com Phone: +33 (0)1 45 29 45 94 Fax: +33 (0)1 45 29 65 19 Mobile: +33 (0)6 07 29 30 16 -------------------------------------------------------------------- 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 Jun 28 07:38:16 2004 Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26535 for ; Mon, 28 Jun 2004 07:38:16 -0400 (EDT) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5SBcCWR010892 for ; Mon, 28 Jun 2004 13:38:16 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 28 Jun 2004 13:38:11 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MA4R0JAV; Mon, 28 Jun 2004 13:38:11 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i5SBbxwg007394; Mon, 28 Jun 2004 13:37:59 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i5SBbPIt025995; Mon, 28 Jun 2004 13:37:25 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i5SBbPsi025994; Mon, 28 Jun 2004 13:37: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 fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i5SBbNIt025989 for ; Mon, 28 Jun 2004 13:37:23 +0200 (MET DST) Received: from mta.imail.kolumbus.fi ([193.229.5.114]) by fep01-app.kolumbus.fi with ESMTP id <20040628113723.ICAV13175.fep01-app.kolumbus.fi@mta.imail.kolumbus.fi>; Mon, 28 Jun 2004 14:37:23 +0300 X-Mailer: Openwave WebEngine, version 2.8.10 (webedge20-101-191-20030113) From: To: CC: Subject: Re: Problem of interaction between SEND(CGA) and the IPv6 mobility Date: Mon, 28 Jun 2004 14:37:23 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20040628113723.ICAV13175.fep01-app.kolumbus.fi@mta.imail.kolumbus.fi> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 28 Jun 2004 11:38:11.0688 (UTC) FILETIME=[64478E80:01C45D04] Content-Transfer-Encoding: 7bit Hi Jean-Michel, 1) I agree that the issue that you mention is a limitation. I'm not sure the security considerations section is the right place to explain the limitation, however; it seems that the limitation is functional rather than security related. In any case, Section 7.14 (Limitations) already states: "Proxy Neighbor Discovery is not supported by this specification." Do you think more text is needed? 2) I believe there's a solution that can support proxy ND with SEND; for now the WG has determined that it will not include the solution in the current RFC. However, there's a plan to develop an extension later. I guess the interest level for SEND and its combined use with things like MIPv6 determines how soon is "later". Chairs? 3) In the meanwhile, MIPv6 home addresses and SEND would work with so called virtual home networks where the mobile nodes never go to. Care-of addresses will of course work with SEND in any case. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Jun 28 08:59:14 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03006 for ; Mon, 28 Jun 2004 08:59:13 -0400 (EDT) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5SCxEAh003210 for ; Mon, 28 Jun 2004 14:59:14 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 28 Jun 2004 14:59:14 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MATPMHYX; Mon, 28 Jun 2004 14:59:13 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i5SCx5wg012413; Mon, 28 Jun 2004 14:59:05 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i5SCw9It017623; Mon, 28 Jun 2004 14:58:09 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i5SCw9SV017622; Mon, 28 Jun 2004 14:58:09 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i5SCw7It017617 for ; Mon, 28 Jun 2004 14:58:08 +0200 (MET DST) Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 28 Jun 2004 14:58:06 +0200 Received: from PXPELLAFOL ([10.193.161.74]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6713); Mon, 28 Jun 2004 14:58:06 +0200 From: "Jean-Michel COMBES" To: Cc: Subject: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility Date: Mon, 28 Jun 2004 14:58:06 +0200 Organization: France Telecom R&D Message-ID: <013701c45d0f$8e54c7f0$4aa1c10a@rd.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20040628113723.ICAV13175.fep01-app.kolumbus.fi@mta.imail.kolumbus.fi> Importance: Normal X-OriginalArrivalTime: 28 Jun 2004 12:58:06.0626 (UTC) FILETIME=[8E490820:01C45D0F] X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id i5SCw8It017618 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by fnatte.sw.ericsson.se id i5SCx5wg012413 Content-Transfer-Encoding: quoted-printable > -----Message d'origine----- > De : jari.arkko@kolumbus.fi [mailto:jari.arkko@kolumbus.fi]=20 > Envoy=E9 : lundi 28 juin 2004 13:37 > =C0 : COMBES jean-michel FTRD/DTL > Cc : ietf-send@standards.ericsson.net > Objet : Re: Problem of interaction between SEND(CGA) and the=20 > IPv6 mobility >=20 >=20 >=20 > Hi Jean-Michel, >=20 > 1) I agree that the issue that you mention is a > limitation. I'm not sure the security considerations > section is the right place to explain the limitation, > however; it seems that the limitation is functional > rather than security related. IMO, this is a security issue because SEND works if the "proxy" has the Mobile's key and so the issue is in fact linked to the CGA key distributi= on (Mobile -> "proxy" or "proxy" -> Mobile) >=20 > In any case, Section 7.14 (Limitations) already > states: "Proxy Neighbor Discovery is not supported > by this specification." Do you think more text > is needed? Yes, IMO, I think we need more text ... I am afraid to see in some drafts "Just use SEND" as we saw for RFC 2401 with "Just use IPsec". >=20 > 2) I believe there's a solution that can support > proxy ND with SEND; for now the WG has determined > that it will not include the solution in the current > RFC. However, there's a plan to develop an extension > later. I guess the interest level for SEND and its > combined use with things like MIPv6 determines how > soon is "later". Chairs? >=20 > 3) In the meanwhile, MIPv6 home addresses and SEND would > work with so called virtual home networks where the > mobile nodes never go to. Agree. This is the right solution for MIPv6, HMIPv6 and NEMO ... > Care-of addresses will of > course work with SEND in any case. ... but with FMIPv6 we have still a problem: the "proxy" function is concerning the Co@ (for the tunneling between the PAR and the NAR). >=20 > --Jari >=20 >=20 Regards. JMC. France Telecom - R&D Division - MAPS/NSS =20 Jean-Michel COMBES, Internet/Intranet Security E-Mail: jeanmichel.combes@francetelecom.com Phone: +33 (0)1 45 29 45 94 Fax: +33 (0)1 45 29 65 19 Mobile: +33 (0)6 07 29 30 16=20 -------------------------------------------------------------------- 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 Jun 28 09:02:59 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03180 for ; Mon, 28 Jun 2004 09:02:58 -0400 (EDT) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5SD2sAh004093 for ; Mon, 28 Jun 2004 15:02:58 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 28 Jun 2004 15:02:54 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MFZ6CZ81; Mon, 28 Jun 2004 15:02:54 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i5SD2rwg012686; Mon, 28 Jun 2004 15:02:53 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i5SD2YIt019577; Mon, 28 Jun 2004 15:02:34 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i5SD2YMp019576; Mon, 28 Jun 2004 15:02:34 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i5SD2XIt019572 for ; Mon, 28 Jun 2004 15:02:33 +0200 (MET DST) Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 28 Jun 2004 15:02:32 +0200 Received: from PXPELLAFOL ([10.193.161.74]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6713); Mon, 28 Jun 2004 15:02:32 +0200 From: "Jean-Michel COMBES" To: "'COMBES jean-michel FTRD/DTL'" , Cc: Subject: RE : RE : Problem of interaction between SEND(CGA) and the IPv6 mobility Date: Mon, 28 Jun 2004 15:02:32 +0200 Organization: France Telecom R&D Message-ID: <013901c45d10$2c9775c0$4aa1c10a@rd.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <013701c45d0f$8e54c7f0$4aa1c10a@rd.francetelecom.fr> Importance: Normal X-OriginalArrivalTime: 28 Jun 2004 13:02:32.0141 (UTC) FILETIME=[2C8B67D0:01C45D10] X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id i5SD2XIt019573 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by fnatte.sw.ericsson.se id i5SD2rwg012686 Content-Transfer-Encoding: quoted-printable >=20 > > -----Message d'origine----- > > De : jari.arkko@kolumbus.fi [mailto:jari.arkko@kolumbus.fi] > > Envoy=E9 : lundi 28 juin 2004 13:37 > > =C0 : COMBES jean-michel FTRD/DTL > > Cc : ietf-send@standards.ericsson.net > > Objet : Re: Problem of interaction between SEND(CGA) and the=20 > > IPv6 mobility > >=20 > >=20 > >=20 > > Hi Jean-Michel, > >=20 > > 1) I agree that the issue that you mention is a > > limitation. I'm not sure the security considerations > > section is the right place to explain the limitation, however; it=20 > > seems that the limitation is functional rather than=20 > security related. >=20 > IMO, this is a security issue because SEND works if the=20 > "proxy" has the Mobile's key and so the issue is in fact=20 > linked to the CGA key distribution (Mobile -> "proxy" or=20 > "proxy" -> Mobile) >=20 > >=20 > > In any case, Section 7.14 (Limitations) already > > states: "Proxy Neighbor Discovery is not supported > > by this specification." Do you think more text > > is needed? >=20 > Yes, IMO, I think we need more text ... I am afraid to see in=20 > some drafts "Just use SEND" as we saw for RFC 2401 with "Just=20 > use IPsec". Sorry, I meant RFC 2461 ... France Telecom - R&D Division - MAPS/NSS =20 Jean-Michel COMBES, Internet/Intranet Security E-Mail: jeanmichel.combes@francetelecom.com Phone: +33 (0)1 45 29 45 94 Fax: +33 (0)1 45 29 65 19 Mobile: +33 (0)6 07 29 30 16=20 -------------------------------------------------------------------- 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 Jun 29 23:18:29 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17281 for ; Tue, 29 Jun 2004 23:18:29 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5U3IQAh003374 for ; Wed, 30 Jun 2004 05:18:30 +0200 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 30 Jun 2004 05:18:26 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MA4SNT1J; Wed, 30 Jun 2004 05:18:26 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i5U3IPXA027735; Wed, 30 Jun 2004 05:18:25 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i5U3HQIt004937; Wed, 30 Jun 2004 05:17:26 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i5U3HQQe004936; Wed, 30 Jun 2004 05:17:26 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i5U3HNIt004916 for ; Wed, 30 Jun 2004 05:17:24 +0200 (MET DST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LBWR5T5ITI8X63J4@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Wed, 30 Jun 2004 13:15:01 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EEB1BAB544; Wed, 30 Jun 2004 13:14:58 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id C72DD4FB14; Wed, 30 Jun 2004 13:14:58 +1000 (EST) Date: Wed, 30 Jun 2004 13:14:58 +1000 From: Greg Daley Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility To: Jean-Michel COMBES Cc: jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <40E23032.1070809@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <013701c45d0f$8e54c7f0$4aa1c10a@rd.francetelecom.fr> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tjatte.sw.ericsson.se id i5U3IPXA027735 X-OriginalArrivalTime: 30 Jun 2004 03:18:26.0429 (UTC) FILETIME=[E87FA2D0:01C45E50] Content-Transfer-Encoding: quoted-printable Hi Jean-Michel, Jean-Michel COMBES wrote: >=20 >>-----Message d'origine----- >>De : jari.arkko@kolumbus.fi [mailto:jari.arkko@kolumbus.fi]=20 >>Envoy=E9 : lundi 28 juin 2004 13:37 >>=C0 : COMBES jean-michel FTRD/DTL >>Cc : ietf-send@standards.ericsson.net >>Objet : Re: Problem of interaction between SEND(CGA) and the=20 >>IPv6 mobility >> >> >> >>Hi Jean-Michel, >> >>1) I agree that the issue that you mention is a >>limitation. I'm not sure the security considerations >>section is the right place to explain the limitation, >>however; it seems that the limitation is functional >>rather than security related. >=20 >=20 > IMO, this is a security issue because SEND works if the "proxy" has the > Mobile's key and so the issue is in fact linked to the CGA key distribu= tion > (Mobile -> "proxy" or "proxy" -> Mobile) >=20 >=20 >>In any case, Section 7.14 (Limitations) already >>states: "Proxy Neighbor Discovery is not supported >>by this specification." Do you think more text >>is needed? >=20 >=20 > Yes, IMO, I think we need more text ... I am afraid to see in some draf= ts > "Just use SEND" as we saw for RFC 2401 with "Just use IPsec". I think that 'Just Use SEND' is probably better in some cases, because it has fallback modes for non-signed messages. There are other issues than whether the messages are signed or not which affect mobile IPv6. >=20 >>2) I believe there's a solution that can support >>proxy ND with SEND; for now the WG has determined >>that it will not include the solution in the current >>RFC. However, there's a plan to develop an extension >>later. I guess the interest level for SEND and its >>combined use with things like MIPv6 determines how >>soon is "later". Chairs? >> >>3) In the meanwhile, MIPv6 home addresses and SEND would >>work with so called virtual home networks where the >>mobile nodes never go to. >=20 >=20 > Agree. This is the right solution for MIPv6, HMIPv6 and NEMO ... I always through it was, regardless of whether SEND is in use... >=20 >>Care-of addresses will of >>course work with SEND in any case. >=20 >=20 > ... but with FMIPv6 we have still a problem: the "proxy" function is > concerning the Co@ (for the tunneling between the PAR and the NAR). Indeed. There is almost always going to be a problem in MIPv6 for existing Mobile Nodes which move off a home network and peers still have a valid neighbour cache entry. A Home agent won't be able to override NC entries with proxy advertisements if the override flag is unset in NAs. This isn't a direct problem with SEND though, since existing ND has this issue too. Of course, I've not waded through RFC3775 recently to see how proxy neighbour discovery is handled in this case (maybe Jari knows better). If the peer is a SEND node though, the poblem is complicated, since it may have knowledge of the other device's previously used keying material even if the NCE isn't in a valid state. This may make an unsecured NA get ignored. 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 Jun 30 18:43:54 2004 Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27059 for ; Wed, 30 Jun 2004 18:43:54 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5UMhtPA026443 for ; Thu, 1 Jul 2004 00:43:55 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 Jul 2004 00:43:55 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id L7947R0Q; Thu, 1 Jul 2004 00:43:54 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i5UMhlwg000553; Thu, 1 Jul 2004 00:43:47 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i5UMgrIt021801; Thu, 1 Jul 2004 00:42:53 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i5UMgqwJ021800; Thu, 1 Jul 2004 00:42:52 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i5UMgoIt021791 for ; Thu, 1 Jul 2004 00:42:51 +0200 (MET DST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i5UMgeq31617; Wed, 30 Jun 2004 15:42:40 -0700 X-mProtect: <200406302242> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdnEEukn; Wed, 30 Jun 2004 15:42:39 PDT Message-ID: <40E342FC.5060103@iprg.nokia.com> Date: Wed, 30 Jun 2004 15:47:24 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040430 X-Accept-Language: en-us, en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au CC: Jean-Michel COMBES , jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility References: <013701c45d0f$8e54c7f0$4aa1c10a@rd.francetelecom.fr> <40E23032.1070809@eng.monash.edu.au> In-Reply-To: <40E23032.1070809@eng.monash.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 30 Jun 2004 22:43:55.0060 (UTC) FILETIME=[B935EF40:01C45EF3] Content-Transfer-Encoding: 7bit >> >> ... but with FMIPv6 we have still a problem: the "proxy" function is >> concerning the Co@ (for the tunneling between the PAR and the NAR). > > > Indeed. > > There is almost always going to be a problem > in MIPv6 for existing Mobile Nodes which move off a home > network and peers still have a valid neighbour cache > entry. A Home agent won't be able to override NC entries with > proxy advertisements if the override flag is unset in NAs. > > This isn't a direct problem with SEND though, since existing > ND has this issue too. > > Of course, I've not waded through RFC3775 recently to > see how proxy neighbour discovery is handled in this case > (maybe Jari knows better). as soon as a binding cache is created, the Home Agent sends a gratuitous proxy neighbor advertisement. since this advertisement is not solicited, the Override flag is set to 1. even for solicited proxy neighbor advertisement, the RFC 3775 says Override flag MUST be set. (section 10.4.1) Vijay > > If the peer is a SEND node though, the poblem is complicated, > since it may have knowledge of the other device's previously > used keying material even if the NCE isn't in a valid state. > This may make an unsecured NA get ignored. > > Greg > > -------------------------------------------------------------------- > 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 Jun 30 23:53:01 2004 Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11531 for ; Wed, 30 Jun 2004 23:53:00 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i613r1PA016652 for ; Thu, 1 Jul 2004 05:53:01 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 Jul 2004 05:53:01 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id L7948VY2; Thu, 1 Jul 2004 05:53:01 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i613qtwg008163; Thu, 1 Jul 2004 05:52:55 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i613q9It017348; Thu, 1 Jul 2004 05:52:09 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i613q96E017347; Thu, 1 Jul 2004 05:52:09 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i613q6It017343 for ; Thu, 1 Jul 2004 05:52:07 +0200 (MET DST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LBY6PSIVVO8X7OH9@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Thu, 1 Jul 2004 13:51:00 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D1DCC80034; Thu, 01 Jul 2004 13:50:59 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id B2C783C010; Thu, 01 Jul 2004 13:50:59 +1000 (EST) Date: Thu, 01 Jul 2004 13:50:59 +1000 From: Greg Daley Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility To: Vijay Devarapalli Cc: Jean-Michel COMBES , jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <40E38A23.9030500@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: <013701c45d0f$8e54c7f0$4aa1c10a@rd.francetelecom.fr> <40E23032.1070809@eng.monash.edu.au> <40E342FC.5060103@iprg.nokia.com> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 01 Jul 2004 03:53:01.0188 (UTC) FILETIME=[E7907C40:01C45F1E] Content-Transfer-Encoding: 7BIT Hi Vijay, Vijay Devarapalli wrote: > >>> >>> ... but with FMIPv6 we have still a problem: the "proxy" function is >>> concerning the Co@ (for the tunneling between the PAR and the NAR). >> >> >> >> Indeed. >> >> There is almost always going to be a problem >> in MIPv6 for existing Mobile Nodes which move off a home >> network and peers still have a valid neighbour cache >> entry. A Home agent won't be able to override NC entries with >> proxy advertisements if the override flag is unset in NAs. >> >> This isn't a direct problem with SEND though, since existing >> ND has this issue too. >> >> Of course, I've not waded through RFC3775 recently to >> see how proxy neighbour discovery is handled in this case >> (maybe Jari knows better). > > > as soon as a binding cache is created, the Home Agent sends a > gratuitous proxy neighbor advertisement. since this advertisement > is not solicited, the Override flag is set to 1. > > even for solicited proxy neighbor advertisement, the RFC 3775 > says Override flag MUST be set. (section 10.4.1) See what I could have learnt if I'd actually read the spec... I guess this is relying on 7.2.8 of 2461 too. (so there never really was a problem... sorry). It's not really very reliable in terms of SEND though (even if there was an authorization mechanism which allowed this), where unsolicited messages are matched with timestamps based on the advertisor's perception of time. The sudden change of advertisor could certainly cause headaches if this wasn't managed (or worked around), as otherwise the new advertisor's message could fall outside the fuzz and drift allowances. What I'd like to see would be some sort of authorization which could be signed by the address owner, which could be overridden by a later one (like a last will and testament) signed and timestamped by the same owner. This would authorize SEND nodes to receive a proxied solicited NA as an override, although they would defer to the original address owner if it returned to the link. (the O=0 flag would still be set for non-SEND nodes, to preserve existing function). I'd guess this could all be based on the owner's perception of time, although there may be problems if that changes suddenly. Certainly providing the router with authority to do this may be problematic when a device isn't on the link. In the MIPv6 case, it may be possible to exchange delegation chain messages over the home tunnel to ensure that the MN knows that the HA is authorized to be a router for the prefix. Also, the MN could sign the key of the router and send back a proxy certificate by a similar message. There may have to be a control plane request in the message sent back to the router which could request use of the address, and proxying. With MIPv6 this is already done if the proxy certificate is sent within a BU/BAck. Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html --------------------------------------------------------------------