From luo_Dobranski@sharpcode.de Mon Oct 01 00:33:21 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcCy9-0004MW-S3 for nemo-archive@lists.ietf.org; Mon, 01 Oct 2007 00:33:21 -0400 Received: from [85.97.128.59] (helo=dsl.static859712859.ttnet.net.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcCy6-0005mu-4u for nemo-archive@lists.ietf.org; Mon, 01 Oct 2007 00:33:18 -0400 Received: from gazi1 ([163.177.47.130] helo=gazi1) by dsl.static859712859.ttnet.net.tr ( sendmail 8.13.3/8.13.1) with esmtpa id 1rAFiD-000FMV-xU for nemo-archive@lists.ietf.org; Mon, 1 Oct 2007 07:32:18 +0300 Date: Mon, 1 Oct 2007 07:31:54 +0300 From: "luo Dobranski" Reply-To: "luo Dobranski" Message-ID: <090543433714.628537280086@sharpcode.de> To: Subject: shuppats MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-9"; reply-type=original X-Spam-Score: 4.0 (++++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Good day nemo-archive Alert to all investors! Look at D-M-X-C! 5-day price: ~$0.50 Check it at 31.09.2007 sgadanak shiget sheepher sgulfkcu From mext-bounces@ietf.org Mon Oct 01 04:27:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcGXM-0005Mc-8O; Mon, 01 Oct 2007 04:21:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcGXL-0005MX-Kh for mext@ietf.org; Mon, 01 Oct 2007 04:21:55 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcGXK-0003Ff-L6 for mext@ietf.org; Mon, 01 Oct 2007 04:21:55 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 644001986B9; Mon, 1 Oct 2007 11:21:53 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 04009198658; Mon, 1 Oct 2007 11:21:52 +0300 (EEST) Message-ID: <4700A05C.3070905@piuha.net> Date: Mon, 01 Oct 2007 10:23:08 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Jouni Korhonen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org Subject: [MEXT] AD review of draft-korhonen-mip6-service-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Jouni asked me to AD sponsor this document. Here's my review. I support the extension proposed in the document, but there are a number of issues relating to how these values are defaulted, tight coupling to MN-NAI, whether these options appear in the first or all messages, and a few other things. I expect a revised ID. I proposed text for some of the issues that below, in some cases you need to still work on it. Substantial: > o In absence of the Service Selection option the home agent may > provide, based on operator policies, a default service. For > example, a plain Internet access could be an operator's default > mobility service. > The fact that there is no standard "default" and the proliferation of various operator conventions and policies has caused significant problems in GPRS and UMTS data access. I would not like to repeat this mistake here. One of way of avoiding this problem is to mandate that you do have a default. Suggested edit: OLD: In absence of the Service Selection option the home agent may provide, based on operator policies, a default service. For example, a plain Internet access could be an operator's default mobility service. NEW: In absence of the Service Selection option the home agent MUST act as if the default service, plain Internet access had been requested. There is no absolute requirement that this default service be allowed to all customers, but it is highly RECOMMENDED in order to avoid having normal users employ operator-specific configuration values in order to get basic service. > The Service Selection option should be used in > combination with the Mobile Node Identifier option during the initial > Binding Update at the beginning of the mobility session. I do not see a reason to make this MNID specific. Also, the concept of a mobility session isn't necessarily well-defined, if home agents can reboot, etc. Reformulated: OLD: The Service Selection option should be used in combination with the Mobile Node Identifier option during the initial Binding Update at the beginning of the mobility session. NEW: The Service Selection option should be used in every Binding Update that makes a registration to the home agent. And then you should probably add text somewhere to talk about the case where the service id suddenly changes and this no longer fits with the home address allocation, etc. > The Service Selection mobility option can be included in any Mobile > IPv6 Mobility Header message. This is inconsistent with Section 2. I'm not sure I see a need for this option to appear in other messages than the BU. Please reformulate. > This option MAY be included in the initial Binding Update message > when registering to a home agent at the beginning of the mobility > session. The MN-NAI option SHOULD be included in the Binding Update > message when the Service Selection option is used. Sending the > Service Selection option in any Binding Update message is not > prohibited. See above for tight coupling to MN-NAI option or the initial BUs. > It should be noted that sending this option to > correspondent nodes makes little or no sense unless the home agent > and the correspondent nodes share the same knowledge of provided > mobility services. Be more specific. SHOULD NOT be sent? Presumably, depending on what kind of service you got, you will or will be able to reach the CNs directly. In either case, it should be OK to attempt RO. > o Identifier: A variable length service identifier string used to > identify the requested service. The Identifier string is encoded > as a host name or a fully qualified domain name as defined in [4] > and [5]. The Identifier MAY be resolveable by DNS. > > 'internet', 'internet.example.com', 'voip.example.com' and > 'voip.companyxyz.example.com' are valid examples of Service > Selection option Identifier strings. At minimum the Identifier > must be unique among the home agents the mobile node is authorized > to register to. > Something like "internet" would not be unique among the home agents, if I the mobile node is allowed to use two different operators, for instance. Are there existing APN conventions in GPRS networks that are based on domain names? Or are you inventing a convention here? Another alternative might be to just say "UTF-8" and that the value is up to a local policy. And unique within a particular home agent. > The Service > Selection option is intended to be used with the MN-NAI option, but > it is also possible to use Home Address to identify the mobile node > as defined in [1]. See above about the coupling to MN-NAI. Editorial: > Mobile IPv6 [1] has a Mobile Node Identifier option (MN-NAI) [6] that > provides a flexible way to identify mobile nodes using other > identifiers than IPv6 addresses. Example of such identifier is a > Network Access Identifier (NAI) [2]. There are multiple ways of identifying the mobile node, and the NAI is just one of them. Suggested rewrite: OLD: Mobile IPv6 [1] has a Mobile Node Identifier option (MN-NAI) [6] that provides a flexible way to identify mobile nodes using other identifiers than IPv6 addresses. Example of such identifier is a Network Access Identifier (NAI) [2]. NEW: Mobile IPv6 [1] can identify mobile nodes in various ways, including home addresses [1], Network Access Identifiers (NAIs) [2, 3], and credentials suitable for IKEv2 [RFC 4877]. > The service selection may affect home > agent routing decisions and Home Address or Home Network Prefix > assignment policies. Or firewall and security policies. Suggested edit: OLD: The service selection may affect home agent routing decisions and Home Address or Home Network Prefix assignment policies. NEW: The service selection may affect home agent routing decisions, Home Address or Home Network Prefix assignment policies, firewall settings, and security policies. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From nemo-bounces@ietf.org Mon Oct 01 05:00:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcH73-0003tz-Lx; Mon, 01 Oct 2007 04:58:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcH72-0003ts-F9 for nemo@ietf.org; Mon, 01 Oct 2007 04:58:48 -0400 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IcH72-0004f1-0j for nemo@ietf.org; Mon, 01 Oct 2007 04:58:48 -0400 Received: (qmail 12691 invoked for bounce); 1 Oct 2007 11:04:00 -0000 Received: from unknown (HELO ?130.79.91.222?) (kuntz@unknown) by unknown with RC4-SHA encrypted SMTP; 1 Oct 2007 11:04:00 -0000 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <2B67DA53-B8A1-4A63-968D-56C0FEC0C9A4@clarinet.u-strasbg.fr> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: nemo@ietf.org From: Romain KUNTZ Date: Mon, 1 Oct 2007 10:58:59 +0200 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [nemo] Prefix Delegation documents X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hello, I'm wondering what is the current status of the Prefix Delegation documents for NEMO: one seems to be still active and is referenced by the NEMO charter page (draft-ietf-nemo-prefix-delegation) but the other WG document (draft-ietf-nemo-dhcpv6-pd) does not appear anymore. Is it still supported by the WG? Regards, -- Romain KUNTZ kuntz@lsiit.u-strasbg.fr Louis Pasteur University - Networks and Protocols Team From nemo-bounces@ietf.org Mon Oct 01 05:39:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcHjQ-00026l-JR; Mon, 01 Oct 2007 05:38:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcHPW-0007jU-7r for nemo@ietf.org; Mon, 01 Oct 2007 05:17:54 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IcHPV-00058e-Tk for nemo@ietf.org; Mon, 01 Oct 2007 05:17:54 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1191230272!30222886!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 4756 invoked from network); 1 Oct 2007 09:17:52 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-14.tower-119.messagelabs.com with SMTP; 1 Oct 2007 09:17:52 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l919HltY026139; Mon, 1 Oct 2007 02:17:52 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l919HkaQ010209; Mon, 1 Oct 2007 04:17:47 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l919Hibs010149; Mon, 1 Oct 2007 04:17:45 -0500 (CDT) Message-ID: <4700BB35.4010402@gmail.com> Date: Mon, 01 Oct 2007 11:17:41 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Romain KUNTZ Subject: Re: [nemo] Prefix Delegation documents References: <2B67DA53-B8A1-4A63-968D-56C0FEC0C9A4@clarinet.u-strasbg.fr> In-Reply-To: <2B67DA53-B8A1-4A63-968D-56C0FEC0C9A4@clarinet.u-strasbg.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000777-4, 30/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Romain KUNTZ wrote: > Hello, > > I'm wondering what is the current status of the Prefix Delegation > documents for NEMO: one seems to be still active and is referenced by > the NEMO charter page (draft-ietf-nemo-prefix-delegation) but the > other WG document (draft-ietf-nemo-dhcpv6-pd) does not appear > anymore. Is it still supported by the WG? I would like to second the question, thanks for the replies. The work is mentioned in MEXT WG Charter "(B.3) Finish working group documents that are currently in process, and submit for RFC. This includes prefix delegation protocol mechanism for network mobility, and a MIB for NEMO Basic Support." (Personally, I've made up my mind. If until now I supported both, I think only the one doing DHCPv6 Prefix Delegation makes sense. The issue with the one doing prefix allocation with BU/BAck is that a similar thing is proposed in NETLMM WG: put ::/0 in PBU and receive prefix in PBAck. These two things (MNP in BAck and HNP in PBAck) are practically the same thing; but done with different encodings, with different assumptions and different technologies - an incoherency. DHCPv6-PD can do that and much more, more advanced architectures are supported, lifetimes, advanced configuration, and so on. BEsides, there are some implementations opensource.) Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From almarosa.mendez@kaballero.com Mon Oct 01 06:17:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcILC-0000U6-7f for nemo-archive@lists.ietf.org; Mon, 01 Oct 2007 06:17:30 -0400 Received: from 74-130-110-225.dhcp.insightbb.com ([74.130.110.225] helo=saugpk) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IcIL6-0004x7-2B for nemo-archive@lists.ietf.org; Mon, 01 Oct 2007 06:17:25 -0400 Received: from javjt ([228.146.178.121]) by saugpk (8.13.4/8.13.4) with SMTP id l91AK2Ta072286; Mon, 1 Oct 2007 06:20:02 -0400 Message-ID: <4700C972.6070102@kaballero.com> Date: Mon, 1 Oct 2007 06:18:26 -0400 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: Sailor or not, this yacht is hot Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.9 (++++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Production Facility Nearly Maxed As New Porsche Designed Yacht Hits Market Fearless International Inc. FRLE Current: $0.32 "Fearless 28" is became every discerning captains dream boat, as it made waves at the Miami Boat Show this year. Orders are already pouring in and have nearly maxed there production line. It has been raved about as a must have item by magazines like "Simply The Best", "Details", "GQ" and D'Luxe. Check out the video and all the media coverage on the fearlessyachts website. Monday morning this should be the first buy you make. It will be one of the biggest movers of the year. From mext-bounces@ietf.org Mon Oct 01 13:12:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcOm7-00085v-VL; Mon, 01 Oct 2007 13:09:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcOm6-000828-Dq for mext@ietf.org; Mon, 01 Oct 2007 13:09:42 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcOm6-0007vd-1G for mext@ietf.org; Mon, 01 Oct 2007 13:09:42 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Oct 2007 10:09:41 -0700 Message-ID: <470129D4.8090403@azairenet.com> Date: Mon, 01 Oct 2007 10:09:40 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [MEXT] AD review of draft-korhonen-mip6-service-03.txt References: <4700A05C.3070905@piuha.net> In-Reply-To: <4700A05C.3070905@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Oct 2007 17:09:41.0325 (UTC) FILETIME=[DAFFCFD0:01C8044D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Jari, A couple of comments. Jari Arkko wrote: >> o In absence of the Service Selection option the home agent may >> provide, based on operator policies, a default service. For >> example, a plain Internet access could be an operator's default >> mobility service. >> > > The fact that there is no standard "default" and the proliferation > of various operator conventions and policies has caused significant > problems in GPRS and UMTS data access. I would not like to repeat > this mistake here. > > One of way of avoiding this problem is to mandate that you do > have a default. Suggested edit: > > OLD: > In absence of the Service Selection option the home agent may > provide, based on operator policies, a default service. For > example, a plain Internet access could be an operator's default > mobility service. > NEW: > In absence of the Service Selection option the home agent MUST > act as if the default service, plain Internet access had been > requested. There is no absolute requirement that this default service be > allowed to all customers, but it is highly RECOMMENDED in > order to avoid having normal users employ operator-specific > configuration values in order to get basic service. This is a good idea. Completely agree. >> The Service Selection mobility option can be included in any Mobile >> IPv6 Mobility Header message. > This is inconsistent with Section 2. I'm not sure I see a need > for this option to appear in other messages than the BU. > Please reformulate. We should probably not say anything here. There is no need to restrict it to the Binding Update and at the same time no need to claim that it can be used in any mobility header message. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From nemo-bounces@ietf.org Mon Oct 01 16:53:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcSGS-0007xV-U4; Mon, 01 Oct 2007 16:53:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcSGR-0007xB-UV for nemo@ietf.org; Mon, 01 Oct 2007 16:53:15 -0400 Received: from web84112.mail.mud.yahoo.com ([68.142.206.199]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IcSGM-0003Ms-CE for nemo@ietf.org; Mon, 01 Oct 2007 16:53:15 -0400 Received: (qmail 10847 invoked by uid 60001); 1 Oct 2007 20:52:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=fOe6Vak6LuCHnGtqDJ2reo0mu08A3Yr9rleuMavIQ5H+0yupH05//OYEf9wSFQyob9cRPPx+DzD+1a4Q9yII+oKR1obyfvxqSVyaOR10r2//Xj8kkgr0wap6NvozXkQ1sxzKrZX8NNIW7cHbbc/A7EKfuPwRvRbLZKu9nz3NkY0=; X-YMail-OSG: e5ayK5MVM1l..EexIqYVHUbMTMUOej_Jk3.Ty.DzvX94ToEpauDEcypoLZHo9x_iTHhmq._8tGiHQBAiRaJO_6MlKSSeh8_w4pZIg8mk.uQODoZWX6h_.53D3w-- Received: from [206.16.17.212] by web84112.mail.mud.yahoo.com via HTTP; Mon, 01 Oct 2007 13:52:52 PDT X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134 Date: Mon, 1 Oct 2007 13:52:52 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [nemo] Prefix Delegation documents To: Alexandru Petrescu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1443389722-1191271972=:10786" Message-ID: <483735.10786.qm@web84112.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org --0-1443389722-1191271972=:10786 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I agree with Alex. DHAAD extension proposed in NEMO DHCP PD draft is I thin= k a stretch and may probably be not needed.=0A=0ARegards,=0A=0ABehcet=0A=0A= ----- Original Message ----=0AFrom: Alexandru Petrescu =0ATo: Romain KUNTZ =0ACc: nemo@ietf= .org=0ASent: Monday, October 1, 2007 4:17:41 AM=0ASubject: Re: [nemo] Prefi= x Delegation documents=0A=0ARomain KUNTZ wrote:=0A> Hello,=0A> =0A> I'm won= dering what is the current status of the Prefix Delegation =0A> documents f= or NEMO: one seems to be still active and is referenced by=0A> the NEMO ch= arter page (draft-ietf-nemo-prefix-delegation) but the =0A> other WG docume= nt (draft-ietf-nemo-dhcpv6-pd) does not appear =0A> anymore. Is it still su= pported by the WG?=0A=0AI would like to second the question, thanks for the= replies.=0A=0AThe work is mentioned in MEXT WG Charter "(B.3) Finish worki= ng group=0Adocuments that are currently in process, and submit for RFC. Thi= s=0Aincludes prefix delegation protocol mechanism for network mobility, and= =0Aa MIB for NEMO Basic Support."=0A=0A(Personally, I've made up my mind. = If until now I supported both, I=0Athink only the one doing DHCPv6 Prefix D= elegation makes sense.=0A=0AThe issue with the one doing prefix allocation = with BU/BAck is that a=0Asimilar thing is proposed in NETLMM WG: put ::/0 i= n PBU and receive=0Aprefix in PBAck.=0A=0AThese two things (MNP in BAck and= HNP in PBAck) are practically the same=0Athing; but done with different en= codings, with different assumptions and=0A different technologies - an inc= oherency.=0A=0ADHCPv6-PD can do that and much more, more advanced architect= ures are=0Asupported, lifetimes, advanced configuration, and so on. BEside= s, there=0Aare some implementations opensource.)=0A=0AAlex=0A=0A___________= ___________________________________________________________=0AThis email ha= s been scanned by the MessageLabs Email Security System.=0AFor more informa= tion please visit http://www.messagelabs.com/email =0A_____________________= _________________________________________________=0A=0A=0A=0A=0A=0A --0-1443389722-1191271972=:10786 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
I agree with Alex. DHAAD extension proposed in NEMO DH= CP PD draft is I think a stretch and may probably be not needed.

Reg= ards,

Behcet

----- Original Message ----
From: Ale= xandru Petrescu <alexandru.petrescu@gmail.com>
To: Romain KUNTZ &l= t;kuntz@clarinet.u-strasbg.fr>
Cc: nemo@ietf.org
Sent: Monday, Oct= ober 1, 2007 4:17:41 AM
Subject: Re: [nemo] Prefix Delegation documents<= br>
Romain KUNTZ wrote:
> Hello,
>
> I'm wonderi= ng what is the current status of the Prefix Delegation
> documents f= or NEMO: one seems to be still active and is referenced by
>  the NEMO charter page (draft-ietf-nemo-prefix-delega= tion) but the
> other WG document (draft-ietf-nemo-dhcpv6-pd) does n= ot appear
> anymore. Is it still supported by the WG?

I would= like to second the question, thanks for the replies.

The work is me= ntioned in MEXT WG Charter "(B.3) Finish working group
documents that ar= e currently in process, and submit for RFC. This
includes prefix delegat= ion protocol mechanism for network mobility, and
a MIB for NEMO Basic Su= pport."

(Personally, I've made up my mind.  If until now I= supported both, I
think only the one doing DHCPv6 Prefix Delegation mak= es sense.

The issue with the one doing prefix allocation with BU/BAc= k is that a
similar thing is proposed in NETLMM WG: put ::/0 in PBU and = receive
prefix in PBAck.

These two things (MNP in BAck and HNP in= PBAck) are practically the same
thing; but done with different encodings, with different assumptions and
  different technol= ogies - an incoherency.

DHCPv6-PD can do that and much more, more ad= vanced architectures are
supported, lifetimes, advanced configuration, a= nd so on.  BEsides, there
are some implementations opensource.= )

Alex

______________________________________________________= ________________
This email has been scanned by the MessageLabs Email Se= curity System.
For more information please visit http://www.messagelabs.com/email
_____________________________________________________________________= _


--0-1443389722-1191271972=:10786-- From mext-bounces@ietf.org Mon Oct 01 16:53:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcSCm-00057a-Bl; Mon, 01 Oct 2007 16:49:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcSCl-000579-2d for mext@ietf.org; Mon, 01 Oct 2007 16:49:27 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcSCk-0005Q5-Nj for mext@ietf.org; Mon, 01 Oct 2007 16:49:26 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1887E198677; Mon, 1 Oct 2007 23:49:26 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id ACD91198646; Mon, 1 Oct 2007 23:49:25 +0300 (EEST) Message-ID: <47015D55.1050602@piuha.net> Date: Mon, 01 Oct 2007 23:49:25 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [MEXT] AD review of draft-korhonen-mip6-service-03.txt References: <4700A05C.3070905@piuha.net> <470129D4.8090403@azairenet.com> In-Reply-To: <470129D4.8090403@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Vijay, >> This is inconsistent with Section 2. I'm not sure I see a need >> for this option to appear in other messages than the BU. >> Please reformulate. > > We should probably not say anything here. There is no need to restrict > it to the Binding Update and at the same time no need to claim that it > can be used in any mobility header message. I think you need to define what the behaviour should be when you receive this. I'm not sure its obvious. What should you do if you receive this in a BA or BE, for instance? Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From nemo-bounces@ietf.org Mon Oct 01 17:34:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcSuN-0001Xr-9o; Mon, 01 Oct 2007 17:34:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcSuL-0001V9-V8 for nemo@ietf.org; Mon, 01 Oct 2007 17:34:29 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IcSuG-0004CL-Q9 for nemo@ietf.org; Mon, 01 Oct 2007 17:34:29 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1191274454!23825247!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 26110 invoked from network); 1 Oct 2007 21:34:14 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-119.messagelabs.com with SMTP; 1 Oct 2007 21:34:14 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l91LY8hj018290; Mon, 1 Oct 2007 14:34:13 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l91LY85L003973; Mon, 1 Oct 2007 16:34:08 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-169-4-81.corp.mot.com [10.169.4.81]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l91LY5ue003961; Mon, 1 Oct 2007 16:34:06 -0500 (CDT) Message-ID: <470167CD.8020601@gmail.com> Date: Mon, 01 Oct 2007 23:34:05 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Behcet Sarikaya Subject: Re: [nemo] Prefix Delegation documents References: <483735.10786.qm@web84112.mail.mud.yahoo.com> In-Reply-To: <483735.10786.qm@web84112.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000778-0, 01/10/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Behcet Sarikaya wrote: > I agree with Alex. DHAAD extension proposed in NEMO DHCP PD draft is I > think a stretch and may probably be not needed. Err? Sorry, I'm happy you agree with me, but I think the NEMO DHCP PD draft doesn't propose DHAAD extensions...(?) draft-ietf-nemo-prefix-delegation-02.txt proposes exensions to PBU/PBAck to request and receive a prefix. The NEMODHCP PD draft that I've seen last time (Ralph+Pascal) and whose draft name I can't find doesn't propose DHAAD extensions either, it just pictures the roles of MR and of HA as Requestor and Delegator, (IIRC terminology), normal DHCP PD roles. It didn't define new message formats/flags, IIRC. Alex > > Regards, > > Behcet > > ----- Original Message ---- > From: Alexandru Petrescu > To: Romain KUNTZ > Cc: nemo@ietf.org > Sent: Monday, October 1, 2007 4:17:41 AM > Subject: Re: [nemo] Prefix Delegation documents > > Romain KUNTZ wrote: > > Hello, > > > > I'm wondering what is the current status of the Prefix Delegation > > documents for NEMO: one seems to be still active and is referenced by > > the NEMO charter page (draft-ietf-nemo-prefix-delegation) but the > > other WG document (draft-ietf-nemo-dhcpv6-pd) does not appear > > anymore. Is it still supported by the WG? > > I would like to second the question, thanks for the replies. > > The work is mentioned in MEXT WG Charter "(B.3) Finish working group > documents that are currently in process, and submit for RFC. This > includes prefix delegation protocol mechanism for network mobility, and > a MIB for NEMO Basic Support." > > (Personally, I've made up my mind. If until now I supported both, I > think only the one doing DHCPv6 Prefix Delegation makes sense. > > The issue with the one doing prefix allocation with BU/BAck is that a > similar thing is proposed in NETLMM WG: put ::/0 in PBU and receive > prefix in PBAck. > > These two things (MNP in BAck and HNP in PBAck) are practically the same > thing; but done with different encodings, with different assumptions and > different technologies - an incoherency. > > DHCPv6-PD can do that and much more, more advanced architectures are > supported, lifetimes, advanced configuration, and so on. BEsides, there > are some implementations opensource.) > > Alex > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From nemo-bounces@ietf.org Mon Oct 01 17:59:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcTH8-0002x8-T0; Mon, 01 Oct 2007 17:58:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcTH7-0002pa-Uc for nemo@ietf.org; Mon, 01 Oct 2007 17:58:01 -0400 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IcTH7-0006i7-B5 for nemo@ietf.org; Mon, 01 Oct 2007 17:58:01 -0400 Received: (qmail 22202 invoked for bounce); 2 Oct 2007 00:03:13 -0000 Received: from unknown (HELO ?192.168.1.3?) (kuntz@unknown) by unknown with RC4-SHA encrypted SMTP; 2 Oct 2007 00:03:13 -0000 In-Reply-To: <470167CD.8020601@gmail.com> References: <483735.10786.qm@web84112.mail.mud.yahoo.com> <470167CD.8020601@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr> Content-Transfer-Encoding: 7bit From: Romain KUNTZ Subject: Re: [nemo] Prefix Delegation documents Date: Mon, 1 Oct 2007 23:58:12 +0200 To: Alexandru Petrescu X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Alex, On 2007/10/01, at 23:34, Alexandru Petrescu wrote: > Behcet Sarikaya wrote: >> I agree with Alex. DHAAD extension proposed in NEMO DHCP PD draft >> is I think a stretch and may probably be not needed. > > Err? Sorry, I'm happy you agree with me, but I think the NEMO DHCP > PD draft doesn't propose DHAAD extensions...(?) draft-ietf-nemo-dhcpv6-pd-02 adds a new D flag to DHAAD in section 3.5. And I agree with Behcet that this may not be useful, as the MIP6 bootstrapping work does not rely on DHAAD to assign HA addresses. It could be interesting to integrate this work better in the MIP6 bootstrapping effort. Romain >> ----- Original Message ---- >> From: Alexandru Petrescu >> To: Romain KUNTZ >> Cc: nemo@ietf.org >> Sent: Monday, October 1, 2007 4:17:41 AM >> Subject: Re: [nemo] Prefix Delegation documents >> Romain KUNTZ wrote: >> > Hello, >> > >> > I'm wondering what is the current status of the Prefix Delegation >> > documents for NEMO: one seems to be still active and is >> referenced by >> > the NEMO charter page (draft-ietf-nemo-prefix-delegation) but the >> > other WG document (draft-ietf-nemo-dhcpv6-pd) does not appear >> > anymore. Is it still supported by the WG? >> I would like to second the question, thanks for the replies. >> The work is mentioned in MEXT WG Charter "(B.3) Finish working group >> documents that are currently in process, and submit for RFC. This >> includes prefix delegation protocol mechanism for network >> mobility, and >> a MIB for NEMO Basic Support." >> (Personally, I've made up my mind. If until now I supported both, I >> think only the one doing DHCPv6 Prefix Delegation makes sense. >> The issue with the one doing prefix allocation with BU/BAck is that a >> similar thing is proposed in NETLMM WG: put ::/0 in PBU and receive >> prefix in PBAck. >> These two things (MNP in BAck and HNP in PBAck) are practically >> the same >> thing; but done with different encodings, with different >> assumptions and >> different technologies - an incoherency. >> DHCPv6-PD can do that and much more, more advanced architectures are >> supported, lifetimes, advanced configuration, and so on. BEsides, >> there >> are some implementations opensource.) >> Alex >> _____________________________________________________________________ >> _ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> _____________________________________________________________________ >> _ > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > From zozo510@au.atlascopco.com Mon Oct 01 23:51:54 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcYna-00052L-ES for nemo-archive@lists.ietf.org; Mon, 01 Oct 2007 23:51:54 -0400 Received: from [82.201.235.160] (helo=host-82-201-235-160.static.link.com.eg) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IcYmo-0003Vf-I4 for nemo-archive@lists.ietf.org; Mon, 01 Oct 2007 23:51:54 -0400 Received: from xch ([82.170.196.105]) by host-82-201-235-160.static.link.com.eg (8.13.2/8.13.2) with SMTP id l923soTH038691; Tue, 2 Oct 2007 05:54:50 +0200 Message-ID: <4701BFDF.1040601@au.atlascopco.com> Date: Tue, 2 Oct 2007 05:49:51 +0200 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: Do not trash this Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.5 (+++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Heavy Trading Begins On FRLE As New Designs Hit Street Fearless International Inc. FRLE Price: $0.20 Big movements on this today combined with rollercoaster prices is brewing a huge move on FRLE this week. The coverage on this company is brewing huge potential for investors. This is just getting geared up, we expect to see this get bigger as the week goes on. You only get a few deals like this in a year, move now and get on FRLE. From hahahal@DHSMDLLC.com Tue Oct 02 01:52:28 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcagG-0008LI-KT for nemo-archive@lists.ietf.org; Tue, 02 Oct 2007 01:52:28 -0400 Received: from host212-191-dynamic.2-87-r.retail.telecomitalia.it ([87.2.191.212]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Icafj-000080-0L for nemo-archive@lists.ietf.org; Tue, 02 Oct 2007 01:51:55 -0400 Received: from 47e2857709c44c3 by DHSMDLLC.com with ASMTP id 325EF9A1 for ; Tue, 2 Oct 2007 07:52:17 +0200 Received: from 47e2857709c44c3 ([126.169.17.18]) by DHSMDLLC.com with ESMTP id FF7B96728288 for ; Tue, 2 Oct 2007 07:52:17 +0200 Message-ID: <000e01c804b8$52df7950$d4bf0257@47e2857709c44c3> From: "hahaha l" To: Subject: gnivom-t Date: Tue, 2 Oct 2007 07:51:49 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C804C9.16684950" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Antivirus: avast! (VPS 000778-0, 01/10/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 3.2 (+++) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a ------=_NextPart_000_0005_01C804C9.16684950 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable CWTE: C'Watre International, Inc Trade Alert. CWTE just announced trading on the OTC. CWTE has the = potential to return 5 times your money with this tight capital = structure. This means the stock can see $1.50 when news is realesed. CWTE has a = womens line of ageless cosmetics that is overwhelming the celebrity industry. Keep an eye for news to hit the market and create a frenzy in = this stock. When investors find out who's using it, the stock could go well beyond our target. nemo-archive, contact your broker NOW for CWTE! gniziuh gn}l gnitceje gnufpmi gnitsevn gnivres- ------=_NextPart_000_0005_01C804C9.16684950 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
CWTE: C'Watre International, Inc
Trade Alert. CWTE just announced trading on = the OTC. C WTE has the potential to return 5 times your money with this tight = capital structure.
This means the stock can see $1.50 when news = is=20 realesed. CWTE has a womens line of ageless cosmetics that is = overwhelming the celebrity
industry. Keep an eye for news to hit the = market and=20 create a frenzy in this stock. When investors find out who's using it, = the=20 stock could
go well beyond our target.
nemo-archive, contact your broker NOW for = CWTE!
gniziuh
gn}l
gnitceje
gnufpmi
gnitsevn
gnivres-
------=_NextPart_000_0005_01C804C9.16684950-- From EverettKraemer@omituto.com Tue Oct 02 02:32:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcbJG-0001OB-Ia for nemo-archive@lists.ietf.org; Tue, 02 Oct 2007 02:32:46 -0400 Received: from athedsl-286316.home.otenet.gr ([85.73.166.10] helo=[85.75.55.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcbJA-00073e-3p for nemo-archive@lists.ietf.org; Tue, 02 Oct 2007 02:32:41 -0400 Received: from ALTEC1 ([185.175.91.14]:7105 "EHLO ALTEC1" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [85.75.55.85] with ESMTP id S22AZXNMRYGGHNKX (ORCPT ); Tue, 2 Oct 2007 09:32:55 +0300 Message-ID: Date: Tue, 2 Oct 2007 09:32:34 +0300 From: "Everett Kraemer" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: edigiss{ Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 CWTE: C'Watre International, Inc Trade Alert. CWTE just announced trading on the OTC. CWTE has the potential to return 5 times your money with this tight capital structure. This means the stock can see $1.50 when news is realesed. CWTE has a womens line of ageless cosmetics that is overwhelming the celebrity industry. Keep an eye for news to hit the market and create a frenzy in this stock. When investors find out who's using it, the stock could go well beyond our target. nemo-archive, contact your broker NOW for CWTE! edartsel edilyhte edemrofm ecnaledr edisgnar ecorce From mext-bounces@ietf.org Tue Oct 02 04:20:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IccvI-0005rF-61; Tue, 02 Oct 2007 04:16:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IccvH-0005kD-5S for mext@ietf.org; Tue, 02 Oct 2007 04:16:07 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iccv6-0001Iz-8K for mext@ietf.org; Tue, 02 Oct 2007 04:16:07 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Oct 2007 10:15:41 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Oct 2007 10:15:40 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222D260@SEHAN021MB.tcad.telia.se> In-Reply-To: <4700A05C.3070905@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-korhonen-mip6-service-03.txt Thread-Index: AcgEBCFn7W9wurwISgKpm9fN88A1ZgAvuKnQ References: <4700A05C.3070905@piuha.net> From: To: X-OriginalArrivalTime: 02 Oct 2007 08:15:41.0330 (UTC) FILETIME=[6C164F20:01C804CC] X-Spam-Score: -4.0 (----) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org Subject: [MEXT] RE: AD review of draft-korhonen-mip6-service-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Jari, Thanks for the extensive review. Some comments inline. > Sent: Monday, October 01, 2007 10:23 AM >=20 > Jouni asked me to AD sponsor this document. Here's my review. >=20 > I support the extension proposed in the document, but there=20 > are a number of issues relating to how these values are=20 > defaulted, tight coupling to MN-NAI, whether these options=20 > appear in the first or all messages, and a few other things. >=20 > I expect a revised ID. I proposed text for some of the issues=20 > that below, in some cases you need to still work on it. >=20 > Substantial: >=20 > > o In absence of the Service Selection option the home agent may > > provide, based on operator policies, a default service. For > > example, a plain Internet access could be an=20 > operator's default > > mobility service. > > =20 >=20 > The fact that there is no standard "default" and the=20 > proliferation of various operator conventions and policies=20 > has caused significant problems in GPRS and UMTS data access.=20 > I would not like to repeat this mistake here. Agree on this. This actually has given headache in several occasions e.g. in our services deployments. Dunno how we managed to repeat it in this I-D in the first place... > One of way of avoiding this problem is to mandate that you do=20 > have a default. Suggested edit: >=20 > OLD: > In absence of the Service Selection option the home agent may=20 > provide, based on operator policies, a default service. For=20 > example, a plain Internet access could be an operator's=20 > default mobility service. > NEW: > In absence of the Service Selection option the home agent=20 > MUST act as if the default service, plain Internet access had=20 > been requested. There is no absolute requirement that this=20 > default service be allowed to all customers, but it is highly=20 > RECOMMENDED in order to avoid having normal users employ=20 > operator-specific configuration values in order to get basic service. OK by me. > > The Service Selection option should be used in > > combination with the Mobile Node Identifier option=20 > during the initial > > Binding Update at the beginning of the mobility session. > I do not see a reason to make this MNID specific. Also, the=20 > concept of a mobility session isn't necessarily well-defined,=20 > if home agents can reboot, etc. Reformulated: Hmmm.. right. "should" is not exactly mandating the use of MNID. Agree on the mobility session ambiguity. > OLD: > The Service Selection option should be used in combination=20 > with the Mobile Node Identifier option during the initial=20 > Binding Update at the beginning of the mobility session. > NEW: > The Service Selection option should be used in every Binding=20 > Update that makes a registration to the home agent. OK. > And then you should probably add text somewhere to talk about=20 > the case where the service id suddenly changes and this no=20 > longer fits with the home address allocation, etc. Good point. I actually had some thoughts to write a bit about this scenario. My initial thinking was that if the service id changes mid session and the HA cannot agree with the new service, the HA would reject the binding and send back a BA with an error code indicating the administrative decision. > > The Service Selection mobility option can be included in=20 > any Mobile > > IPv6 Mobility Header message.=20 > This is inconsistent with Section 2. I'm not sure I see a=20 > need for this option to appear in other messages than the BU. > Please reformulate. Right. Agree. > > This option MAY be included in the initial Binding Update message > > when registering to a home agent at the beginning of the mobility > > session. The MN-NAI option SHOULD be included in the=20 > Binding Update > > message when the Service Selection option is used. Sending the > > Service Selection option in any Binding Update message is not > > prohibited.=20 >=20 > See above for tight coupling to MN-NAI option or the initial BUs. Ack. > > It should be noted that sending this option to > > correspondent nodes makes little or no sense unless the=20 > home agent > > and the correspondent nodes share the same knowledge of provided > > mobility services. > Be more specific. SHOULD NOT be sent? Presumably, depending=20 > on what kind of service you got, you will or will be able to=20 > reach the CNs directly. In either case, it should be OK to attempt RO. Yes, attempting RO should be ok in all cases. I should probably only say here: The service selection option SHOULD NOT be send to a correspondent node. The mobile node cannot assume that the correspondent node has any knowledge about a specific service selection done between the mobile node and the home agent. > > o Identifier: A variable length service identifier=20 > string used to > > identify the requested service. The Identifier=20 > string is encoded > > as a host name or a fully qualified domain name as=20 > defined in [4] > > and [5]. The Identifier MAY be resolveable by DNS. > > > > 'internet', 'internet.example.com', 'voip.example.com' and > > 'voip.companyxyz.example.com' are valid examples of Service > > Selection option Identifier strings. At minimum the=20 > Identifier > > must be unique among the home agents the mobile node=20 > is authorized > > to register to. > > =20 >=20 > Something like "internet" would not be unique among the home=20 > agents, if I the mobile node is allowed to use two different=20 > operators, for instance. IMHO that falls to roaming contract arrangement part and in that case something like "internet" can definitely be agreed on to be unique among operators the mobile node is allowed to roam with. Bad choice of example, I can change that. > Are there existing APN conventions in GPRS networks that are=20 > based on domain names? Or are you inventing a convention here? APNs are have two parts: the Netword Identified (NI) and the Operator Identifier (OI). The NI is mandatory e.g. plain "voip" in the above example and the optional OI is the domain name e.g. "example.com". Of cource GPRS APN domain name convention are more akward than in the above example. So no inventing a convention here. =20 > Another alternative might be to just say "UTF-8" and that the=20 > value is up to a local policy. And unique within a particular=20 > home agent. Hmmm.. could be ok. Need to think about this. > > The Service > > Selection option is intended to be used with the MN-NAI=20 > option, but > > it is also possible to use Home Address to identify the=20 > mobile node > > as defined in [1]. > See above about the coupling to MN-NAI. Ack. > Editorial: >=20 > > Mobile IPv6 [1] has a Mobile Node Identifier option=20 > (MN-NAI) [6] that > > provides a flexible way to identify mobile nodes using other > > identifiers than IPv6 addresses. Example of such identifier is a > > Network Access Identifier (NAI) [2]. > There are multiple ways of identifying the mobile node, and=20 > the NAI is just one of them. Suggested rewrite: >=20 > OLD: > Mobile IPv6 [1] has a Mobile Node Identifier option (MN-NAI)=20 > [6] that provides a flexible way to identify mobile nodes=20 > using other identifiers than IPv6 addresses. Example of such=20 > identifier is a Network Access Identifier (NAI) [2]. > NEW: > Mobile IPv6 [1] can identify mobile nodes in various ways,=20 > including home addresses [1], Network Access Identifiers=20 > (NAIs) [2, 3], and credentials suitable for IKEv2 [RFC 4877]. Good. Thanks. > > The service selection may affect home > > agent routing decisions and Home Address or Home Network Prefix > > assignment policies.=20 > Or firewall and security policies. Suggested edit: >=20 > OLD: > The service selection may affect home > agent routing decisions and Home Address or Home Network=20 > Prefix assignment policies. > NEW: > The service selection may affect home > agent routing decisions, Home Address or Home Network Prefix=20 > assignment policies, firewall settings, and security policies. OK. Thanks, Cheers, Jouni >=20 > Jari >=20 >=20 >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Oct 02 05:35:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ice7d-0000IH-M4; Tue, 02 Oct 2007 05:32:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ice7c-0000IC-FV for mext@ietf.org; Tue, 02 Oct 2007 05:32:56 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ice7b-0005qX-Tr for mext@ietf.org; Tue, 02 Oct 2007 05:32:56 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CBBE3198677; Tue, 2 Oct 2007 12:32:54 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9675D198670; Tue, 2 Oct 2007 12:32:54 +0300 (EEST) Message-ID: <47021046.1070100@piuha.net> Date: Tue, 02 Oct 2007 12:32:54 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com References: <4700A05C.3070905@piuha.net> <59D7431DE2527D4CB0F1EFEDA5683ED30222D260@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED30222D260@SEHAN021MB.tcad.telia.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org Subject: [MEXT] Re: AD review of draft-korhonen-mip6-service-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org > Good point. I actually had some thoughts to write a bit about this > scenario. My initial thinking was that if the service id changes mid > session and the HA cannot agree with the new service, the HA > would reject the binding and send back a BA with an error code > indicating the administrative decision. > This is fine. > Yes, attempting RO should be ok in all cases. I should probably > only say here: > > The service selection option SHOULD NOT be send to a correspondent > node. The mobile node cannot assume that the correspondent node > has any knowledge about a specific service selection done between > the mobile node and the home agent. > Ok. >> Something like "internet" would not be unique among the home >> agents, if I the mobile node is allowed to use two different >> operators, for instance. >> > > IMHO that falls to roaming contract arrangement part and in that > case something like "internet" can definitely be agreed on to > be unique among operators the mobile node is allowed to roam > with. Bad choice of example, I can change that. > > >> Are there existing APN conventions in GPRS networks that are >> based on domain names? Or are you inventing a convention here? >> > > APNs are have two parts: the Netword Identified (NI) and the Operator > Identifier (OI). The NI is mandatory e.g. plain "voip" in the above > example and the optional OI is the domain name e.g. "example.com". > Of cource GPRS APN domain name convention are more akward than in > the above example. So no inventing a convention here. > > >> Another alternative might be to just say "UTF-8" and that the >> value is up to a local policy. And unique within a particular >> home agent. >> > > Hmmm.. could be ok. Need to think about this. > It is still unclear to me what the best choice is. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From service@usra.org Tue Oct 02 09:04:39 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IchQV-0002we-QO for nemo-archive@lists.ietf.org; Tue, 02 Oct 2007 09:04:39 -0400 Received: from a100-98.adsl.paltel.net ([213.6.100.98]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IchQO-0000qz-U2 for nemo-archive@lists.ietf.org; Tue, 02 Oct 2007 09:04:39 -0400 Received: (qmail 19374 invoked from network); Tue, 2 Oct 2007 15:04:16 +0200 Received: from unknown (HELO yljs) (66.87.171.158) by a100-98.adsl.paltel.net with SMTP; Tue, 2 Oct 2007 15:04:16 +0200 Message-ID: <470241D0.2050603@usra.org> Date: Tue, 2 Oct 2007 15:04:16 +0200 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: What do they know that you don.t? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.4 (++++) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Brokers Push Prices Down And Grab Shares In Heavy Trading Day Fearless International F R L E Price: $0.20 Rumors of an investor frenzy has brokers grabbing shares and pushing prices down for maximum return. The whole world is keeping there eye on this one. This is only the beginning; this one is going out of the park. You only get a few deals like this in a year, move now and get on FRLE. From dsanchez@megavalve.com.sg Tue Oct 02 16:59:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icops-0000AW-1J for nemo-archive@lists.ietf.org; Tue, 02 Oct 2007 16:59:20 -0400 Received: from [211.178.192.251] (helo=wjte) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Icopm-0005qM-Aa for nemo-archive@lists.ietf.org; Tue, 02 Oct 2007 16:59:16 -0400 Received: (qmail 23896 invoked from network); Wed, 3 Oct 2007 05:58:50 +0900 Received: from unknown (HELO dhhqn) (222.112.160.106) by wjte with SMTP; Wed, 3 Oct 2007 05:58:50 +0900 Message-ID: <4702B10A.7000800@megavalve.com.sg> Date: Wed, 3 Oct 2007 05:58:50 +0900 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: Move Move Move Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.7 (+) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Consumers Get First Look At Fearless 28's Bigger Brother The 44 Fearless International Inc. FRLE.OB Price: $0.20 Our job is to alert you to the big ones, this has all the makings, hot product, huge media coverage, and now volume is moving. Don't take your eye off this for the next few days. Today's heavy trading is only the beginning. We can not stress how crucial timing is on this, grab it fast. From ligunahvya@longspeakacademy.com Tue Oct 02 17:36:05 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcpPR-0001jo-NO for nemo-archive@lists.ietf.org; Tue, 02 Oct 2007 17:36:05 -0400 Received: from host9-49-dynamic.53-82-r.retail.telecomitalia.it ([82.53.49.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcpPK-0001Kz-W0 for nemo-archive@lists.ietf.org; Tue, 02 Oct 2007 17:35:59 -0400 Received: from utente-e89ee680 by longspeakacademy.com with ASMTP id C51A25C9 for ; Tue, 2 Oct 2007 23:36:29 +0200 Received: from utente-e89ee680 ([190.185.135.44]) by longspeakacademy.com with ESMTP id 93D859E29061 for ; Tue, 2 Oct 2007 23:36:29 +0200 Message-ID: <000401c8053c$3ae34a50$09313552@utentee89ee680> From: "Jerran liguna" To: Subject: kviting Date: Tue, 2 Oct 2007 23:36:02 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C8054C.FE6C1A50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.5 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0009_01C8054C.FE6C1A50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.couliormag.com/ Nice to meet you nemo-archive See my penis pictures as proof Jerran liguna ------=_NextPart_000_0009_01C8054C.FE6C1A50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Nice to meet you nemo-archive
See my penis pictures as proof
Jerran liguna
------=_NextPart_000_0009_01C8054C.FE6C1A50-- From Staceysightneuroanotomy@gobritney.com Tue Oct 02 22:48:18 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcuHa-0003C5-Tu for nemo-archive@lists.ietf.org; Tue, 02 Oct 2007 22:48:18 -0400 Received: from [89.211.81.29] (helo=user626ec5a477) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IcuHZ-0004ga-JX for nemo-archive@lists.ietf.org; Tue, 02 Oct 2007 22:48:18 -0400 Received: from thresh by gobritney.com with SMTP id 6moJc2LZjA for ; Tue, 2 Oct 2007 17:48:38 +0800 From: "Ty Sweeney" To: Subject: Fwd: Thank you, we are ready to give you a loan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 4.9 (++++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Finding rates low enough to suit is never an easy task. What if I were to tell you that there actually is a simple way to find the a lower rate for you? What if I told you that the rates were lower than any other one out there? You would of course be doubtful of what I said, but why not check for yourself? http://contriculation.com/ Lenders should be offering you the best deals and not make you search for them. Stop fighting for lenders let them fight for you! Make them work for your business by giving you the lowest rates around! If you want a lower interest rate,and peace of mind then.. http://contriculation.com/ Bad credit seems to be a major deterrent for lenders these days but again, what if there was somewhere out there who didn't care for your credit status? Low credit rating? No problem. http://contriculation.com/ Wiley English From mext-bounces@ietf.org Wed Oct 03 05:00:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id01U-0006pR-2V; Wed, 03 Oct 2007 04:56:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id01S-0006GI-BK for mext@ietf.org; Wed, 03 Oct 2007 04:56:02 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id01J-0000tC-KY for mext@ietf.org; Wed, 03 Oct 2007 04:55:53 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 10:55:52 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Oct 2007 10:55:49 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222D2D9@SEHAN021MB.tcad.telia.se> In-Reply-To: <47021046.1070100@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-korhonen-mip6-service-03.txt Thread-Index: AcgE1zbB1oqQt1HZTaenxFpveTI5AQAwq6vg References: <4700A05C.3070905@piuha.net> <59D7431DE2527D4CB0F1EFEDA5683ED30222D260@SEHAN021MB.tcad.telia.se> <47021046.1070100@piuha.net> From: To: X-OriginalArrivalTime: 03 Oct 2007 08:55:52.0569 (UTC) FILETIME=[33B5EE90:01C8059B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org Subject: [MEXT] RE: AD review of draft-korhonen-mip6-service-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org > >> Are there existing APN conventions in GPRS networks that=20 > are based on=20 > >> domain names? Or are you inventing a convention here? > > > > APNs are have two parts: the Netword Identified (NI) and=20 > the Operator=20 > > Identifier (OI). The NI is mandatory e.g. plain "voip" in the above=20 > > example and the optional OI is the domain name e.g. "example.com". > > Of cource GPRS APN domain name convention are more akward=20 > than in the=20 > > above example. So no inventing a convention here. > > =20 > >> Another alternative might be to just say "UTF-8" and that=20 > the value=20 > >> is up to a local policy. And unique within a particular home agent. > > > > Hmmm.. could be ok. Need to think about this. > > =20 >=20 > It is still unclear to me what the best choice is. For a wider applicability, not just for one specific scenario, I think UTF-8 could be the way to go. Just like you proposed earlier. If some SDO or alikes need more specific definition they can do it within their own architecture specifications. Cheers,=09 jouni >=20 > Jari >=20 >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From Cole@ipu-bs.de Wed Oct 03 05:03:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id08D-0002uC-Pa for nemo-archive@lists.ietf.org; Wed, 03 Oct 2007 05:03:01 -0400 Received: from v2c13.v.pppool.de ([89.57.44.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id088-00015w-Nf for nemo-archive@lists.ietf.org; Wed, 03 Oct 2007 05:02:58 -0400 Received: from Bernd ([128.196.153.65] helo=Bernd) by [89.57.44.19] ( sendmail 8.13.3/8.13.1) with esmtpa id 1GGsSG-000UTK-ZF for nemo-archive@lists.ietf.org; Wed, 3 Oct 2007 11:10:54 +0200 Message-ID: <000b01c8059d$42bb88d0$132c3959@Bernd> From: "Cole hluza" To: Subject: agilpirg Date: Wed, 3 Oct 2007 11:10:36 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C805AE.064458D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.4 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0005_01C805AE.064458D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://comcbn.com/ Wassup nemo-archive Did you ever ask yourself is my penis big enough???? Cole hluza ------=_NextPart_000_0005_01C805AE.064458D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://comcbn.com/
Wassup nemo-archive
Did you ever ask yourself is my penis big = enough????
Cole hluza
------=_NextPart_000_0005_01C805AE.064458D0-- From mext-bounces@ietf.org Wed Oct 03 05:18:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0M2-0008TV-OU; Wed, 03 Oct 2007 05:17:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0M0-0008Rq-Ki for mext@ietf.org; Wed, 03 Oct 2007 05:17:17 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id0Lv-0005VU-7Q for mext@ietf.org; Wed, 03 Oct 2007 05:17:16 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 360A619866A; Wed, 3 Oct 2007 12:17:00 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id EA620198658; Wed, 3 Oct 2007 12:16:59 +0300 (EEST) Message-ID: <47035E0C.6000500@piuha.net> Date: Wed, 03 Oct 2007 12:17:00 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com References: <4700A05C.3070905@piuha.net> <59D7431DE2527D4CB0F1EFEDA5683ED30222D260@SEHAN021MB.tcad.telia.se> <47021046.1070100@piuha.net> <59D7431DE2527D4CB0F1EFEDA5683ED30222D2D9@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED30222D2D9@SEHAN021MB.tcad.telia.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org Subject: [MEXT] Re: AD review of draft-korhonen-mip6-service-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Jouni, > For a wider applicability, not just for one specific scenario, I > think UTF-8 could be the way to go. Just like you proposed earlier. > If some SDO or alikes need more specific definition they can do it > within their own architecture specifications. > > That would work for me. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From wlock_Preziosi@wildernessfauxfur.com Wed Oct 03 19:29:55 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdDf9-0007ms-1a for nemo-archive@lists.ietf.org; Wed, 03 Oct 2007 19:29:55 -0400 Received: from [213.247.216.54] (helo=[213.247.216.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdDf5-0002Kt-EW for nemo-archive@lists.ietf.org; Wed, 03 Oct 2007 19:29:51 -0400 Received: by 10.134.94.52 with SMTP id aKBThKuRALPBW; Thu, 4 Oct 2007 03:29:56 +0400 (GMT) Received: by 192.168.36.206 with SMTP id vpElgrXQohFcPP.2502719489513; Thu, 4 Oct 2007 03:29:54 +0400 (GMT) Message-ID: <000e01c80615$4c078420$36d8f7d5@designstudio> From: "wlock Preziosi" To: Subject: auxinen Date: Thu, 4 Oct 2007 03:29:51 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C80636.D3192420" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.9 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0005_01C80636.D3192420 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable http://ebaysavy.com/ Good morning nemo-archive Your new, bigger penis is only 5-6 mths away wlock Preziosi ------=_NextPart_000_0005_01C80636.D3192420 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
http://ebaysavy.com/
Good morning nemo-archive
Your new, bigger penis is only 5-6 mths = away
wlock Preziosi
------=_NextPart_000_0005_01C80636.D3192420-- From StewarthurrahMccormick@epfl.ch Thu Oct 04 02:41:15 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdKOZ-00059G-CY for nemo-archive@lists.ietf.org; Thu, 04 Oct 2007 02:41:15 -0400 Received: from static-71-168-35-154.hag.east.verizon.net ([71.168.35.154] helo=keithlaptop) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IdKOZ-0006vB-4A for nemo-archive@lists.ietf.org; Thu, 04 Oct 2007 02:41:15 -0400 Received: from war by epfl.ch with SMTP id ldqkAF6a4o for ; Thu, 4 Oct 2007 02:38:05 +0500 From: "Alonzo Poole" To: Subject: Multi-hand and single-hand blackjack Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Free money free fun. Play your favorite games from the comfort of your home, USA players ARE included! We have it all! $2400 welcome bonus will be deposited in your new casino account! http://netcasinocenter.net/ From ClairdeputationBuckley@trinitycommunion.org Thu Oct 04 05:13:12 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdMlb-0003EC-8j for nemo-archive@lists.ietf.org; Thu, 04 Oct 2007 05:13:11 -0400 Received: from [89.7.113.235] (helo=polo) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IdMlU-0003uI-EN for nemo-archive@lists.ietf.org; Thu, 04 Oct 2007 05:13:04 -0400 Received: from adequacy by trinitycommunion.org with SMTP id u9nX3qBDaC for ; Thu, 4 Oct 2007 11:11:15 -0100 From: "Emory Buckley" To: Subject: Our safe, secure games Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Come see what it means to be a VIP. Come find out. Get your bonus and walk the red carpet to winnings and fun. Come find out. http://greatvegasgame.com/ From SolomonvertebraeMueller@suburbanchicagonews.com Thu Oct 04 07:41:28 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdP56-0003BT-M1 for nemo-archive@lists.ietf.org; Thu, 04 Oct 2007 07:41:28 -0400 Received: from adsl-61-66-173-133.nh.sparqnet.net ([61.66.173.133] helo=mychateb09dca6) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IdP56-0001fy-39 for nemo-archive@lists.ietf.org; Thu, 04 Oct 2007 07:41:28 -0400 Received: from suck by suburbanchicagonews.com with SMTP id VELzU7Zp00 for ; Thu, 4 Oct 2007 19:38:35 -0800 From: "Rod Woodard" To: Subject: Your own privater Vegas! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de We have it all! How about the best service around? Get $2400 you download our casino. Download our casino in 20 seconds to get $2400 richer when you join. http://vegasgamecity.net/ From shru_cool@genesis-sa.fr Thu Oct 04 08:51:29 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdQAr-0001xc-Rr for nemo-archive@lists.ietf.org; Thu, 04 Oct 2007 08:51:29 -0400 Received: from [89.216.193.157] (helo=ejnosmw) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IdQAn-0007Ak-2x for nemo-archive@lists.ietf.org; Thu, 04 Oct 2007 08:51:26 -0400 Received: (qmail 17856 invoked from network); Thu, 4 Oct 2007 14:51:15 +0200 Received: from unknown (HELO fkuea) (85.222.145.42) by ejnosmw with SMTP; Thu, 4 Oct 2007 14:51:15 +0200 Message-ID: <000b01c80685$40432b60$2a91de55@fkuea> From: "Hampton Charles" To: Subject: Graph Date: Thu, 4 Oct 2007 14:51:15 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_01C80696.03BAE460" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.0 (+++) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 ------=_NextPart_000_0007_01C80696.03BAE460 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C80696.03BF2A20" ------=_NextPart_001_0008_01C80696.03BF2A20 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_0008_01C80696.03BF2A20 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_001_0008_01C80696.03BF2A20-- ------=_NextPart_000_0007_01C80696.03BAE460 Content-Type: application/pdf; name="Graph.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; name="Graph.pdf" JVBERi0xLjEKJeLjz9MKMSAwIG9iaiAKPDwKL1BhZ2VzIDIgMCBSCi9UeXBlIC9DYXRhbG9nCj4+ CmVuZG9iaiAKMiAwIG9iaiAKPDwKL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL0tpZHMgWzMgMCBS IDQgMCBSIDUgMCBSIDYgMCBSIDcgMCBSXQovQ291bnQgNQovVHlwZSAvUGFnZXMKPj4KZW5kb2Jq IAo4IDAgb2JqIAo8PAovQmFzZUZvbnQgL0NvdXJpZXIKL1N1YnR5cGUgL1R5cGUxCi9OYW1lIC9G MQovVHlwZSAvRm9udAo+PgplbmRvYmogCjkgMCBvYmogCjw8Ci9Gb250IAo8PAovRjEgOCAwIFIK Pj4KL1Byb2NTZXQgWy9QREYgL1RleHRdCj4+CmVuZG9iaiAKMyAwIG9iaiAKPDwKL1BhcmVudCAy IDAgUgovTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUmVzb3VyY2VzIDkgMCBSCi9Db250ZW50cyAx MCAwIFIKL1R5cGUgL1BhZ2UKPj4KZW5kb2JqIAoxMCAwIG9iaiAKPDwKL0xlbmd0aCAxMjgxCj4+ CnN0cmVhbQpz7VlOOB/a5C3v01bg/notQjC1kVC3r6mPpAhaWUZvusOE9eXcFCulZ40fR/6o+ZB7 C3MbXV88ObJ5xcJfVvN1QMyHcyFd07Z3gzKzZ11uKZA1jHQ2g6pgBy/8JNAW7e3y39ZfJp6swf6F tk+KkA0BJFacSK2JTiYLbyLhQ7yP4+XsYkOY3uR9farqoaQo4swtWL5xDF5OGV4Axsak0Id7FyfH jeWNaKNDyHfWJOakv4pOVeMbpC9VbJ4OAUprw6D+6NAGhWQtLDWpoUec5IFb6AoURUoaeefMxivk t8prPkR8JFwQkzNWvaGEq6T4ACxe+SOlzK15iid0hhqtshoPLmv+/6mUstGSfk1uXGMb7Uq2FtLI VcP/yyIOK1L0dXqtNKvuknFNICNYepC6W+UQzKVXqMmmo76oAExWsOtGp+YfFq9jGe3/ScAQCHKF iA6imYqavegrzBvPXWAhXYYu5QyURVQD5Qq6+6qjDG0Pgi2OEUUUdRFEaWVBkQ12+c1MpjCgF3Sr 8Zx3bfS6M81NWkDmAGH2WeNtkvqerEaFgqpsPWGcyEfCd5Tgg0h1vS5UHn1QpnsSFbONAOmHZQcF 9fISCWsLilsd0l8y+LDCIwUcoJmqViaWqlFkzP78dth9msgTXiugwtsOxHEre/3SiGpXYmv9stgC nJIbBJknqFn3n6Vz8sSLyR+TK2LRtL6ReNVcNjhWl7TW28YJL0cdguqxaNOSAXhc3U5KPFgdLyoH KIdxdLjAifTESlvIMbx4IiJ1EOIa9Ze3KYqNYb3GO7YSAyQRj4AVaGFVBQVy6I3djBeY77IU+GG5 cKTZEj0uAcOeV5EG5gsStoHIgj9YxzchlAERgSFSNVOh3h0vzzef8nl/M72jti05wIPB2iE0l3EA D5nAma+DGY1VZinRmQNCrPUcaG4IWXZtE91FWPJK7tqtS8Ra15gVrjohiSa4VjFcKGNEUxgUcedC 7gyLORpIqpsT4f3gLKtAPUcAnBHKWjHGnm6AWh0dp5nEHocunV1gv1Q8ZtWqGd1b5oVHxywaIYzn Y6YTY+s/4Jr+Yyy6cydNhlbyRDtcnbDWeeOPBy/tUc3w9JdCQ5CvZhwZU5+IcEECIhQuc/oldaOn gAvxvWDl6PwuY8TFlXD91tJkYK/BcuVGFbXenILaV/gGixjP5AS2d3jA2XQF/TE1mpoAg08YAcTn WdfE+/xSEEeslEqvp4XvG8wxwqrXcOG8wT1gPE+n6AC049T8JLDvqyquiybo4CI7HmYGQn2Os8vn emEp43/TYAW2c9dtTlUAA03SPCZ4UHeho+izFf9+Smg58IyBPS+zOSqWRAkq0H3uVSkZX/cO49Zg gGBQYhoHptY83FaXiWDoZrysbB/XYNzGWnjMzR37sKtFVuxDMdne898V++AptQqogPAdOtDB1KFr c9tdsKItKoBb8tqIat5nuWL4b4zxhcEFa/2sd2hKhbmsJpqtdgT9UH9wazBkfj953ekaFcYBH3vl wV/otNKHj2s53LG7ONeZPjHK9EI14YsbmzscHgs1xefmqkLY1DrRE2lUwY4g6kQdnhqWdITTpxOE W7KFi9zip8zzDMlsImN/DXmiK6PM01zxUWNgXXJz7bXg5GyWIFczH93NqnkNf1z2T7FgfOU02hOp 2uCBStVvfDm2CFHKmMslVpm2P6cbgWgPMRP9bPIgNN4d9+0KZW5kc3RyZWFtIAplbmRvYmogCjQg MCBvYmogCjw8Ci9QYXJlbnQgMiAwIFIKL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1Jlc291cmNl cyA5IDAgUgovQ29udGVudHMgMTEgMCBSCi9UeXBlIC9QYWdlCj4+CmVuZG9iaiAKMTEgMCBvYmog Cjw8Ci9MZW5ndGggNTQzCj4+CnN0cmVhbQoNvSPv3lSBMnQx70Dk5zrH2XdNeZvBpKYVcmcMjJYt /bXpJptcYhI7DWqtxGhpl6Hc6caZDHC/t/BSwfAtwK3BJHp14bWRdHo0tdbH1HFHgMgNPB9OSi58 XHsKHmNE/CYxszvO8bT3RBrUWvpEDglpkZFwm0MZg+vu6ynL76bSk0XU9SHhcz/winLopUnVql5z udD1og+yYAWD1e3tj/626sK/XK0oOd6cckjzf0QyBja5094tijwcTbRrCpwpDOjlt2w4MPB58s/L Hh0VQlAEhlgPl7McQRx9hD12wnBswLswHuJCuuMBWG0Pi7cP29LHu+ZkRCJXt1X9jrKBZSbooKWE Q2p7VRRzlSo+Xj8jhru4dHT+FlbiNl1fwsoeXnRs2hTCHWoBAGrJpxoZnPTWtXBieoFYZTModnE0 H+WakOBCQoeDiPYU67zroxthQbELje02wF7sUPNbFk+oQry5CTx1/eNeTlwJ5NM0VZv0io8VU0Vs 7S9gfbzyRa1JE7koxCnEW8Skaj4v1YwvHB8pMzB5FlOTNldk0wvY4VgHiY7xkSXfcuveBPFaLRFr 0f+7qsjKC70mjnWTWIvtIjOxMXaEvdRUIkRspducpeRnWlvH9bcEQzuTF/ZElVeobkc3LAvqFK2A cyky7DuTB0K6bPMBdT9poFb33HLLa2QXhJgx2MQo4NEhkRNulk+B3oGDEqw4sqHjZrglAUVqtKoK ZW5kc3RyZWFtIAplbmRvYmogCjUgMCBvYmogCjw8Ci9QYXJlbnQgMiAwIFIKL01lZGlhQm94IFsw IDAgNjEyIDc5Ml0KL1Jlc291cmNlcyA5IDAgUgovQ29udGVudHMgMTIgMCBSCi9UeXBlIC9QYWdl Cj4+CmVuZG9iaiAKMTIgMCBvYmogCjw8Ci9MZW5ndGggMzQzOQo+PgpzdHJlYW0KT4vGvju5rNpi uUvY9EkDHl+LMC8J76S89O61TegBpcL9C8ZgJnSWvmUuHAdJXhm6KxXNVKyZU8Ew56C2R2tO4tTK VOh4haBtmuI2rXtiaqdl3QYvuxspiyk7xSQ5F5ecx5ajGzS7OKyZeSkw7nSg8RuvH9Rd1Eo42jqF U6rB6CoQGE1jj5x1/C/gAF+SYsGrrL8HJK1CNEQzIwp8GSpD2hdeGIG20EJlJVob/DE+G0lrZjBF QBvwq8+QcumHlxi2WGp0r25G0RvYd2bWEF/2NSoJWIqGTlQojNJuJrCmw9MnvwFxI0UEwxvkDOPT H+hhNW2V0K5Pn6YfMMdeNXCv8GbYj26egLfj6nVbuH6VsNuHnbmvQ1gB31rPC703XFRhMwBx6PjW Z93DEHc6fZYxod2vWMOu85x8Zm1GKhEwHvXfLFD5FmVW8OzgNpzEWkq+im9SIzUFRl3e8sq+YAIy DO8W0yQU66TG3DwZQ71nYty/tV1wUlrpWRmEEyLXoDbO+O9vGdN/7T2vl/eHnn9E59nDdPTeS6tg CMIw4r3m/rbHOfd5pGGnu5W7ZzpfQMypPGBiBB/S52s4Qh1GyyiRgyUekc7U6MYIjsmn82F5X9ma kJ9IJoUreH6ZuR1XPKeFXWTthykf+Py7UgQeD21ohzaWyeVjHeDR6Y+55g2KEE4asp9LNNEZHUyG 5Y0crdWWQbZ4+v1JvNdvwDjnqGH4KdrAmvhWXTmY+NtXcIB8n/Fr65+ucCDZjlH3eSax2/fLxsVI F8w3GGapPIqZmEeDT6fUD+eIklTtF4joJO1/NXYts97fzTkY5uz363Tz138MMjmCiRt6Ju3Dhvio AJaVxnC/RhbcSvPjm14+ol5XDlaHal0mLqY6xeZ6zppAZO4JjS34nCWA7mhuYYz6paaHA/hAtaF7 5t+G1l5MQ04OJRZc/0bZ4SVx1ImeutgTBauy2lzI7+vyRdHCFK1vYCCv+kr2Nb7pmZzIIP+MoJW7 09fCr1YsAGyH/Wl6A6tOE+1oyppGb1xWK91mmNyfySxjhfY79dcU2Rbz7ABrzJIc7+fJza53RaWd bIUUMYK60E/oUieYqwi1A/+ZTD3j+plzsFQNmCgzKwjT5pEaQR1CGNAoCLOqQrGM9dGXIMA2evdj 985Ao6UNSA7MocokgBEPxZpFSKjp2ATSgvQnxp/Yvqq4Te61Gak4U050Md5wjyF52sCvTR04oNm9 KI+sNi39CTXGnqZyNpr8qnYuYInXdlJf72OH27gGtDogwmSARyzo3lwcRx7rWPmRhKW3kYJRYO1K fJWOmVv7MHzfKCdG0gDNCi4rB6tMr50mb01DKi260pOU5tA0vlWM8B0hmEPqNf1YqRe86L5Jmofm sBiGVdua50rxHno1XZBcL+yBVfR94SiZe+a35P1H8FwxWzO8U88qmM3OnWcN9v3N8F/09AHOlC8J XMpgnehBC4XIECRZBkn43VFHxZ6T8RvvZ2qtroRlom5ht//wVh0lfkkS55daiWEp2zwPD+teLzl7 eJQ3KGxeVRtjYKziTTM5c1sz1Z+UZcbksuRJzVaodOJU+eSiQDLbHC9DC6WK0BxhwlZop+pexnd1 dMlN5Rj4oHEaRKvCpIlWK6Vd6/v5rf60SKW6o6kWZt1VPAHgjnZMV+V7AcwPTjNqTW548HaeX/zV qtvQP4RqNZIZw56EB2kU65K1vrqbV+nx5FfFxjrB/mPeaMhXMiJy6k2sxpfZ+iCr83qCn3mxNvfZ yBTiJCq+N1U92fkjLtu/9gFzq2zU/G4mW03p2RY/D2aJeZGW1gZOIuympQq8mD+5UTse8sO2bNsZ N+pefr1xsjNuyZhpAMfbO4/F/3Jqa7XGM3ZMAngylGH1Y0bHrpZd1U2P4/7RJEcqwqSnDUndP/Xy L/y69bcTaLeCrlyvtdpSv/71yDdqwQhq8Jch1SWs7ifmkv/c07WwL8rxVZJ5M2Ih2j1teaGNONd0 7GK9GYIAb38sF0GBG7qgI90mVTdq9tJGZRSO2xGsE7k2jmeqrSqfWcEOdQC4EgOIRD7mgZout7oX VodKdsyCt5iatI5575ZvMxlAu/odkc5F+EIzdnuLntiqfV5Kf3uyU3hB1MV6FPiHydWxRe2WES2g Uzb+FqfC8DYKHN98IGuQxn+1aNwVgQm99c03HbcLCSQj4bO4cVg7TcEWC2YSkTpEC/I7Gb2QCEuH KVljuNl0iFz5HGvkFovM1fueXBznLIbAXJ9LLBWJ8PfhW8xajymow7HD1j1WBHQ531s4kz5pYbhO 7gGWw0IBhrvw8nV84ohiG/KfPoNI1T+vNXk7I7J2DWmGk9qmuSed21cRPXrPF/KtW0D8YfnN9dT4 I1p+QEAbotSnQ19Tw4ZSZYAwlwfezb3U+MV8KdI68Tcs9pbZnL1yponr6nn/NUOd8cWNGcqtYOKP 3MZX5uEcUmn1AjM6BO6BBTqo8wa36zckFQb0nfwFvJxcBS1Ugt6rsvB5VAmJuz3ZBkP+9Af03NND yrV2adZ929yUuTB3gXev+BuOwjcHfZjE9tqf70ZKMd8Bp5kl4mLkyCnZAzGLBgG/dqmMLpOf7SuQ v20r5dv91NnACbKBmq6StXy7iIJgTyBILDh0wig8QbXGOHa3PHGca7KWrwm1UzVOpopvrh00OGJo Q3cX/hSVBnNUuVyft87vc2IVxA0kzJQW4Fn4EFBNB/chzpogWmCrARMSgLNXIo3ENCXkbfcdl5Jh IopRTO7qOIOE5T+snVsdk0JN3svTVY7mF5JbxcoMqUmXm7hs0WrSJbm7aeLaz1Y07hLS1I4dEXkl qGzHp3ua5jgzdGNroaDhM487rl1Xqhb25DrjZvInv+wgBLe1F66tPD/Wvo9Uq72BRq1cDpodivsV FE7xXgcXCX4/72kAb/I6/wbhSJy2qxumIK9xWrJtZ5N0OtZWxWFMSJ9fxpyO3JUs/MVjBfy2m4Ls Flj2j6o7Qb8GLelplrNOA0tKi/Vjryu+gHOYcXwzS+anyMZ1c3492P6wKfHSKRs5bIQ6MVLmqAG8 QKH4ABMWL06zxduS4GenPjJd9cYNaJJZ0KiKAOrhQ+FA55c2mUztc91HI8eTSWtIfBsOMKu8X5dB xzMq+nmlUir2jojN+z20jBjQxn0ZISXGwYvaOoBD18OfiOl1LG1wld5D7caeBAqP0+W+TQftCBNg 6zq0uMTlWFmkebirsFcxJBhA5/c7U65KMrRo0DbDeLOhQNYP7u3Um07tKmtOGvyPJ6KV7/Z7m1gc 55htgcOg9ePB2uob21mKmkJq9+L724MIuTSBWeJ46mOWJGXERW/T68JIdOEFaJx8+aMq2d3EpErJ XfJZArGNqcL+qxLXnv/GJqzxKUkTpEmAo1rcUwxxjMmc32C+36UL+FxiMiJZ6CTu9k8E7zyvKH/j 4uzF8c9HtUaiekhBB2gQvn8jDhTcCIDJyaYOcUjl/S3TG1rJh859kba8jtsq18X8Xk6TarpLBCme JlIWkjzXOVB3T69trmRbRwt8TO3H2xgtG9/14Px3RKYzH5LWh3o7t7yzbjSA6JuqNTyraJJJwxJ7 yTlukIwSSFhuuO3IFxJnAJr44NKcWibHRc3BpWeJT3pGJPLQJdPKmbYd0cj1CvemBKnBtc1QLAtD 1PSMkmXJm6wJceHsDS1XojYNFXOSbxeJSHk23XXJNYr5YZxVvb9OGNixJ5VZy7/3psKI+Jqicvvp giRZ2Hsadr0mKmyxLKjuPMvre+0ocAbKQducfGjTMVZJPNHeQDOVj9cx9ZuF1W4YDmY0tUxweSfA D6rDPEHebEsSxWEqdMtzx/5aoR1jUaYP7Ubx7IG32LoLJdA1rrmmNL0jdghrc86CBQrFynWlBhul 16QpqX3ijmK5B6OYE/pTyBkoW/2vbh9E8Vm31hpLnwvFolS+M8p6Bozhwr+GpJrpgfhEcv7/nwZC qlWVDNVxq0kFEduT6/TPcTQNQcwLovj+vewHB9geGQburg+wD0Dh8ABS2HP+AT7GrW1PKTCCN+1v Lysqq4BAoSSzvpJ0KVGezAaw43Z/m5LHTWfRQHKWA1neFmOpDUTAglkfvp8HdnZpaQBa2fmlIDA+ OWmmDd9X/fyz2norVrKaK17e4v4Iy8GNCUJEa4lGkVLcF+FkNZQx7dizIONc/8Xkmd+Bi3mNigUU 7mLcaaMwhOnFVfD/rahHzyV+WPLV2nvquHEUzyU4R7zvwU4vXJM1+h2yf3oGI+vxIgBMIW9ty9hH eUHEKEwS8YDuASlrg4hfWhhj4u456jJ6G/WEtWs4ov9Dj9rygHXrQBB7zafLsbXKBiksTXVFj+S6 hTP/2FbW6fKZTFITl3/g9t9d3cBtgr9ba9OCXl6qchjcVI4YbLZufLbma/kSe6yjHPkTHHx45bK0 BP8rM5z6/vQZy3xfd7ZAHsPeAWDPAGXfLMGCuWYICJ4H6Gp84NKYyH2xFIJaw5XG1cTYhpJsMP5U NuoavLY+uQqDkfD0AkL4GrjNusZGBEzIfRBGzru0bi1rXVWOoF9gmIYi21/11DA7raeN8NsTDfUY 57i7tSrDfybKeAplbmRzdHJlYW0gCmVuZG9iaiAKNiAwIG9iaiAKPDwKL1BhcmVudCAyIDAgUgov TWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUmVzb3VyY2VzIDkgMCBSCi9Db250ZW50cyAxMyAwIFIK L1R5cGUgL1BhZ2UKPj4KZW5kb2JqIAoxMyAwIG9iaiAKPDwKL0xlbmd0aCAzNTM4Cj4+CnN0cmVh bQobIbu9vCJjFcVTicFvEXkmkXjV6sZ6tCRhS6w0YKnecpPY4J0YAQuTQX/Ufy2YUENqtkUXIgkb 5bsDpmIfeZzN4zECB0cGzy9gdFk3mP6H9RWF799SX/LsnFjZ0RQyheGZGlE50LZPA7Uco9soxAaK JgOAgkqI18996Hk+9+PvlZs28pWys2Tbm/rLCyA+j+zGvyi6UY8nsJhviHLrV2Gw0N2JE6Iqcwwm AprPhLDwUzDkgZFt8wbFBbnt3pLA6R+z6ixVv9kJZNOhKUsmZfspfns19sTi3xq8bv7bgZcaNcbO CUYD9V5ZDJLn6E8TqfsLDWjc54enFMqFuYj3oiVNeezwF+mP1Co/JFb1Acv12tUKKwHtVL8OAYlX 8j6VX4vGnj+KVDBR5G+WdkrcHwFQ+xK00HVkec/mDGUB7eahl1dTihNZdrGFqpd/k0gwBgCp5TYY fY16mZsX7XzaKaIdlzmuYAMK3JriqFqctB81icBgvssZw65QfTYbtC4ZASeBvaMnBHy6cw8haj+j UO2gV4MshKtLVc6TD/cdpODXmPX0nHR/xJHX8neBhOsRCHXxCvQ3fHl+jF3G6ItERUr+PTeaN1o9 15SB2AD4v5rE07gnByEGA0hEB617eeBWbpmlp3gGOqhecWzDx1HV36/DcyopZvqQoYIT7iEkjoFk PpFEJl1Q4jO27s0J5qA/UF145FsTbUEXXO+vg+t9zVcaFatHyqT5LUr6U1qTX5nUpnk7NaCnC18H Uny7Uk5keo2hpZr/OOU8tsyS7b0L4RgDMeou54vqAbNTXLh6SbNkezvgLeKxFvoGuPQoAlZoSfUg p9XYrg29X34XK8eS+aQP4dg8yWmknjFxi6JZeQfdXpyjwXnPorT9154tmEa/jt+z7DwDaRAswr0j fG5qSdmFPpIcNT7fjZyFDvbAiGDGSqzebh10/buCZ5jQxy7E+j/iCODszwyppYinx2YKPUGxQXDm N22j5EsE2u9+5/9Yr935n8RWGYTSgxhlJPHNaqkVO0tKgFCgCkK59XtUkjyOhcISpJkctPXv9Al6 +uOAJuC+kpVXqtzBRG2SqrbuMP21a5sLX9yvk46Reev/Syefh97Oa1TRsKbvmi+XD02VwomlyZNv M/bImLW76lGUmnHt/+uTtUXXEMKoNwq55UslCroiqHIFcYLeTnuS0UhF83hAPd7SwFx7HMcNhlzp ePMNQjXAbtSJem+dRXkzUAhl5CPiAKJ1d/dSbDcE7nKP2/bcYkxnuxNII/R2Q+gj4XGW0EoEENPH ulYeeOp+bDHP1zya4NXybE+bQdLM5fnwUhksTmA4fEq3Js7CvnOgTk4uGHdv4A0BkW4SqpqwD/RY xTN0+ppcTxNXUUWk71vgtjBFhIf058OQtl30tQPHJcpDYU35Ony1QgRKcuM9GtD+mTJugygpM68y A75fvxUJA/2tUW1l6R1PkV4Uis63/mmSQXOHMCLeBc3bZMb9mM5OVAVYKliju0WoEtufte//cJfE iMHgvZ346UONloYSj5grIIoDAC3x9Izwfl7gwLcKj6iBI1182JKqBtyilpzCu+U49our51QqdHXh XMue/yTG6XvcurkZpFNuHCu1PIGi8/jH9tUPJSXQxNksNceWxqTQ/6/Br8X6g5CF5f5UZRIKMLYD rVdDTvos+PYaR55z2jgvQDsLdkhvmTfnFuYWV/nFxmksSGPu2Qo3SaDvP+r9JPg66d4sl8tLjTTy 3ZqAi2Oyb2HqBepnL6m3LP+nAYvqf7XnzF3B3FDX0cBtPfcFFZu8dvwB7XT50iy2o01qfcvI1fr3 zibgxkx4glkVB44bhN+PtyISM+J3yNsPv/sjacpijvR+H3zi//6c9iYimbaJcbcI+6jE1W3X4qBX so+G/x1rPJ79qbEKi9QxWXCFJwaITQNz/jnMWziEHez23ZMqXD3mAM+xfrRH833ykfBeJbRiMN+Q hurBqVIqPMyTVy/9cbRlI7oWxkoVmY6BGrqFXZN7+z232SQ/KspESh1Cdf4e5+XePRMCXBqLk4Ik i+VJsGdbKpAoV1tJWeKXyPfIOmsV+uHmEvlOZeFBvp0fYcpyC018V1iIdCrgr4Fte9zGJO1hBWtz lYG7tCuwVytyAkqysrrgknT5Jl/To+ATZKL8khpvRO+rxbPcPwjSly4bfl156bX6qSNTcWlBWAre w1JImArj+luSuVWN5IUznc6IvotXdIH/++7DnTJFvLHN/+r2bkjD1Hatuq0UeTGJOnNUJoQ9TewF Fna8j/3pG9GUBN2RoIkRBlK/y8rC4U/0VQQlDUckIrJVlyGC983Outt1ZDqjTkOY19DFNfaI+EAF 4MShjapC6LNbDCXkBJCYhdrorej+lf055ZoxFNCeCaj0CguH95CPVuswltBIIpCItvcXo/KLNcHJ R3j9pCKLXqBRZlbBZDN8OI9p6FjLbnq6vSFYCuqPqto//LmJCEmVKGVPXDLVTfvyqmvH0jP5npX2 BuoaHKUk/pLhKyci++keaD0Jt6Ebljt2VIzLyaZDek1u3w9Po0ZfN0WikI05JjY/oimUawht0aIz Yi93AvLYoiUJzJEUCVw/bHJZQa1HKzlNZZxkF6RES91z1rp9d3RqYBJeAJAPUo8KAx4en9nNQ0/2 zqNvAA7q3X0uvzjgfmbt/N2H9JZi/hEGkLZrrmRgZe27n98yo2MvLACdZWOOgyviq0oT+BODPDdN to9LJGcucrNLLotiMSA1tk/bWFlClsnYTOjuosJZz28w6H9D/00HqwVPC+VeukvkpQtPYofOosgw WY1b54rMX50eK3ogLbE56Cu+tNujaA8vpGjS4nKGLersEME8ne2QXm6HbuQXb4HFzWRuxKipFWbF gGpW5gzMank8MLJvnh2Rq48OsH/r88v/s4wjppB9Gu6JUhcB+28T5DgTLaoFg+XqJ51wkcU5sufY pOep78fhUIis//4CFZhcXPkLGJHgdNV21fY1rhwtSkdOrqaLDk6yV/+zMk/RFW6hqYx86XV26jdK UM7qr/7fcl4rBbAM1YPt5BLbroa6pRUqIU11eIKnp2stf1hlU0Xosd2yhK6vQAcmaNOxrrxX/EaH NKqsKAumRudCwW0owMrRQ16JlSxteKJyGYeEadXTcRJDYezTbjdJXUSrZ8WjVPuZhRuWbQG4s5Jx XJsSTb8jonih6INVapks+hNmuO46hnYR5B/Ozjlk9ejU8+l48JJgcs56UHZEmW/BPZQ5PylacpRN gHJaoMRx7PZkOaY/+UefdZRB+jJSEePbZoLV2gmDFU8mSj/ISbZRqSCoP56/mCC9hMvmu+Iib96Z +HGA/jjWvURLoepVVyEgXA3W2rxiX5s/LKVVlIBuKmT14TZrROEbhJovJzX0+hy8qHtDCG8hqUYt EXbxlnLmgvTQTUMLX/qa7Hd+UeWod+HroNs1zxGLSnRjTNHUZuVNEBHh8fmiQut2Un42oV94FbvI z5mvYmFuyMM6hTFdx0pnu6ndcX5VeN659zwd8HLbLdYEtn96D/eGKGPFBiZWiJ+hQC8KWfAy5Qjk AN89lvjWMB4Nw0qhGedW9BG+4uDeGhOZwsD8oVS2wMq62sCx+o5JEJzk50sArQhTqEIHuwioTqrt xckoj2mWlLfqiNes0gbJS6nOxdDURv3LcEWOGxFm/fPRNlHeWSMRVOZ3JRuiX8c5bT06yCs2zYF1 /rX0eNkqjzBT9OVi6AAfDTeWA0/XKUyhDqb54QSYtCj/clG+LGAZKXgZ6CIxGFVYW+8jwRsMt7vT zleP8KAJMuMcxzsQ8m5etzphRg8BM6jZOPD4suYJz9yO2MdwE5mNSY9Lsjbl1XARHF5hSjYBSvgy R/8TVhl4yvCN9OQEV2QrCuyaIe4aOkIUh38tNFscr9Wr3if0zVWNxH/m2nRGXwjgeeGd2HsFA7wJ orPyeufVILynUtWkLanvBaVxSzLwwHoXu52W6i+aCHIfHFpfEi9WrXq87tQC4pgGQz2o81+EYxOU q57CwaUJJvvZ3cwb904LVsCb8XFxD36ZWRPlC57mp44CnhnfFsruBkvZ7l4A9RKYHU1VHPrKNs41 1OQYeJbUr2MN7Dm1n4EXGvDNyH8ttzK/g8jlPXtqt897sYQWq/PZord8r+OowqC1QrMB3oXvda3+ 0LPY3zoGQRhZfeWpuZNfudl3Im9edsiGuOQgLL8Myb5kc0+b0y45zA+7GSY425f1JlVs3uhVXHv8 7552+06Gq0lW0Cbl8N7H/E+t1jmFMhY5SCERLoi6Q0DcPsiJDyUIwoE8p2FwBcmWz/qAP1Mi88JN xuIUjoCBotOyyU87yKXQWrgtFViT18oS8hN+S430JAEPq8hxZ1sVKrNFLZ3W9PC6C16AewbHR7la 10/8Q2tf1C+nGfIENLlHKgwQUKE2b2C/lFLJPLcKSD12FesIaQxJURApyvwF9sqiGacNtc1U4kEw L6C5UR8Fd3bf5KD4I39R0Tj1QbpNoIPC1EHUG0fgZclZcCRxnSKmM7Z2M9S6VOMsnUOkgALOccMa 6tzM4a+LCNNAMKp1lgefayc2WipWqAxjSaRXogt3B+INMzP2gCN106B10aUTnyVluq0jY9M0gNYO I3n8QX+WFMSJ3EHze6Q32hSbePWflwtHLZtL6FxJBen3eiYOL7EQo2qh2jdpRiSDjMhlqPybiXAo qdoWbjtqCmVuZHN0cmVhbSAKZW5kb2JqIAo3IDAgb2JqIAo8PAovUGFyZW50IDIgMCBSCi9NZWRp YUJveCBbMCAwIDYxMiA3OTJdCi9SZXNvdXJjZXMgOSAwIFIKL0NvbnRlbnRzIDE0IDAgUgovVHlw ZSAvUGFnZQo+PgplbmRvYmogCjE0IDAgb2JqIAo8PAovTGVuZ3RoIDI5MDYKPj4Kc3RyZWFtCrC1 4I+7htz8U4+18dsiiEAF9LBGVOzGHXZ/jzNDCtdRgIxWpTBISkd1DSqLKGZhApScQld7BG/87LC1 wM8ORD+9Ywq/sVvNpaQORtH1PpWBBYsff6n9PeFcTwqPravLCsVwAjlnfhMfMGp2J8qE73RPBA7x JwvL+FvVXrwqr4ASqswxYhtJ1nudp0WSdLepNRJNR9k+aV9Bvgt040qXC6TT+3riirT1ieKEDQpG EKkB4IDvyGrMaO7oAyMluydPjR30hbi/PNNjCc+H4HFPQLuTMnxpSKEdxAABSi/K1lE7cTsmqwmS wKEeZbvvL2jxIbgeMo98iAMaEQlrEBDAhilBtptc/2R4nurnguSF7mLbba5tauzOPFrL7zpb8LSt OV6+tIgxsYtQ3r5De9zrM7se0M5y2cW+diFZ4RQOzzt/E/x1xK/0rMc37IADAcWKNYN994VKj/rd wRjBZSUvycKboQ2903d/WRnQV3BuWYbEeebcUpZrdCuZUPMONHME++G+86+B+uJEiSow6YgaOlKe bbu2TvGj1p6dFXfKZP2SGvqIec7V5rPCUT0w3tRtWkz0hPZwUzGy7JTVNRsAixC5zT8DCTrpMre6 p20xzSVhzm6gopnyM5+uqhpiSA5OL+WuGAgIHakD73PnLVkZpygLaAh5h9Zl6Rt7LWz68eHxX85n 7joVDl1airbVzIPf71xbt40nfswCfqo7Rmqfvc1mzOPdyljHK/13yhlmZPOt/eZR2ELDek2g3cg8 ChoicuOog42zNbGJ8+iRGfsTAvRo3A4f7l7GnhpkuuCo2Rxhd7OQC9rzMh4/SRIprPDYDiN6tO8Z XGlIwuWzts33D6L1WszJBKHnxIgnmvmUQssItMZ5Di8fiw9eO2piZL10/RCDHjQKoIjFqmCtLE8E /NhTAHKO5al/2CqrLi5sjaaA/34Pn+CDMVUEXYUInbcac6DUcRlO1bL6rdQksSTvr5BgdRDK/bI1 jHAf9UyN0L5F8EInuKUvEIsnkpMGxeiwn8pcYkaOHIT4BP43F6Tk4CsH4n17Q/ZYHjGR9L+mKkrM 3Jj4xx+bQ5YxYQGdZ0DRboTXKvs7cwR5h7U5Ge+aCsHe2c5BFCpRUqOPuj/sJpvbsxmC54bhWu+S wcxFf47vadwE5bLMwxbq93F5scIfzw6kBZPwy8CkSzUDSaa03VmD2oYe7kMPHJAJctqTdC8ADECH KdDeTWdQu0PWYk+HpWah3jd+IkzSRUEoM7ZLifYJSPz4FlXADrYKAFTLsMTKxEGQvuMTqLdlwsHT OOgF/KLRO2tMImF5zZ7H+dEqfTSpXiNICneTZ0xvqP2Iq2pmrHtndWvhLLxcK/hL+3X+cTqH6xPf W0dP6LaxGbjYdpl+b39AGXSSpl89hdwfNAplzUN15MyCeZ6P/Sc0n9EERmRUAMUbwzWP8+KHjkoI 2c2XD0vu4NsWkGEkbU1nF0mVeawbx1ujtAyCOFwp8pazBQiP99S7xGoYODSD9SCU7KXZWacVefV3 m/+4GJIi3SBSejhdfWCcHDXH4ZKmnrPnrlFG2Mt9aURQB0glJia61GOv1pqZQS5XSAwXs3wNTrBm GdLyUGLFyz2JdYOQVY13DWMd1df9fMvf/8uby+OtZchojDbcnhx/rKQrfxGo3vhW0w4jRdZ9L5kl YzKqnuN6dfdmy09jtrMs9B1Jr+ck2IF05gKjk6oLST70Tka8XZ6VBfxoqrEjdgTLqrmBFdAQNFfX yhaJIkvW0GNdP2Gf7mwAAgHEvg4Lkl1q3f4f5xzwzDw19o1haTLWtP4RLfnV8yVp5G2Wr1LK7n0u zIE6HgQo2/0VVSq9ida2Xlv5+dXfWRGZywcet0vHXzJFuqnAf3PD0EWJvAjXiPVQzaelrEpLBell rGiFmHGVzkaVwpmFEQz79QezISZwE34vM1pnPJ6fUCasQLnRESp1iooLhqUXnEgmHEpRYXDH1y47 yTobeHQsyVwZ/QK8heCKAW6hSpp6f/5RVlbbQV0FE2USUWHmcBsSanrLk2RympbCKQhA5bhaD6ir yalHnxrhnLEyeGI5waWmQsAuJgkXxeSyVh3MpEYX4eqT/0J+0YiV5D5i2KRI8pB7aDqsTNlwpIbB 6G7aynu67vU0+S7DPI4RxdrEUXc6rw6eYLC8NBNebnCVS28E+zz5vX7KBtwLUkyihwy4hksp2RiX g7m3xFcHM28NCdA3IlYlWjnMO/9YxwUyg0fFBD7e0wa+R0FX/4LA/PLFe5jIh7IGQapChBZcv9J5 kYCzZscUJSx05Y4c1mveNPbqhXDsLBzUwr4mNCupdFck37Gp+NuIclLASUJgxffTAduaUBTeQc+7 8D6sxiRLF2VDJDw/3Mej2tf49wkRAiB1eh7FX6cuHn08TPMpytJjPEM3oFHz+JtKAhgKpI3qO4DZ 4lrp9+vbik1dZIrHZ3Ga1NWAbg7IjLqmz/eOq7aCqV7S9wqCX2eYfkF6Qb8UdGY4pKQKmSCeiDDK 4fW2K/mDth6JCF0Al5YLup5IAj5UcBTr/ZWR3FWBo7c1WXdAn9qGlRb2rjb106W5AkracYel/cKh qhO4qTZuhadfqctQ5xCgjbfUlX5EeGjS40EfIO5/Dpis3UV9tHtr5ShAIWcmjgRgp97zizt1cIQq XyE3lOAXgfwL2qluRjpxU4ajTTX+Ufpgo/CEaUKXGU4xaWcV2D7QdvezUREeeynVXcYiI5dQU/H/ 7+bEuufuGsdWId7w8U6PSiWRap/BB7slGw5ET2rV4xb4miQ3pMsa4fHHiHgCszGC8xBFELy2AgRk PCt0XTbxLaGfAxUr1ivNVJVi0uilccoEmpso/nwMBBfQdWypjt3GUjuq1FD/EXi2qyuZEI79l8ep 0yelo04BlU9pVYAgSELm/OuNatUelD6XS01ohUpiez9gxds7Ixw0BZkCfCq6h1AKofmpHVsTIlrO HfKQRJSPFSbMt0pBgVJIfga6I7uNQz20jJB97xxg2ys8XrDfCh6w/LKSWdsLcG5XGGSH1aIEYc7O XfxRAH/qLn/+9vA8/VjQoV1Ju6G/7KxOHCeT2/xB5oiJNE2C2d9ovVpfGWh6vklnoOU+Ms+YeBQu WHMgP5UzsnxG2TiwO2HAXn4G5+ZzGolcXblfoIRglc4mQpUL0sVbfOakTLz29Aioj8kMPiF7CnxN 9pLa/0S8onxH1FH6yoM/DOf08Nv8th/+nsuOr4TZApyl5+yyXV8J8iY7UVI08VxlYWCjjpTxa2mv U7ODaq9qLNVo+31pJYQiTcYAitsNJXoAit4MZ5B+/3nCOu0m1mOo8FY6ZuQbjx5uu/lSp+akMcBY g7jqMeHvuGe6mjVb6W9LUNy3sXS5gmP7n3d79/WTQalBGJ+60sM6Se8tjNSaIEBdGuJaEt13C1/h xQD+eo9Wy/K0nECCfMG25rUiIcPwiPXIvIBzrlNBWnvL3oLDJ8b1Hdbi4GyR6sV4KOqyUlgWyybS slMzRXC6FPDLFcbYARr051+l8oFE88gZByYF4Up79E4TXHJtANz2XKh4vORzSwN2R2nzy5QP7eSx XFI2bDeEE4wZsZ46JBmXl4YSvR/BlvzOCPgKJjUF/J7csXK0jLnj+ab9DVRX9jhZc89F/fAmrZUP DsWFmVfEw7bFQCv41MkP/gGOg/m2fJt+JWHheUyA4JnZT9lAKc1cHfZKpGRA1q3PQ4vMLeAKdpuw FPHJqVvyLhQDI4DtDntB+QI8vhncNW4aUgAGsRqZHQKVB9k72iirAJpP7HMHFMg0/JoVPCNwpisy UH3gpQX05D3kdcOCEOYem2HlH1Jf5054blnm8usQh3BnMCKCW9+1jYw8CUaiPTKLOMU4RJKNCmVu ZHN0cmVhbSAKZW5kb2JqIAoxNSAwIG9iaiAKPDwKL1IgMwovUCAtMzkwNAovTyAoo1ekEBK+/ZTS n6wxn8608lxiqMA3ZajbwDeY3cppNXoLKQovRmlsdGVyIC9TdGFuZGFyZAovTGVuZ3RoIDEyOAov ViAyCi9VICg3bfIAevbOEySIvQuRywvWAAAAAAAAAAAAAAAAAAAAACkKPj4KZW5kb2JqIAoxNiAw IG9iaiAKPDwKL1RpdGxlICiNI3Z6c9zRyffeoZlRiHthp+gSvIO8kaf03mfIjO5WXHSBGchx2gIu 2FOy0RmppJbBG2gxbWn+JzVYdfwqX5H51TWMV35vSVIi6wvvb7RKElxmXHTZ0/2XLn6PHuBS3Q/w QLbOnpcidlZKD+SEYMxueWasvDnvbAscTI+0D9+hG72/de0LFANwu8JCQMJXhoRM+mFMOffS0iax PReAYKK7N4jWWRtEQbGMiDvdz3earBSCbCkKL1Byb2R1Y2VyICisOGxxIJWlyvWIj8tYnWU1xNE+ hM//kb2g1W/OnbwCAMgazTreTCSdW6DBVbKxlsIaeXk/aPstZ0IariNWzbydcI9VeH9ZESLwQu9o u01GXFwY3sLl0npigl/4E94D71i22pOYN2EXSg7uyibWfCxgofk7qTsaBkyPuBbXo1xuoa84KQov Q3JlYXRpb25EYXRlICiLbTNmY4HBlqmY9YpcdN44dCkKPj4KZW5kb2JqIHhyZWYKMCAxNwowMDAw MDAwMDAwIDY1NTM1IGYgCjAwMDAwMDAwMTUgMDAwMDAgbiAKMDAwMDAwMDA2NiAwMDAwMCBuIAow MDAwMDAwMzIxIDAwMDAwIG4gCjAwMDAwMDE3NjUgMDAwMDAgbiAKMDAwMDAwMjQ3MCAwMDAwMCBu IAowMDAwMDA2MDcyIDAwMDAwIG4gCjAwMDAwMDk3NzMgMDAwMDAgbiAKMDAwMDAwMDE3MyAwMDAw MCBuIAowMDAwMDAwMjUzIDAwMDAwIG4gCjAwMDAwMDA0MjggMDAwMDAgbiAKMDAwMDAwMTg3MiAw MDAwMCBuIAowMDAwMDAyNTc3IDAwMDAwIG4gCjAwMDAwMDYxNzkgMDAwMDAgbiAKMDAwMDAwOTg4 MCAwMDAwMCBuIAowMDAwMDEyODQyIDAwMDAwIG4gCjAwMDAwMTI5OTIgMDAwMDAgbiAKdHJhaWxl cgoKPDwKL0VuY3J5cHQgMTUgMCBSCi9JbmZvIDE2IDAgUgovUm9vdCAxIDAgUgovU2l6ZSAxNwov SUQgWzwyNTYxZTE2MDBkMmZmY2VhOTM0Njc0YzI0NGY2OGY5OD48ODM1N2VjN2IxNmU4MGUzOTc4 NmFjMzY1YTE0ZDQzNDY+XQo+PgpzdGFydHhyZWYKMTMzODEKJSVFT0YK ------=_NextPart_000_0007_01C80696.03BAE460-- From Baciulisyhvn@aerohost.us Thu Oct 04 12:37:59 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdTi3-00072Z-J4 for nemo-archive@lists.ietf.org; Thu, 04 Oct 2007 12:37:59 -0400 Received: from [122.161.87.165] (helo=[122.161.89.179]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdThz-0005ly-JT for nemo-archive@lists.ietf.org; Thu, 04 Oct 2007 12:37:56 -0400 Received: from baijal ([162.150.55.24] helo=baijal) by [122.161.89.179] ( sendmail 8.13.3/8.13.1) with esmtpa id 1XFOer-000LHQ-lQ for nemo-archive@lists.ietf.org; Thu, 4 Oct 2007 22:08:11 +05-30 Message-ID: <000201c806a4$e9d78d00$b359a17a@baijal> From: "dermont Baciulis" To: Subject: fuutou Date: Thu, 4 Oct 2007 22:07:54 +05-30 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C806D3.038FC900" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.7 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0003_01C806D3.038FC900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://eckounilt.com/ Hi nemo-archive Did you know.. 88% of ladies want a man that is big, they say its more = fulfilling dermont Baciulis ------=_NextPart_000_0003_01C806D3.038FC900 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://eckounilt.com/
Hi nemo-archive
Did you know.. 88% of ladies want a man that = is big,=20 they say its more fulfilling
dermont Baciulis
------=_NextPart_000_0003_01C806D3.038FC900-- From AdelenucleolusCope@gasupreme.us Thu Oct 04 15:29:38 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdWOA-00071g-5R for nemo-archive@lists.ietf.org; Thu, 04 Oct 2007 15:29:38 -0400 Received: from pool-71-243-90-39.bos.east.verizon.net ([71.243.90.39] helo=carver1.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IdWO9-00038h-Tn for nemo-archive@lists.ietf.org; Thu, 04 Oct 2007 15:29:38 -0400 Received: from madame by gasupreme.us with SMTP id MvtEjEqviN for ; Thu, 4 Oct 2007 15:27:09 +0500 From: "Chris Ledbetter" To: Subject: Our casino is for you who likes to win! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Visit and start seeing the dollars coming. Best offer in gambling history . Visit and start seeing the dollars coming. Players from the United States and around the world! http://trynetgambling.net/ From armand275@mindpage.com Thu Oct 04 22:27:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idcv1-0006eL-3N for nemo-archive@lists.ietf.org; Thu, 04 Oct 2007 22:27:59 -0400 Received: from c-71-225-245-125.hsd1.pa.comcast.net ([71.225.245.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idcuq-0002iH-Uf for nemo-archive@lists.ietf.org; Thu, 04 Oct 2007 22:27:55 -0400 Received: from steve-8td74hb61 ([136.123.159.53] helo=steve-8td74hb61) by [71.225.245.125] ( sendmail 8.13.3/8.13.1) with esmtpa id 1XhShV-000DOR-Zd for nemo-archive@lists.ietf.org; Thu, 4 Oct 2007 22:26:35 -0400 Message-ID: <000301c806f7$1cd29270$7df5e147@steve8td74hb61> From: "armand kvaska" To: Subject: unbanked Date: Thu, 4 Oct 2007 22:26:19 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C806D5.95C0F270" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0008_01C806D5.95C0F270 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://suavehair.com/ Yo man nemo-archive Rated #1 for effectiveness and value armand kvaska ------=_NextPart_000_0008_01C806D5.95C0F270 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://suavehair.com/
Yo man nemo-archive
Rated #1 for effectiveness and = value
armand kvaska
------=_NextPart_000_0008_01C806D5.95C0F270-- From craft@scadawise.com Fri Oct 05 10:21:27 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ido3T-0003Lj-3O for nemo-archive@lists.ietf.org; Fri, 05 Oct 2007 10:21:27 -0400 Received: from [196.202.196.246] (helo=[196.202.196.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ido3M-0007Tn-H1 for nemo-archive@lists.ietf.org; Fri, 05 Oct 2007 10:21:23 -0400 Received: from op-met-acdc by scadawise.com with ASMTP id AB349E8E for ; Fri, 5 Oct 2007 17:22:09 +0300 Received: from op-met-acdc ([131.170.133.40]) by scadawise.com with ESMTP id C4B13C61DB36 for ; Fri, 5 Oct 2007 17:22:09 +0300 Message-ID: <000b01c8075b$16332c90$f6c4cac4@opmetacdc> From: "Hurit craft" To: Subject: ihtavala Date: Fri, 5 Oct 2007 17:21:57 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C80774.3B806490" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.7 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0006_01C80774.3B806490 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://stasuzuki.com/ Yo nemo-archive You get astonishingly fast penis enlargement results Hurit craft ------=_NextPart_000_0006_01C80774.3B806490 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://stasuzuki.com/
Yo nemo-archive
You get astonishingly fast penis enlargement = results
Hurit craft
------=_NextPart_000_0006_01C80774.3B806490-- From nemo-bounces@ietf.org Fri Oct 05 16:29:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdtmG-0003nb-2I; Fri, 05 Oct 2007 16:28:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdtmE-0003lh-3r; Fri, 05 Oct 2007 16:28:02 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdtmD-0003H9-Ee; Fri, 05 Oct 2007 16:28:01 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l95KRPZJ018268; Fri, 5 Oct 2007 23:27:37 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Oct 2007 23:26:54 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Oct 2007 15:26:49 -0500 Received: from 172.19.244.153 ([172.19.244.153]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 5 Oct 2007 20:26:49 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Fri, 05 Oct 2007 15:27:02 -0500 From: Basavaraj Patil To: ext Hesham Soliman , , Message-ID: Thread-Topic: [Mip6] DSMIPv6 current status Thread-Index: AcgBgqIJjZqP202ZRrGw4qdcNw30CQGC3Q23 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Oct 2007 20:26:49.0851 (UTC) FILETIME=[0F00A4B0:01C8078E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [nemo] Re: [Mip6] DSMIPv6 current status X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Hesham, Thanks for the update. Can we expect a revised I-D with all the LC comments addressed sometime in the next week or so? Assuming we can get the IKE issue dealt with as well. -Raj On 9/27/07 10:49 PM, "ext Hesham Soliman" wrote: > Folks, > > Just a quick progress on the draft. There is currently one issue being > discussed, which is the use of IKE in DSMIPv6. This was raised by Christian > last week. Other than that, all the comments are pretty straight forward. > > I'll send an update with one or more proposals soon. > > Hesham > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 From nemo-bounces@ietf.org Fri Oct 05 22:14:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idz9o-0000QC-Ss; Fri, 05 Oct 2007 22:12:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idz9m-0000DW-Bu; Fri, 05 Oct 2007 22:12:42 -0400 Received: from omta01ps.mx.bigpond.com ([144.140.82.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idz9c-0005Qc-11; Fri, 05 Oct 2007 22:12:38 -0400 Received: from oaamta06ps.mx.bigpond.com ([124.190.106.219]) by omta01ps.mx.bigpond.com with ESMTP id <20071006021148.ECKB13408.omta01ps.mx.bigpond.com@oaamta06ps.mx.bigpond.com>; Sat, 6 Oct 2007 02:11:48 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta06ps.mx.bigpond.com with ESMTP id <20071006021143.KQKZ12669.oaamta06ps.mx.bigpond.com@PC20005>; Sat, 6 Oct 2007 02:11:43 +0000 From: "Hesham Soliman" To: "'Basavaraj Patil'" , , Date: Sat, 6 Oct 2007 12:11:35 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgBgqIJjZqP202ZRrGw4qdcNw30CQGC3Q23AAwAkmA= In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Subject: [nemo] RE: [Mip6] DSMIPv6 current status X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Raj, Yes, all other comments are included. It would be great if we can handle the IKE issue soon, I'm trying to come up with solutions, I encourage others to do the same. Hesham > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > Sent: Saturday, October 06, 2007 6:27 AM > To: ext Hesham Soliman; mip6@ietf.org; nemo@ietf.org > Subject: Re: [Mip6] DSMIPv6 current status > > > Hi Hesham, > > Thanks for the update. Can we expect a revised I-D with all > the LC comments > addressed sometime in the next week or so? Assuming we can > get the IKE issue > dealt with as well. > > -Raj > > > On 9/27/07 10:49 PM, "ext Hesham Soliman" > wrote: > > > Folks, > > > > Just a quick progress on the draft. There is currently one > issue being > > discussed, which is the use of IKE in DSMIPv6. This was > raised by Christian > > last week. Other than that, all the comments are pretty > straight forward. > > > > I'll send an update with one or more proposals soon. > > > > Hesham > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > From steffeyludoh@afbainternational.com Fri Oct 05 22:57:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idzqq-0003wu-L5 for nemo-archive@lists.ietf.org; Fri, 05 Oct 2007 22:57:13 -0400 Received: from [88.249.56.103] (helo=dsl88-249-14439.ttnet.net.tr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idzqd-0006U9-V8 for nemo-archive@lists.ietf.org; Fri, 05 Oct 2007 22:57:01 -0400 Received: from yeni by afbainternational.com with ASMTP id FBDC183D for ; Fri, 5 Oct 2007 05:53:51 +0300 Received: from yeni ([107.161.7.46]) by afbainternational.com with ESMTP id 546154AD5E17 for ; Fri, 5 Oct 2007 05:53:51 +0300 Message-ID: <000d01c806fa$e6781840$6738f958@yeni> From: "Ivelisse steffey" To: nemo-archive@lists.ietf.org Subject: avappaz Date: Fri, 5 Oct 2007 05:53:25 +0300 Message-ID: <000d01c806fa$e6781840$6738f958@yeni> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.7 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Whats up nemo-archive You only live once so why not be the best that you can be? Ivelisse steffey http://streemteen.com/ From Leukkunenftva@aiyaaa.com Sat Oct 06 12:36:22 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeCda-0003F0-Nq for nemo-archive@lists.ietf.org; Sat, 06 Oct 2007 12:36:22 -0400 Received: from host69-73-dynamic.58-82-r.retail.telecomitalia.it ([82.58.73.69] helo=[87.2.125.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IeCdR-00022W-3F for nemo-archive@lists.ietf.org; Sat, 06 Oct 2007 12:36:13 -0400 Received: by 10.49.170.169 with SMTP id vGxAwFcBPXkZd; Sat, 6 Oct 2007 18:36:23 +0200 (GMT) Received: by 192.168.188.184 with SMTP id hecwaEQdbNkSbg.9186362894726; Sat, 6 Oct 2007 18:36:21 +0200 (GMT) Message-ID: <000701c80837$057e0eb0$647d0257@cucina> From: "Kiyoon Leukkunen" To: Subject: abgelege Date: Sat, 6 Oct 2007 18:36:18 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C80847.C906DEB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0006_01C80847.C906DEB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.mnmgops.com/ Morning nemo-archive proven to be safe and very effective Kiyoon Leukkunen ------=_NextPart_000_0006_01C80847.C906DEB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.mnmgops.com/
Morning nemo-archive
proven to be safe and very = effective
Kiyoon Leukkunen
------=_NextPart_000_0006_01C80847.C906DEB0-- From Jacqui-kiefer@SENTURYLENDING.COM Sat Oct 06 17:35:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeHIe-0006hO-44 for nemo-archive@lists.ietf.org; Sat, 06 Oct 2007 17:35:04 -0400 Received: from [77.251.83.73] (helo=dhcp-077-251-083-073.chello.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IeHIc-0007HH-Mm for nemo-archive@lists.ietf.org; Sat, 06 Oct 2007 17:35:04 -0400 Received: from your-211cfb4c82 ([134.135.93.89]:6817 "EHLO your-211cfb4c82" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by dhcp-077-251-083-073.chello.nl with ESMTP id S22DOAQNSGKLQFRM (ORCPT ); Sat, 6 Oct 2007 23:35:09 +0200 Message-ID: <000b01c80860$be626060$4953fb4d@your211cfb4c82> From: "Jacqui kiefer" To: Subject: kitsa Date: Sat, 6 Oct 2007 23:34:58 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C80871.81EB3060" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0003_01C80871.81EB3060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.muias.com/ What's up nemo-archive A girl once told me i was to small, im the one laughing now Jacqui kiefer ------=_NextPart_000_0003_01C80871.81EB3060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.muias.com/
What's up nemo-archive
A girl once told me i was to small, im the one = laughing now
Jacqui kiefer
------=_NextPart_000_0003_01C80871.81EB3060-- From chelle8369@nojima.co.jp Sat Oct 06 19:00:01 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeIcr-0006RI-FN for nemo-archive@lists.ietf.org; Sat, 06 Oct 2007 19:00:01 -0400 Received: from [209.126.134.18] (helo=wpev) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IeIcg-0000Z2-Gv for nemo-archive@lists.ietf.org; Sat, 06 Oct 2007 18:59:51 -0400 Received: from yfq ([236.97.153.106]) by wpev with Microsoft SMTPSVC(6.0.3790.0); Sat, 6 Oct 2007 15:49:03 -0700 Message-ID: <470810DF.8010706@nojima.co.jp> Date: Sat, 6 Oct 2007 15:49:03 -0700 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: looking for this? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.3 (+++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Fearless International Breaks Out! FEARLESS INTL INC (f r l e) $0.21 This one is moving fast as the word is out on this hot new company. This coming week will be huge for investors. Get moving on FRLE first thing Monday. From Creechwfu@artpix.ca Sun Oct 07 04:00:47 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeR4B-0004j1-Ii for nemo-archive@lists.ietf.org; Sun, 07 Oct 2007 04:00:47 -0400 Received: from [88.230.193.119] (helo=[88.231.201.103]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IeR46-0005MN-3I for nemo-archive@lists.ietf.org; Sun, 07 Oct 2007 04:00:42 -0400 Received: from grnt ([195.121.6.162] helo=grnt) by [88.231.201.103] ( sendmail 8.13.3/8.13.1) with esmtpa id 1XHmcW-000LKR-rD for nemo-archive@lists.ietf.org; Sun, 7 Oct 2007 10:58:22 +0300 Date: Sun, 7 Oct 2007 10:57:56 +0300 From: "lorimer Creech" Reply-To: "lorimer Creech" Message-ID: <433885584169.393961830981@artpix.ca> To: Subject: tsaocwsn MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-9"; reply-type=original X-Antivirus: avast! (VPS 000778-5, 06.10.2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 4.0 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea How it is going nemo-archive African tribes take these herbs all the time, this is why they have such big cocks! lorimer Creech http://mwtscm.com/ From Hontrakqcde@epa-services.co.uk Mon Oct 08 03:07:48 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IemiS-0003Qk-Rg for nemo-archive@lists.ietf.org; Mon, 08 Oct 2007 03:07:48 -0400 Received: from gld14.internetdsl.tpnet.pl ([83.3.29.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IemiQ-00046N-Al for nemo-archive@lists.ietf.org; Mon, 08 Oct 2007 03:07:46 -0400 Received: from woda ([149.116.120.61] helo=woda) by gld14.internetdsl.tpnet.pl ( sendmail 8.13.3/8.13.1) with esmtpa id 1TjFoH-000YVI-Ig for nemo-archive@lists.ietf.org; Mon, 8 Oct 2007 09:08:11 +0200 Message-ID: <000a01c80979$ed523660$0e1d0353@woda> From: "moe Hontrak" To: Subject: etmreawe Date: Mon, 8 Oct 2007 09:07:45 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C8098A.B0DB0660" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0009_01C8098A.B0DB0660 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable http://pocrises.com/ Nice to meet you nemo-archive its the size of ones penis that determines success moe Hontrak ------=_NextPart_000_0009_01C8098A.B0DB0660 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
http://pocrises.com/
Nice to meet you nemo-archive
its the size of ones penis that determines = success
moe Hontrak
------=_NextPart_000_0009_01C8098A.B0DB0660-- From gregory8hall84@56.com Mon Oct 08 09:33:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IesjP-0002lN-B4 for nemo-archive@lists.ietf.org; Mon, 08 Oct 2007 09:33:11 -0400 Received: from [87.120.123.87] (helo=87.120.123.87) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iesj5-0007Md-SY for nemo-archive@lists.ietf.org; Mon, 08 Oct 2007 09:33:11 -0400 Received: from [87.120.123.87] by ufksv.56.com; Mon, 08 Oct 2007 13:32:39 +0000 Message-ID: <000601c809af$0496ea1f$9a9c0098@fksvoc> From: "Eugene Newsome" To: "Cecilia White" Subject: Fwd: Thanks, we accepted your business loan request Date: Mon, 08 Oct 2007 11:45:16 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C809AF.0491E13D" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 2.7 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C809AF.0491E13D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you have your own business and require IMMEDIATE cash to spend ANY = way you like or want Extra money to give your business a boost or need A = low interest loan - NO STRINGS ATTACHED, here is best deal we can offer = you TONIGHT (hurry, this offer will expire THIS EVENING):   $51,000+ loan   Hurry, when our best deal is gone, it is gone. Simply Call Us Free on=20 877-292-6896 ------=_NextPart_000_0003_01C809AF.0491E13D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If you have your own business and = require IMMEDIATE cash to spend ANY way you like or want Extra money to = give your business a boost or need A low interest loan - NO STRINGS = ATTACHED, here is best deal we can offer you TONIGHT (hurry, this offer = will expire THIS EVENING):
=20
 
$51,000+ loan
 
Hurry, when our best deal is gone, it = is gone. Simply Call Us Free on 877-292-6896
------=_NextPart_000_0003_01C809AF.0491E13D-- From hossrpfl@celticheritage.com Mon Oct 08 15:23:35 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeyCV-0003TX-B4 for nemo-archive@lists.ietf.org; Mon, 08 Oct 2007 15:23:35 -0400 Received: from m123.net195-132-110.noos.fr ([195.132.110.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IeyCJ-0001kj-25 for nemo-archive@lists.ietf.org; Mon, 08 Oct 2007 15:23:29 -0400 Received: from mambé ([124.127.12.116] helo=mambé) by m123.net195-132-110.noos.fr ( sendmail 8.13.3/8.13.1) with esmtpa id 1wjCxO-000SBC-tR for nemo-archive@lists.ietf.org; Tue, 9 Oct 2007 05:23:17 +1000 Message-ID: <000901c809e0$a697a720$7b6e84c3@mamb> From: "Luuk hoss" To: Subject: neteklet Date: Tue, 9 Oct 2007 05:23:05 +1000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C80A34.7843B720" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Antivirus: avast! (VPS 000775-2, 18/09/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0003_01C80A34.7843B720 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.nickbut.com/ Evening nemo-archive Do you use extra large condoms? Luuk hoss ------=_NextPart_000_0003_01C80A34.7843B720 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.nickbut.com/
Evening nemo-archive
Do you use extra large condoms?
Luuk hoss
------=_NextPart_000_0003_01C80A34.7843B720-- From nemo-bounces@ietf.org Mon Oct 08 21:16:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1If3fq-00084S-BO; Mon, 08 Oct 2007 21:14:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1If3fm-00080j-UF; Mon, 08 Oct 2007 21:14:10 -0400 Received: from bosco.isi.edu ([128.9.168.207]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1If3fm-0006L1-GP; Mon, 08 Oct 2007 21:14:10 -0400 Received: by bosco.isi.edu (Postfix, from userid 70) id 1E108E667E; Mon, 8 Oct 2007 18:09:33 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20071009010933.1E108E667E@bosco.isi.edu> Date: Mon, 8 Oct 2007 18:09:33 -0700 (PDT) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: nemo@ietf.org, rfc-editor@rfc-editor.org Subject: [nemo] RFC 4980 on Analysis of Multihoming in Network Mobility Support X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4980 Title: Analysis of Multihoming in Network Mobility Support Author: C. Ng, T. Ernst, E. Paik, M. Bagnulo Status: Informational Date: October 2007 Mailbox: chanwah.ng@sg.panasonic.com, thierry.ernst@inria.fr, euna@kt.co.kr, marcelo@it.uc3m.es Pages: 39 Characters: 88572 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-nemo-multihoming-issues-07.txt URL: http://www.rfc-editor.org/rfc/rfc4980.txt This document is an analysis of multihoming in the context of network mobility (NEMO) in IPv6. As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. The possible deployment scenarios of multihomed mobile networks are described together with the associated issues when network mobility is supported by RFC 3963 (NEMO Basic Support). Recommendations are offered on how to address these issues. This memo provides information for the Internet community. This document is a product of the Network Mobility Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From huxley7bertrand03@brusty.com Tue Oct 09 11:03:07 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfGbz-00006W-NS for nemo-archive@lists.ietf.org; Tue, 09 Oct 2007 11:03:07 -0400 Received: from cp159984-c.dbsch1.nb.home.nl ([84.27.116.198]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfGbx-0005T6-7t for nemo-archive@lists.ietf.org; Tue, 09 Oct 2007 11:03:05 -0400 Received: from [84.27.116.198] by megjjv.brusty.com; Tue, 09 Oct 2007 14:49:57 +0000 Message-ID: <000a01c80a83$01533e67$dbf0449f@mmegjjvn> From: "Sherman Hanks" To: "Kitty Park" Subject: Fwd: Thanks, we are ready to lend money regardless of Credit Date: Tue, 09 Oct 2007 13:02:34 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C80A83.0151EBCA" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C80A83.0151EBCA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you have your own business and require IMMEDIATE money to spend ANY = way you like or want Extra money to give the company a boost or need A = low interest loan - NO STRINGS ATTACHED, here is best deal we can offer = you NOW (hurry, this offer will expire THIS NIGHT):   $29,000+ loan   Hurry, when our deal is gone, it is gone. Simply Call Us Free on=20 877-292-6896 ------=_NextPart_000_0007_01C80A83.0151EBCA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If you have your own business and = require IMMEDIATE money to spend ANY way you like or want Extra money to = give the company a boost or need A low interest loan - NO STRINGS = ATTACHED, here is best deal we can offer you NOW (hurry, this offer will = expire THIS NIGHT):
=20
 
$29,000+ loan
 
Hurry, when our deal is gone, it is = gone. Simply Call Us Free on 877-292-6896
------=_NextPart_000_0007_01C80A83.0151EBCA-- From chi-yaoromy28@bulgarian-online-school.com Tue Oct 09 13:21:29 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfIlt-00036l-5w for nemo-archive@lists.ietf.org; Tue, 09 Oct 2007 13:21:29 -0400 Received: from [189.25.58.50] (helo=18925058050.user.veloxzone.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfIls-0008S9-Bz for nemo-archive@lists.ietf.org; Tue, 09 Oct 2007 13:21:29 -0400 Received: from [189.25.58.50] by efqdyky.bulgarian-online-school.com; Tue, 09 Oct 2007 17:20:39 +0000 Message-ID: <000501c80a98$078b8774$6abab08a@efqdykyg> From: "Nelda Bullard" To: "Madge Keyes" Subject: Re: Thank you, we are ready to lend money Date: Tue, 09 Oct 2007 15:33:17 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C80A98.0786A72D" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 2.3 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C80A98.0786A72D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you have your own business and wish IMMEDIATE money to spend ANY way = you like or want Extra money to give the company a boost or require A = low interest loan - NO STRINGS ATTACHED, here is our deal we can offer = you NOW (hurry, this tender will expire NOW):   $39,000+ loan   Hurry, when our deal is gone, it is gone. Simply Call Us Free on=20 877-292-6896 ------=_NextPart_000_0002_01C80A98.0786A72D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If you have your own business and wish = IMMEDIATE money to spend ANY way you like or want Extra money to give = the company a boost or require A low interest loan - NO STRINGS = ATTACHED, here is our deal we can offer you NOW (hurry, this tender will = expire NOW):
=20
 
$39,000+ loan
 
Hurry, when our deal is gone, it is = gone. Simply Call Us Free on 877-292-6896
------=_NextPart_000_0002_01C80A98.0786A72D-- From Alecia@nordahl.vovve.net Tue Oct 09 18:39:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfNk1-0000dA-Qd for nemo-archive@lists.ietf.org; Tue, 09 Oct 2007 18:39:53 -0400 Received: from manz-4d00bf5d.pool.mediaways.net ([77.0.191.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfNjt-0006kc-F2 for nemo-archive@lists.ietf.org; Tue, 09 Oct 2007 18:39:51 -0400 Received: from DANIEL ([107.126.87.140]:27519 "EHLO DANIEL" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by manz-4d00bf5d.pool.mediaWays.net with ESMTP id S22NIGRXZGBPKYUO (ORCPT ); Wed, 10 Oct 2007 00:40:10 +0200 Message-ID: <000801c80ac5$4681dcd0$5dbf004d@DANIEL> From: "Alecia Ridley" To: Subject: diehtoz Date: Wed, 10 Oct 2007 00:39:38 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C80AD6.0A0AACD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.9 (++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f ------=_NextPart_000_0006_01C80AD6.0A0AACD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.reggetkn.com/ Morning nemo-archive Ladies, here is the ultimate gift for your men, used by p0rnstarrs = worldwide Alecia Ridley ------=_NextPart_000_0006_01C80AD6.0A0AACD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.reggetkn.com/
Morning nemo-archive
Ladies, here is the ultimate gift for your = men, used by=20 p0rnstarrs worldwide
Alecia Ridley
------=_NextPart_000_0006_01C80AD6.0A0AACD0-- From janicebromee@theinternet-guys.com Wed Oct 10 06:23:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfYjJ-0007WQ-6Z for nemo-archive@lists.ietf.org; Wed, 10 Oct 2007 06:23:53 -0400 Received: from bzq-79-182-227-96.red.bezeqint.net ([79.182.227.96] helo=bzq-79-182-235-101.red.bezeqint.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfYj2-0003Ux-JS for nemo-archive@lists.ietf.org; Wed, 10 Oct 2007 06:23:43 -0400 Received: from DRAGON by theinternet-guys.com with ASMTP id A3B87FA7 for ; Wed, 10 Oct 2007 12:23:35 +0200 Received: from DRAGON ([158.124.139.124]) by theinternet-guys.com with ESMTP id 9F9769DCA1FC for ; Wed, 10 Oct 2007 12:23:35 +0200 Message-ID: <000701c80b27$956c4530$65ebb64f@DRAGON> From: "janice bromee" To: Subject: onbeslag Date: Wed, 10 Oct 2007 12:23:21 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C80B38.58F51530" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.0 (++++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0003_01C80B38.58F51530 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable http://realvideoz.com/ Good evening nemo-archive Men are going to love this product... janice bromee ------=_NextPart_000_0003_01C80B38.58F51530 Content-Type: text/html; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable
http://realvideoz.com/
Good evening nemo-archive
Men are going to love this = product...
janice bromee
------=_NextPart_000_0003_01C80B38.58F51530-- From fabio_carvalho@discovery-group.com Wed Oct 10 15:27:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfhDb-0007Da-Br for nemo-archive@lists.ietf.org; Wed, 10 Oct 2007 15:27:43 -0400 Received: from ccd199.neoplus.adsl.tpnet.pl ([83.30.127.199]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IfhDR-0005qp-HM for nemo-archive@lists.ietf.org; Wed, 10 Oct 2007 15:27:40 -0400 Received: from kow ([207.205.233.239]) by ccd199.neoplus.adsl.tpnet.pl (8.13.5/8.13.5) with SMTP id l9AJUNkd026018; Wed, 10 Oct 2007 21:30:23 +0200 Message-ID: <470D2790.7030003@discovery-group.com> Date: Wed, 10 Oct 2007 21:27:12 +0200 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: here ya go Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Free games, What more do we need to say? http://24.232.64.228/ From rosamaravillosa22@uwaterloo.ca Thu Oct 11 01:01:55 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfqBH-0002is-LD for nemo-archive@lists.ietf.org; Thu, 11 Oct 2007 01:01:55 -0400 Received: from pool-71-247-131-250.nycmny.east.verizon.net ([71.247.131.250]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IfqB8-0007YZ-82 for nemo-archive@lists.ietf.org; Thu, 11 Oct 2007 01:01:53 -0400 Received: from foe ([177.41.34.52]) by pool-71-247-131-250.nycmny.east.verizon.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Oct 2007 01:01:21 -0400 Message-ID: <002a01c80bc3$c3ea2750$342229b1@foe> From: To: Subject: here ya go Date: Thu, 11 Oct 2007 01:01:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Time to stop paying for the net, get ONE THOUSAND FREE GAMES! http://220.134.52.160/ From LenaNekkanti@ncel.com Thu Oct 11 01:33:44 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifqg4-0007Cl-Ql for nemo-archive@lists.ietf.org; Thu, 11 Oct 2007 01:33:44 -0400 Received: from p54828682.dip0.t-ipconnect.de ([84.130.134.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifqg0-0003MJ-5y for nemo-archive@lists.ietf.org; Thu, 11 Oct 2007 01:33:40 -0400 Received: from klaeranlage ([119.169.125.60] helo=klaeranlage) by p54828682.dip0.t-ipconnect.de ( sendmail 8.13.3/8.13.1) with esmtpa id 1Unryp-000GUW-SE for nemo-archive@lists.ietf.org; Thu, 11 Oct 2007 07:35:10 +0200 Message-ID: <000701c80bc8$74ed1b80$82868254@klaeranlage> From: "Lena Nekkanti" To: Subject: owyenneb Date: Thu, 11 Oct 2007 07:34:56 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C80BD9.3875EB80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f ------=_NextPart_000_0004_01C80BD9.3875EB80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.baloidse.com/ Hi there nemo-archive what the hell! she didnt have an orgasm again! take action today and do = something about it. Lena Nekkanti ------=_NextPart_000_0004_01C80BD9.3875EB80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.baloidse.com/
Hi there nemo-archive
what the hell! she didnt have an orgasm again! = take=20 action today and do something about it.
Lena Nekkanti
------=_NextPart_000_0004_01C80BD9.3875EB80-- From Haley742@wholesalecanada.ca Thu Oct 11 14:55:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig3By-0002GC-95 for nemo-archive@lists.ietf.org; Thu, 11 Oct 2007 14:55:30 -0400 Received: from ya648.y.pppool.de ([89.60.166.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig3Bq-0007rh-ND for nemo-archive@lists.ietf.org; Thu, 11 Oct 2007 14:55:30 -0400 Received: from yellow ([150.116.60.20] helo=yellow) by Ya648.y.pppool.de ( sendmail 8.13.3/8.13.1) with esmtpa id 1fhRGt-000QQS-nm for nemo-archive@lists.ietf.org; Thu, 11 Oct 2007 20:55:51 +0200 Message-ID: <5ABA8C25.AB6D5B1E@wholesalecanada.ca> Date: Thu, 11 Oct 2007 20:55:20 +0200 From: "Haley misztal" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: uedosten Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed hello beautiful nemo-archive you'll wake the kids, sound familiar? Haley misztal http://www.bitoffon.com/ From Cromieordb@proatomic.com.au Thu Oct 11 23:05:06 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgApm-0008Ci-Cn for nemo-archive@lists.ietf.org; Thu, 11 Oct 2007 23:05:06 -0400 Received: from [58.172.250.136] (helo=[58.172.249.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgApg-0000a0-QS for nemo-archive@lists.ietf.org; Thu, 11 Oct 2007 23:05:02 -0400 Received: from jeff ([143.191.82.138] helo=jeff) by [58.172.249.207] ( sendmail 8.13.3/8.13.1) with esmtpa id 1kAUWp-000BTE-xM for nemo-archive@lists.ietf.org; Fri, 12 Oct 2007 13:11:28 +1000 Message-ID: <000901c80c7d$828811e0$cff9ac3a@jeff> From: "nat Cromie" To: Subject: nickeler Date: Fri, 12 Oct 2007 13:10:58 +1000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C80CD1.543421E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.0 (++++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 ------=_NextPart_000_0008_01C80CD1.543421E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Greetings nemo-archive 1, 2 oh no 3 orgasms! WOW you can have them too nat Cromie http://www.bloglfux.com/ ------=_NextPart_000_0008_01C80CD1.543421E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Greetings nemo-archive
1, 2 oh no 3 orgasms! WOW you can have them = too
nat Cromie
http://www.bloglfux.com/ ------=_NextPart_000_0008_01C80CD1.543421E0-- From naeslundgyzug@trentnathan.com.au Fri Oct 12 11:29:23 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgMS3-0008I0-Fa for nemo-archive@lists.ietf.org; Fri, 12 Oct 2007 11:29:23 -0400 Received: from [122.164.126.248] (helo=ABTS-TN-dynamic-082.127.164.122.airtelbroadband.in) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgMRk-0004yH-1q for nemo-archive@lists.ietf.org; Fri, 12 Oct 2007 11:29:04 -0400 Received: from system-iqxxjfje ([159.182.152.49]:9626 "EHLO system-iqxxjfje" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by ABTS-TN-dynamic-082.127.164.122.airtelbroadband.in with ESMTP id S22YDBJKOJGLQYMR (ORCPT ); Fri, 12 Oct 2007 20:59:35 +05-30 Message-ID: <000701c80ce4$a104eaf0$527fa47a@systemiqxxjfje> From: "Rick naeslund" To: Subject: kamijyuu Date: Fri, 12 Oct 2007 20:59:07 +05-30 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C80D12.BABD26F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.8 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0005_01C80D12.BABD26F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello buddy nemo-archive you think having an average sized cock is ok? Rick naeslund http://aomoco.com/ ------=_NextPart_000_0005_01C80D12.BABD26F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hello buddy nemo-archive
you think having an average sized cock is = ok?
Rick naeslund
http://aomoco.com/
------=_NextPart_000_0005_01C80D12.BABD26F0-- From Wan-crossland@mooseheadcampground.com Fri Oct 12 13:34:24 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgOP2-00070Y-5X for nemo-archive@lists.ietf.org; Fri, 12 Oct 2007 13:34:24 -0400 Received: from ffh114.internetdsl.tpnet.pl ([83.13.137.114]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgOOy-0001F1-6w for nemo-archive@lists.ietf.org; Fri, 12 Oct 2007 13:34:21 -0400 Received: from oem-ehbig4haf8a ([151.105.134.109] helo=oem-ehbig4haf8a) by ffh114.internetdsl.tpnet.pl ( sendmail 8.13.3/8.13.1) with esmtpa id 1MhfKy-000QKP-aW for nemo-archive@lists.ietf.org; Fri, 12 Oct 2007 19:34:52 +0200 Message-ID: <000601c80cf6$1b6410d0$72890d53@oemehbig4haf8a> From: "Wan crossland" To: Subject: trayat Date: Fri, 12 Oct 2007 19:34:14 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C80D06.DEECE0D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f ------=_NextPart_000_0003_01C80D06.DEECE0D0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable hello comrades nemo-archive CAUTION! she might be tight when you reach your new size, stretching may = be required Wan crossland http://www.amianrts.com/ ------=_NextPart_000_0003_01C80D06.DEECE0D0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
hello comrades nemo-archive
CAUTION! she might be tight when you reach = your new=20 size, stretching may be required
Wan crossland
http://www.amianrts.com/ ------=_NextPart_000_0003_01C80D06.DEECE0D0-- From Linkewxr@RIAA.com Fri Oct 12 17:11:54 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgRnW-0006gP-T6 for nemo-archive@lists.ietf.org; Fri, 12 Oct 2007 17:11:54 -0400 Received: from host-84-220-37-198.cust-adsl.tiscali.it ([84.220.37.198]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgRn4-00080B-5o for nemo-archive@lists.ietf.org; Fri, 12 Oct 2007 17:11:26 -0400 Received: from DIRETTA ([120.156.109.97]:25918 "EHLO DIRETTA" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [84.220.37.198] with ESMTP id S22FBARNORLUZPQR (ORCPT ); Fri, 12 Oct 2007 23:11:26 +0200 Message-ID: <000201c80d14$62fe0220$c625dc54@DIRETTA> From: "Allah Linke" To: Subject: ir|fnvej Date: Fri, 12 Oct 2007 23:10:58 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C80D25.2686D220" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.5 (+++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 ------=_NextPart_000_0008_01C80D25.2686D220 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello beautiful nemo-archive gigantic, heavyweight, king sized. Thats how my dick is now described Allah Linke http://aomoco.com/ ------=_NextPart_000_0008_01C80D25.2686D220 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hello beautiful nemo-archive
gigantic, heavyweight, king sized. Thats how = my dick is=20 now described
Allah Linke
http://aomoco.com/
------=_NextPart_000_0008_01C80D25.2686D220-- From glew@0612.net Fri Oct 12 18:11:37 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgSjJ-00060M-Eh for nemo-archive@lists.ietf.org; Fri, 12 Oct 2007 18:11:37 -0400 Received: from adsl-ull-161-166.47-151.net24.it ([151.47.166.161] helo=adsl-ull-138-161.47-151.net24.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgSj6-0000tM-5n for nemo-archive@lists.ietf.org; Fri, 12 Oct 2007 18:11:24 -0400 Received: from fd4m952m1jviar7 by 0612.net with ASMTP id EB392163 for ; Sat, 13 Oct 2007 00:11:37 +0200 Received: from fd4m952m1jviar7 ([135.186.125.127]) by 0612.net with ESMTP id 7CDD696F58D7 for ; Sat, 13 Oct 2007 00:11:37 +0200 Message-ID: <000801c80d1c$d309a850$09b52f97@fd4m952m1jviar7> From: "Cassie glew" To: Subject: amremm|t Date: Sat, 13 Oct 2007 00:11:23 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C80D2D.96927850" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 ------=_NextPart_000_0009_01C80D2D.96927850 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable whats popping nemo-archive think your a mack daddy? think again, you aint hittin it with that = twinky you call a dick. Cassie glew http://amrouz.com/ ------=_NextPart_000_0009_01C80D2D.96927850 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
whats popping nemo-archive
think your a mack daddy? think again, you aint = hittin it=20 with that twinky you call a dick.
Cassie glew
http://amrouz.com/
------=_NextPart_000_0009_01C80D2D.96927850-- From FlorachinSimons@clevelandclinic.org Sat Oct 13 10:49:41 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgiJB-0007l9-PF for nemo-archive@lists.ietf.org; Sat, 13 Oct 2007 10:49:41 -0400 Received: from c0d4201c3.dhcp.bluecom.no ([195.1.66.13] helo=eierb585f390c1.bluecom.no) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IgiJB-0004MV-Dz for nemo-archive@lists.ietf.org; Sat, 13 Oct 2007 10:49:41 -0400 Received: from starvation by clevelandclinic.org with SMTP id r86mg3OZPd for ; Sat, 13 Oct 2007 16:47:25 -0100 From: "Opal Albright" To: Subject: Download our casino in 20 seconds to get $2400 richer when you join. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Travel no further than your screen and get your free $2400! After thatit's only fun and winning. Come find out. Play your favorite games from the comfort of your home, USA players ARE included! http://casinocentreworld.net/ From obecdemandice@aircrew.com Sun Oct 14 14:38:33 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih8MD-0005Y7-LV for nemo-archive@lists.ietf.org; Sun, 14 Oct 2007 14:38:33 -0400 Received: from f048119103.adsl.alicedsl.de ([78.48.119.103]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ih8M7-0001gl-3P for nemo-archive@lists.ietf.org; Sun, 14 Oct 2007 14:38:33 -0400 Received: from kkjz ([143.126.172.226]) by f048119103.adsl.alicedsl.de with Microsoft SMTPSVC(6.0.3790.211); Sun, 14 Oct 2007 20:40:06 +0200 Message-ID: <47126286.3040507@aircrew.com> Date: Sun, 14 Oct 2007 20:40:06 +0200 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: I've got something you have to see Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 PPYH Moves To Be "King Kong" in "Hong Kong". Physical Property Holdings Inc. PPYH $0.25 Huge internal changes are paying off at PPYH as they move quickly in new direction. Some of Hong Kong.s most desired properties have already been acquired and their target list is growing. Monday will be a big day for this one, get your broker on it as the trading warms up. From nuxxvjd@boxwin.node.com Mon Oct 15 03:13:57 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhK9F-00074c-6T for nemo-archive@lists.ietf.org; Mon, 15 Oct 2007 03:13:57 -0400 Received: from adsl-76-217-91-192.dsl.emhril.sbcglobal.net ([76.217.91.192] helo=printech-ya5hyz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhK98-0004Qx-Ii for nemo-archive@lists.ietf.org; Mon, 15 Oct 2007 03:13:53 -0400 Received: from [76.217.91.192] by stover.node.com; Mon, 15 Oct 2007 01:11:42 -0600 From: "Millard Horne" To: Subject: Korean leaders sign peace pledge Date: Mon, 15 Oct 2007 01:11:42 -0600 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_000E_01C80EC8.58969210" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: Aca6QACHHWKRGXJB6QBCPS5UF96ZI5== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: <01c80ec8$58969210$c05bd94c@nuxxvjd> X-Spam-Score: 1.8 (+) X-Scan-Signature: b38aee91eedbacb27d28d558bc16c035 This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C80EC8.58969210 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01C80EC8.58969210" ------=_NextPart_001_000F_01C80EC8.58969210 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit BAGHDAD, Iraq (CNN) -- British Prime Minister Gordon Brown arrived in Baghdad on Tuesday for meetings with Iraqi government officials, the British Embassy in Baghdad said. Carol Ann Gotbaum may have accidentally strangled herself while trying to get out of her handcuffs, Phoenix Police Department spokesman Sgt. Andy Hill said Saturday. The tech-dominated Nasdaq also gained 1.5 percent for its highest close since February 2001 while the S&P 500 gained 1.3 percent. Hong Kong's Hang Sen was also up 3.89 percent -- gaining more than 1,000 points -- at 28,047. "You're seeing a continuation of the recent momentum," said Chris Johnson, CEO of Johnson Research Group. Someone close to Stiles told investigators Stiles is a "survivalist type" and always carries a weapon, Nye County District Attorney Bob Beckett said. "Sometime during the time she went into custody, she went into medical distress," he said. Stiles was a distant friend of the girl's family, De Meo said. "The mother has cooperated with us," De Meo said. "We believe that the mother was not aware of anything that went on with this young girl. It was very sad for her to find this out." "According to investigators, it appeared as though Ms. Gotbaum had possibly tried to manipulate the handcuffs from behind her to the front, got tangled up in the process, and they ended up around her neck area," he said. A spokeswoman for the Maricopa County medical examiner said an autopsy would be conducted Monday morning. "She's what you'd expect a little girl in elementary school to be like," he said. "You would never know something like that happened. Ever." Todd Allen, a Las Vegas resident, told CNN he once lived with the girl from the video and her mother. He said he recognizes his old apartment from scenes in the video. He said he knows the suspect because Allen's mother dated Stiles and the couple spent time together at Allen's apartment. Watch Allen describe Stiles and the girl » Witnesses told police that Gotbaum was "yelling and screaming" and running through the terminal Friday. She was arrested for disorderly conduct. (CNN) -- Darren Tuck, the man who gave police a tape depicting the rape of a 3-year-old girl, turned himself in Sunday to Nye County, Nevada, authorities. Betsy Gotbaum called Carol Ann Gotbaum "a wonderful, wonderful person" and a great mother. She said the family was dealing with the situation "the best way we can." Authorities have identified Chester A. Stiles, 37, as the suspect in the tape. A resident of Pahrump, Nevada, he remains at-large, De Meo said. Pahrump is about 60 miles west of Las Vegas. While handcuffed, the New Yorker became "disruptive" and she was taken to a holding room, where she was left alone, Hill told CNN affiliate KTVK. Investigators said officers went to check on her five to 10 minutes later. Police policy requires that be done every 15 minutes. Finding Gotbaum "unconscious and not breathing," Hill said, officers performed CPR. CNN and other news organizations did so until the child was found, and De Meo asked media to stop showing the picture. Gotbaum was the mother of three young children and the daughter-in-law of longtime New York City Public Advocate Betsy Gotbaum. Allen said nobody realized the child had been abused. Allen said he never witnessed Stiles physically assault anyone. "But I have seen him verbally and mentally assault many people," Allen told CNN. "He's good with mind games. He's good at twisting people's realities and manipulating people." ------=_NextPart_001_000F_01C80EC8.58969210 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

BAGHDAD, Iraq (CNN) -- British Prime Minister Gordon Brown arri= ved in Baghdad on Tuesday for meetings with Iraqi government officials, t= he British Embassy in Baghdad said.


Carol Ann Gotbaum may have accidentally strangled herself while tryin= g to get out of her handcuffs, Phoenix Police Department spokesman Sgt. A= ndy Hill said Saturday.


The tech-dominated Nasdaq also gained 1.5 percent for its highest clo= se since February 2001 while the S&P 500 gained 1.3 percent.


Hong Kong's Hang Sen was also up 3.89 percent -- gaining more than 1,= 000 points -- at 28,047.


"You're seeing a continuation of the recent momentum," said Chris Joh= nson, CEO of Johnson Research Group.


Someone close to Stiles told investigators Stiles is a "survivalist t= ype" and always carries a weapon, Nye County District Attorney Bob Becket= t said.


"Sometime during the time she went into custody, she went into medica= l distress," he said.


Stiles was a distant friend of the girl's family, De Meo said.

"The mother has cooperated with us," De Meo said. "We believe that th= e mother was not aware of anything that went on with this young girl. It = was very sad for her to find this out."


"According to investigators, it appeared as though Ms. Gotbaum had po= ssibly tried to manipulate the handcuffs from behind her to the front, go= t tangled up in the process, and they ended up around her neck area," he = said.


A spokeswoman for the Maricopa County medical examiner said an autops= y would be conducted Monday morning.


"She's what you'd expect a little girl in elementary school to be lik= e," he said. "You would never know something like that happened. Ever."

Todd Allen, a Las Vegas resident, told CNN he once lived with the g= irl from the video and her mother. He said he recognizes his old apartmen= t from scenes in the video. He said he knows the suspect because Allen's = mother dated Stiles and the couple spent time together at Allen's apartme= nt. Watch Allen describe Stiles and the girl =BB


Witnesses told police that Gotbaum was "yelling and screaming" and ru= nning through the terminal Friday. She was arrested for disorderly conduc= t.


(CNN) -- Darren Tuck, the man who gave police a tape depicting th= e rape of a 3-year-old girl, turned himself in Sunday to Nye County, Neva= da, authorities.


Betsy Gotbaum called Carol Ann Gotbaum "a wonderful, wonderful person= " and a great mother. She said the family was dealing with the situation = "the best way we can."


Authorities have identified Chester A. Stiles, 37, as the suspect in = the tape. A resident of Pahrump, Nevada, he remains at-large, De Meo sai= d. Pahrump is about 60 miles west of Las Vegas.


While handcuffed, the New Yorker became "disruptive" and she was take= n to a holding room, where she was left alone, Hill told CNN affiliate KT= VK.


Investigators said officers went to check on her five to 10 minutes l= ater. Police policy requires that be done every 15 minutes.


Fi= nding Gotbaum "unconscious and not breathing," Hill said, officers perfor= med CPR.


CNN and other news organizations did so until the child was found, an= d De Meo asked media to stop showing the picture.


Gotbaum was the mother of three young children and the daughter-in-la= w of longtime New York City Public Advocate Betsy Gotbaum.


Allen said nobody realized the child had been abused.


Allen said he never witnessed Stiles physically assault anyone.

"But I have seen him verbally and mentally assault many people," Alle= n told CNN. "He's good with mind games. He's good at twisting people's re= alities and manipulating people."


------=_NextPart_001_000F_01C80EC8.58969210-- ------=_NextPart_000_000E_01C80EC8.58969210 Content-Type: image/gif; name="footer" Content-Disposition: attachment; filename="footer" Content-Transfer-Encoding: base64 Content-ID: <006901c80ec8$58969210$c05bd94c@27CERJ> R0lGODlhigHWAPcAAAAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A/wD/ /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAzmQAzzAAz/wBm AABmMwBmZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDMmQDMzADM/wD/AAD/ MwD/ZgD/mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMzmTMzzDMz/zNmADNmMzNm ZjNmmTNmzDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPMmTPMzDPM/zP/ADP/MzP/ZjP/ mTP/zDP//2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYzmWYzzGYz/2ZmAGZmM2ZmZmZmmWZm zGZm/2aZAGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbMmWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb/ /5kAAJkAM5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkzmZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZ AJmZM5mZZpmZmZmZzJmZ/5nMAJnMM5nMZpnMmZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwA M8wAZswAmcwAzMwA/8wzAMwzM8wzZswzmcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZ ZsyZmcyZzMyZ/8zMAMzMM8zMZszMmczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8A mf8AzP8A//8zAP8zM/8zZv8zmf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+Z zP+Z///MAP/MM//MZv/Mmf/MzP/M////AP//M///Zv//mf//zP///yH5BAEAABAALAAAAACKAdYA AAj/AP/9g5dNoL9+AhMqXLhwGkOE1bZJ1Cax4rZqGBlq3GhQoz+OGkeBHElS472SKEHiS8lyob9p H/8xakkyZkqHI7fR/GeTJMKdQFGS6gi0YFCGEhcWm0aNZMWMJXsqlHq0JE5VKO9RraoRJ9CtRHn+ 6zcNFleGTbVxlDZtWjZp/7xyrNZy5Ui5cs9yHRo3ZVO9s0i2XUZTYrVYEu/pdLnxL9eTdxNiFax3 I9mEdjn6Ayt2JFyBefW+VAiZY95YsKhxNr0a9MLPd1tXFui4ZGaFtRXKhZ3wEUjeLeVum4Y46ey7 oRO6vZk8YenIvyE3b1ls4/PjCVEpLwkbJtDpujUC/+eYDXzC8f+aGf1ny6zmqf7wbZ7/laH58Cwt bqNm8Z/di8ah9IpaQYWmjTY/vWfQbV2RhA+BPjnEIFDMYJfSR9ehhMdOck24XYMoeffhiIyNJtB6 I823GT4sUuPii7Ild99RoWxn0TQV/SNRLIhZSJJa2pgHGUImTrKRXBAKBFmSHGWWnDN0+chSkAlB COGMG23oEUlUCOQhljQ51BRc+VAz4WjeMakQi/i8aKaLTLnZZm4tZTjVUcxIhOON+km0yDY8whKL lBv5k02ChZ4olZE1baQmY4Tqlc2jLMm2pUZJ/mEaS3m56amLcUUp2Ec2tXnPpy62yGI/bJo5p5lH 4f91D2x0IpVUTPr5ox9/TxkGxkU8QknTPdPl9QIMJ4JWLFfaFCQcpQaBGWlfIHbWkqXVBuVYWxqV KU0+/5T5KWYEcusgm8S26KI01JzyJpuqxvkmjCzqhdNLl4HEZJ/b6GqRvxZhJLDAyDAyaFacGYqo QkyqdilX2VAFbbLTWgUuQ+gdma9zO1151Ev+ePoqNUzlk0+bCcXnKU/4IPRTfPCO/OKDbjLFojRz qtqym830HPKLHLZVXlh3MjSaLRLp+qt+00RU0Z4BDzxwLAY7zRGx3D26FYrHSVtxcOJBytCss310 i1leYyZzqm4adTF9GqV66qmfyqwzuq2u62IzcPb/TE3PcbIp1WRhPqyjfPxuA0azTlP0tNSQY8Qj ajwa3GNVRK7X3GFidO7551xw8fnonvMY0WseFtisRs04c5ydHqG6MnbevdLY7GrHXO/CU72YSip+ BJ8KySLnHLOcrsq7dzPS3MP38nK2Kf1ChWyEMkMXUyt24hJNiiNGTQ/MTOSSTy5ooJUPGmCiLNm5 jRg34CB//PTXT78rN9ifPw75c7GYkv94DjGKIi2bhGZGnZKdAsc1GwkR4nZ1U0j2tgOrlayEGsHz wxQ2yEE/vIld0dNdnJj3t+eRbBqAe1HgdBczbC3kf0XTCPe61z3wke8wk6Oc+XJIuUY0QhuNoAtM /xySNqMhhQvzS6L+9oe//OXvD/xz4g3c4xq5VGdaMZkG7wSyxYUs8IsKRGEzSBKNjC2kPKRKoIvo 5iYJeul3qRDFvP5BjQ3eg4NT6MMU/IAPm8nueMMrYVvmNTMWGrJVLqSMQhJ3w4Fl4w85PF8keYi+ RlCNEZgEYiOGJhDgJPIfhtBeQt53A1TwL4pRlOL+VPmH/eGAGjigIn4q5h2yJYRkPcEJGHcpu2z0 7Je/JFqsuEabF7GxjU1JlQbvsMd3kWyD0+BgH6bBFpXVTWRwih5MWOiMQ6ZKeoZQDTG/0pNeNbIa 92AGj7LBI0hSkpKSnJwP50lPH+okL5/8x2TyQv9KHEwjlaoMqEDzp41YSimUKeJiymAiu2mkwoQN /aIYxQg4bQBuomMMIFdMFDcVemp44ZJeHZnpQZRRAxVTeAkH2XKHd0nvVXa74KlE6qpD2nQUZlqF OBtSIYG4TkcgQaFAAnaRiFQDSlN7p1IpSQ0e1ZOe1PAhJtGAySBKY2IoMUpo4Mc/Uy4xoNNwYlva QlBZ7oQ/G9mCQsbjFRc99Jcl5GXNajZWYI71rs2waDPg+LueCTMok+roGl3kDLc2gy4vWqZD3ZQK PWaBWFNAhR6ZYs2fzayQqZpGq2zKWTbh1FWGGknqFvJTc0ptqZNrKg95Qsl/PJWeQMQkIxohhqr/ 4ghaIvrRRrgav7BK0QYD9cdAtWHWyjhjgv/4DDV+V1g3OeOtrWtuGPtKMp/ZdaIoLGHP+KoNvvbV r2IpIkoWCFLfTeEO+PBDnNLj2CkwYwrRnEIqftam+MAMXt9kEd04G7G7qWuzIg3tUfp0wxy6k4eu 8EcsgsSjf8iznv6Y7Wsj3AhGGIIRnavqNpLkFZyEoSSUMgQSnYgKKWphoDcga0BrFSnvQhSMccyg ZlEoRuc1g8YU9a6O8/rLbOzNXKLEjnM/Sg2BAQ++d9DsmzS4wfd2kBoRo6zgNKuumYXseIR8RZvc 4hYsIw+0cSFiSfo1xJc85bRKVQUPJxELNDr1/7UVxuQ0ZBtnH0ZYtobIc23tybW8gAHEWxExiged P99KERb4QC5DUIFVluj4oZ/6nR9SEScNZmHGd0BFW35JrE2j0MXABOZLhBanuwZZY0OsRUKq8RdS JUkbsissRDV4x0C2KRVTAAMYpnCPLGShmf5wBcn+u8bOsg2/+FjElv1b5XldbyVsaUnU0IzaHKLh khKmZ1WlOltGTCPOsg13njHcuQszQlThAROBqGKILRDa0ITOX3E3Mooo3xIoj/6di1SxXD9kYdJt kWwWmtEHP/RB09qta1uk0QxU/PKuysPlCQdZ0VOTZBEModQryOuibRACvnsM5D9S8Ws8/roPzv8+ lZaRnSp/JMJ49HIVqvwYwrzVyzUv/F9/dDTt8qHWkpbLdj23He6q1vYQ364qJsdtCDE03XNVPZLF HSXMdqP4xvFW5byjEpR8p6KwzlCFH7QAcIcavA/46MO/N33jtkN8Gq8YpNwHqcK2jHqEDunitVRi 349OehuwMPgGAxkyJqt9g3qc77yojOhvytxMrbC5quSKTZqCZjVJWcy0URsybVDt269V+ra5jWfa ioELjfj2hVfv9Kd/TramuU6jrQXKLfAArMzIekC3PhJt5DMhjMh3c/+QR1Fsug8Fnwby/cC3G7cl SNm9qzTKM3G3zx3i1RUzp1qyQFdQUxsa1GP/STGI6w2WXPzyye9m+6EyFsq8XvdN//u3jM1jw2rM OTozDnmo4FioBuixsEnc9lSHUGdFF26mxwiw0G1NVwik83o+NBKQ8QYGYQUJcQPsU3tDoErwFgPB RQ3aoHU78XvAJ3zPpXbMd1cGNw3/NjwUtWkTh1fl8XZ0R4N7w2KKNF7UQCzUIF3LlQr5QHIbdAep UF+FEH7nl0eqQUhy8hLHMzKbdVnO5HggVEj4BSogkXmmhRHxxCOeNzlJF25zRnTddoBk2AiGkIAL OFuGgAbl9oBiQFXoNhJEIBBcoBA2MBKCBlaDxhQDxXtj81ct4XVf529lBzzBQ3B94IIpxGWe/0aD eAWJb3djQAE7EEQNbMFYwxN+zdQiTOZrecRMivdSuoMzNWVIoEINdyAKOuNS8IIzqPgmG6F5/JJU /JdD+FBh4JZ6Zkh63lZVgrJ0hpAGcThbneNDcPg5FTaHKGETvyNKJrKHUgRv+TMFugeIayKIg/ho OFUIKNh8hvhvfWB8f5MNcTdWQRKDb/c3b5cH6whXQeFCn8KD1KAKqTAKJSdf9VJ+5pdHnZgznhIf 7JdMFiQnyocK+IBrJSUfo/CE9NdZHMFIAkNJv0gc85SL86R0YYiAGOZtQDdnUpVnTTcGVJNhJZmM e8aMKKEmySGNTtREqmSN0yhQ85YXlrgThP9ICMgXSGc3DQYHcBeFY6V2V33TfDR2Y8AwDe5IlDD4 MYZTTNMQJNogXc9laf+IQVMAiiWXZCJFivIBL3Q0BXIkHx+xEs0QWfHBN3nzWa5oU3OEFEDVc5TE iyGjdANohmRIboyAD2sYTnsmkmIwT1B3knCISTBUFeNkdTMpRTHggQElXE5EDfL2DyyJGcfhder1 b3wDPH20fIuQfWz3NyrkfG8FPJQ2VmwxDeuAV9aXUXVBEz0Ya0eWeNLDj3ikj60oOMs1DffgQanA BKwoOEMRTUX4UqzoDy0Fgm3pTbIoQwTGhXOZejCRkWUIbmlYdLsoBiBpdHuGBnoWmHQmYeT/9oCW VBLJUAoSiHMKUQ3uNmiNCVaSOZNo0xDU5CP5NgrBQ3HThHzLJwnsOFY32AxlxxSm2QyisJnMc1Hq iGOuSXUgIQYKohYusnGfUpWIl4pWmY99YAi5iTK45mRcqZYjQwpnKQr+cJa/A1//MJYr4l8EGYXO WYvVcD5w5pGid4C+WDlGB3odyYC86Tk+FIAVloam5zkh43TnVhmpw57x5pgzGZ+RCQsosjHixRD4 IA8JkW/BU3DN4A/z9W8/2XzO51bC01iB5FZE6FAG6gfSQF0ndEJ3xze9NxIQWhILZKH/aJt5NA3I IA+A8F9sMnJ7ZEIsQmX8mJxMMF8oKgpT/9AU/MYiJ/qDZgKDcXSKqfOcsUAcbxZ6vnej1WmSa8ht xyikT2UIzjOGFeY5rjc6qsEIh1kVdsKkhOakUsQ3YDVOJKIXWupvqPA3wQOm4wiabSEKBTdpgIOI v0OEiDhp0LVXlPZLqUCPDiMlMXGnRyZfmyENTJaV/jhN+0WKqtio/sEmZ8k3YhlHYqmKRYii5cd8 hdAme2VXooAK9KpvVWYrAFJU+4cPm2qA/qANZmhuUxWYQto5VNV0TxekPmRuqdo5Adg5Y4CSGeYf jZISE7INXNCkAwWlTiSlX5Oljxamu5lBBfesFCsQROg7k5ZBfkCskiYKd3CIfCUKNHugxP+Dg7Ox Ns41m01xD3fErVkQBnpkovT1Ul6KrTlztEX4JmfJfGKZHtgqoINHri7oaXslCsNzry/kNPo6OXuJ l4xADQIrWxHGsOQGbhHbOX9gjOA5Z6rasGjQCGk7OsJgsFDXCK+agSWRISPmnk70niiGjU/JGhqh pQVHMurFsh4klD7pQb7TB86qQS4LPHuFUsNjoKjwO/NKs3yzXnqhd3GhQH/wBxrUq9PADJ+YlUE7 BV3qePCiQe9yZShKR2OnBYMqlvgwu2a5Rx8Brc7nN5KaaKO0SPq3f0JKYeGpdBfWCGlwZ0XndAsb sMeYek4HpA2bjHU7OkGkjWJjGwvRtwP/Bbh9OJnQ8RURoxCG26uI2JvCU31/gwdyNEiUW7MZJGkP lQrMQGk71nDPcyo0oSkN0RqxwG8NVR5k4Q/MwExA+2sLOX9tAruASg1MYK7Mp4onKl/p4VDPhZXF SbPL1QyAdAzHILxDdbJOY4uYBJ74gJ0HKAaatLBUFbHXmcLg2W1uqJ0WZo7a8IYPuMOFibcnGzZF 4zXVgETUyJi0OlBhFQNmxZtelDIrmbcCsaubWKwi63xM0Qx3cAwTt6zLtYqrSL9sql1YHFd64xiu kKsL4QcLNV4R5zt4UFJt4Y+Xxq3zBYWtArvjSq6s6wdJ5h8x6w8b9DfwJQpMMLWWFYsC/6EN+WBU OqevxquLHElnY8sI/rBnlhRnY+ADsYVJmxyYUuU55eHDEts5O5y2aJC2lzNarWBEs/e9OFBiNxAk qiS+KLbEVNRH1dIaOPsPbLyrvmrFWRC/TFFXwVNYmtuyqxg8NdtXkEZ3bwrNN6ueAJRQfrGDqJIK cdwietSP92Ca1gSpL6VBS8sTZoKizOQMgbdBXTqozNdH+XWKVwYv8YEzj2IYPodtYNt0ZciGNWww Fha2NZyG1ouG2klVpTw6O4xhbugDBqMTN6m3KWHEcRe+SRy+aKNZRhQTjSYbWgDMy7qll4t9qRCz 9ct8zjAKbxWgv5SaADpYn7IZxJQc9/8wWiBBXvooqBx0cqf7eCxUfsmjrKx7lhu0uS4SMidjQX60 Zf4ABmHgwCbjECbDyAmBGBOpo90GbrNFVWcbgB45vbRVhv8AyqmKhtvWdK+Q0KQzBj5sCD4gBpdD gl4DCIVm0RcdUOa4ddO6dyOhpZpGrIo70kTZb8ZKYy+yXd51otQEoPIiM6RiHYViiWryRSW9tNsK iuIHMpYKqRh0yIJ3Bz2jj8tlJmcgCSrChJTVfpYqDdGQD9Pg2iZjMiSDEF3rVCxMwxJmsFIlDWfb sCEJqtlGDeW2qmoNsR1pkl5SIC1B16UkUI35ns8d3U7amLk8Iq/saCGraYqrmZNYaqP/SYiAM2oB uRle0xyJRNnqVXgbJJUcRGnGY0izWZwoc3MX9CpiCld549Mr4RXSQBdQoSORXHQiidtUk4CpR9Cg 7G0AG2dQN2exwAuZJAZpQNyeM7qlXKSXgzk27UWF5pjS/eEgHt3FlRZSMl/dxVd+4HDbzXxYjFc6 5lDf9aYp1HJb4TUZshWc8SI+qLKqwZswcZvY6rpPeF/zzCYg9GLAW3MAxiL5cL44h24+d6MznIZu mNXH6G0I3ghxF2eZygzT4IZpbWGNwAsXJtwSO1afgwZu6J2mV55nARcbvmqGEOKNuQx0DuIsthjX PV5eqmPMqriiwOKM+2nNSizPg1GQ/5YqghjR//AKGyfRMfTELkIKbhIywKMauIZCt4lym+HArXjU TMgMDDfjX1ZT6ucisT1EFQEX+7FIxpttGSaqe2ZhTZcGxkhu2VBhn+fgGHYMaa7mtUXKpAMTdltb SOqdZ3sRleE19agKqrAFWxDddh7d+RMDMDANMJDtMNCYKkmtIxeykmbFgR6JQvm7dofYzmpCG3Ey lcEZsJNMTAhrl+4P26pZ0rTZLFTMnVuDx9RCuuN4hbTI/sC1OiERTbEYkfx/RRpnBG3DvZ3Cr0B6 NxzWjUAKLeyG1HDDD6jxXB3Q47k+nEInDkGCdEQF2u6YfSRWjant1CC4e44SWippMv/GpS2Oxcgw CujeDN+8Xc9D8iAhMelppbJj6SW1raq7QQvplccDzapS0/hOU1YoJybzErGdDwX/D3ShE00RD/tH mdkZ64ww8R05DQ5NNYaQDWSdZ8RYvZK8egJbjMX+6+a2vETqsFLMvVHpI9HuRDXtRLR8A9b+B7py HByVDePUDzHfWPkZpuXBPAz6N9Clvw+311PCdZF+b1DcUQwF6v1mJsjHraA/fkW72U9fqC7lKTeG WS9V9bFNvFFSDakgEDgUnnVWOlpNW4YwBtOwZz4JymdApNF7gOOWwrJVWzecwmreixl290EsxNWs F2IgP/70T/IDS9LPP708SyHiEG//oRBTcB7gTnI/GabqQWPS4NLQ6syQ5iFg8WGZb80jkRtUUYXR 7CKB/sD9CPooJ3+eLj1FztkAMY0atWwDXQ3EhzChQmr4/v3D5/BfPor5qFXMN/Hhrj4Pq8UCyUjk SDEixYhp1EikSpHT0kxDmZLRHzGGRP4bmTOnP5GGfJIsyQiNzqE5G51stO3hUqb//DVtOu0p035L p0LFirWaGBxdp3XFoQ0sDi44xPhzBvXq0mxZ3S7tN+1fW6lTpqbCmxevHz+p+P7t07dZs2lSpxH2 N7gZXsWFqa1lCpnpoqXa3l5+u+rZUmRLqQkcGNrfQFF+Bt6ZMiWL6tVTTFO7tzDi/2zaEUPflhpa G8HQjm/PbrjUYuiM1fJV+0cNeSphfjzC0rmSkU00SGWyZARz2shGRUf+m4Y9urbt0XPaZMRSfLaS St/ey0ron2Wo8OFjzroNVlku/VGVHWssf7ZJKzKmBppGIvyqWkquuRxkSi+9/qIwsD5QoWaww+I6 rDANBQLNHxGzkkwtzErET5qHOvGMGmluu82vz1JTjbXUXoNNoNpki4iwxxDEB7SBCiooNC0GOuai jCaiCEZnlGTyoVRS6+ifamBJKUv1bEIJKelEUgOmmtJTTyRtspmmHzJ1kso8lWQyLz1GXhHDPbcU xKoQtxjEDMKHtknjpADJ4o+srv98QDSWpkrs5z78nHrIwaf4XErCVKjxK7AK/QgMRsKaIe9D30RE 0alSH6LvrVSjCvItFZmqBkYYZZwxi9ZqxDGx0HYE7sfPBBqtmYao2Q1GPyJCpklqHhpuIGeepMi4 iVKhwhXXnmukPOlSKkoMH1AKKSVDwmSJC/O0WQlOkV7JFh+jdIJTXUZO8hOr+7J4tClHHY3qHxW3 iSWNMcYQ+CQuED3UB7IQ/bYrMWJxr0Q0822qrQYfgiQRKfHCNBV//OKUQr766OPS2/6Y5pUOB/ts 2aX4ZUogt07Bzx/LAGnwnnoflXXWOwrLYhpbWVutj2Z6VYjX3HpuGaGGFlryn23/kKMaRnwsajK5 KTm91iOQshHPqKPESEM86HQqKWx03cyGkXvihNsklFZ9C1+K6yNxm3vS4Htgv8cQFAeEGeaqKwC5 eDg5Eu9+9GOI8sJUZMD8yKKv21Rh+tWHKP2nnzwikwoqmq3Kir5SGLfKQaZDm/JSP6aYhujUskgF 6aePScg2IXvmNSKMJnLPuCWvtsjjaVLRGnYqnZMapFiyLXOk8AoLSk704I43+pW201a8eHOqLqm5 Ht2ZYjz/3Mall/hmv/2GA79h0LHEmAY51O/vXK/jQRbZwj4qN9nqBvIqmD3kHp9D1anYohYFngpY LdKNz/wwjdcFzVa3Ms1CfoOP/yRFJEFW692uruaRalRjG1MTnkVGkQpnpEJYoXndjV5XJal9BBbh yVJOdLY2efXQTNnA0pfEJpJs4EMly2BGnLATKPGBBz8FxIrdWMWUEwYsDf5Yn/ra1zdvEQpxAWKY D8rij4fZCX/52h9ePsa//nHqf37AnACdyDmmsKMdnnHiZdYyGkiZqI/5iiCCBjKlKaRiNauJnWpe d4dhgdA2CRnNjp72yNn4Ax/SspIJqWal5DxpGlmjRgyn8D9bMU9qUwPJNJ6XrsKYiRrZ4w5LXqGN lChiTd4jk3p0OcSeoMROCswjZqR4MQgFbGB8U980pNE3ghXsW4UDS38AJLgwMv+MEfbTyBkvk4o0 7k9ykyNZYALYMwO66kCf6RNTUnU+YLpFVkJKBR5oNM/UCC01HmvkbJKjQQEqBCMUYdY/J1LCEiZH IMWLYeVEacp7AOwjsSiPlqAXvVGQ4l0RlWgO5cSItaVLiNxJT/h+qU3MtKVVgNpiSpn5hzEg6iQn qSYYveUtwkFscf84xii0aam9fJNkbizaOG/zEGDySyojeovFkEpUA90PRruLJz3niQ9cvUJxkGQI bWSVO+Llwx///Kc2sJZNi2jjHqGk0V9oVLmYfeShINGltvzxJomiC4dfomv0urfRbakkG+TxJVOg SNIFNkilKR3YS/3QTPYB7qX/j4UsTAlnxpgR9h88BZmmQhbOypFsNX0RqqmWcj6mSMNBLyIfH5tC WswwAyq4mZU8lUfPZszTD7uxyEMakg/b8M53//wkWCvyVZfF6hX2o2Ba/bLWrr0MJA+FhfOc98r5 QARO80lPRzUaNjlpNF3fI4lyLEs+Kmpxi397JmMPe1j0PvZbsCBRgVRFIvhgdmT94+wFD8kXjukW mA4qDGj06F/I4KOdTXHtOZsWIzwURqpToGqNCrmshDgjI72jjXC7Ktx8aAM5uZ3IIGfbl3n2ITXy oYqV0iddVYKEWHBlxLIaoY1TuGLG0fNelnAIPbzO6bvzigU2GQcL5N2NX9ug/1/7Eks/mKzXyU/m ohjgmxX5mq9SPJXcT0mp3wuOkr++WipUdqZarLgMH2dd7R/PeJuzxiiRUj2kjUrmkeN8mMN33vBx wFrQbC6XSqlAhYmligoTtfih/gCJNp6nEkg5JMcZ3W5L7JrLNWVnbTAJclZcNt5IScYVaGrsMZ08 Syiz1711Ytxgm5KXxeTlD4SQxgT5wmVaZ+GnlitWmCtb5k2TqCFTMTDjNPfa0NwjLr0RJT1bE2fX yLeEd4b2hgkKVsUlJ9klE+WyU0No0RJVLpqMlXTFvWhIg/fR0yDPo+EkBiBS9mKEjcvmymelg5nX ydl4RalVCrhvIawrQn4UzP/Kh1m/ZOEV96Ccrbbc5bR+OdcoouOrBsLUP9qsstnwxzRUjZVhHyjA o7lcsuepbQlb7oTJIWjK6zxtisBj5SlnebS05odRKFfk9OT2fZ5SL0YgetzSbUQsGEFuSPdYeuGp 9HkMQT+1GLjXjJOMxi8DC8Gp97DZ0PcWIRugG0wZKoF4D1ToqDVLceoe0sjGwr9Q4r/sz2W6kUzU IahpMVPqHpY8MLF7lvGbM5dGJqbCPakG8xJO4xaweHm04EH4xGckH36eQm338uC/F7lfVklfekKS y4wa/cdBz4krYum9kyhq3mdcy+mxAouXrjdBpW5EY186DYWN5QaYc4sVSmf/WtP2SzJl90MzbPVm hfLX8uCxWHJEc/kGdfwVj4EKa1EFSNX3bBoFgfyDA38r20JfagOpRv2Y8vKUe2QgWVO+yLWR/YbT HC+vNZE/HmqIRtwiFtEFOi0lWhjtURpsP06Pk4AF+8m7fDkf6dO01ruiANMGfCi1VvKHMdCGl3KF aSIL3Luf0xu7jcELE6Oq4jOZy2AQGLmKSZiEFIOKYomMXiugAnwLGDkT1rm5vlurZbsUO6kfwis/ ErKfqIkcegItf4ghCtGL0HiI5Ku20aIi6KgJ7+q5NTGt7LkxLfG8sfE6TruM0HkU1juJLbI3lSoM gSGjk9AGhSGEG4CBG9gC/1hwt7tRvcsIpb+YOIohFRjUtWAitqt4OgQkKQFivyn4A8obub8jhFnq nKWQBx7UQeEhuxnMi9v6A8gJDYA7xLsBGFUwGJl4pejIq0YAGyrkK7kZQGnABiTEQrfIu1g4Cat7 MpdwrC4Ci/i5AUMwpVN8CxfUozq8DW0AJozzRavwvqYiKZ1SsJ75Q0FERtc4ntDojMsoIWoYhWSj AuPTC2GRGszYQKzYGXzQjxt4qS2Im5EoBJmQg+h4KZvCQze0LFOEClj4FlbcN8hCHAs0hAHMChiw xUh5t/GSC1nhxaZ4BPwIxnS6m+NTPsxxhjgaJBpMxmQ0PqZpIb+QLddwP/9JnMPGeYvy6QcU0Y95 IZzIqglD0AbEOQk5iKyhE0Z1HK+Mc4ttMIR3dLJXrL1BMQRKhAoqKBWbwcWN0yYRSZOt2sil0Jim WIWmeDr8eEPMoAZVwBxVGKfso4aGTEbuk6G/oAI8wEoKiUSTwUU/yop5Y0lUpIalo6lqQpQJBEmU ZAp2vAw/SAt86AcDC7Z8XIpqeEkxYEWZnMmx4AJVsEm3oBudzEC6fAh7MCBZkQZeDLMRMQTPoBs0 gkyjXEpqaKEYEbk3k8rMTA08IML+ygqwsyxREIVdwwoF4kXLeKtVeqlnkjJ0rBjGGU3C/AdVKLO7 ZKwlM5hpugE1ZEPU6cr/m2Icg3wLe9DFARoIxSQVyBiN31SzRSHNc0LIceqEm8NMZKRKqdIsz8yX Q6DLpJRNtpTNfCEFrVg6x1IEV5CsrthNNcRA/HnMu3kKnnQLZ8AH2myc4tyd5TunUwkO8vDPpuCT 1FsKFSmFZJBMZ2EhZ6EGS5AqbZAqZpBKkeGYgWDO7gzP8dKCyMQKPvQ2t9iKflMY3dzNLfDLh7jC C01J1OFQXnuK0XiR21DOfjjK+9kjiju9fuo7f6ARnRHEzgwNYkRR35MMTojNfKnQctImMKAYqYs+ MWsQf7AqVJwGC4zFWezNpdATVCTMGQ3P5aS40pw4GV1RxlGQpMSUjAuN/yehQQetTi8DLYOciiIN 0ne7CnuQTxQ50n9Ahiqb03RykPeMipFcT/bk0vl6lDE9EDIdL91YFP18GVssQPlbygBiyHtIK0J4 Py0FTtmUC55sxkTFij/I0DP6yz71jBc4vsJAUmfcDy4YwDbEDEDdVKYohBdAVedUyftJBS14gVG1 CpBDzq/EDyClVVsVTiP1jAl9HVQAwr6QmT7hyQKqhj+w1UJVyQRzizs6wlJJhRc4UVO1LAeBAS0I y3JCVPwpVytrCliAgXZ9gT9IUYxsiijFDF61VV+9RW3Q16uQDLY8hgNpVxh4V8sajRZ6HT+QBkzt Ne/0TqeAEGqw1WpFV/+SKhV2hS9V8NYLjZpw1RwtGNUAY4pzhQpPuAzW0hn8cIjH2I0XyNLLgNUm XQqMbdm3KARflQaPvazXvIzFyJk0cadbfZRsNJDcmrh5mzd4gC8/wdhvTR0rgYErxFnGaVjSiQyU 6VWowNjlgIFSxcKNvRtYqFlj5RwtyFIYcIU0wx+SLUgt0Ljj0VQCw4+X3dV7xZNU2FqlfAH77BwY yNJm0FmomNaILYTwE9qHiFqffYvCJUh9gYpdBYUXCIOZtdtSxbhpENWm4FvfpMMIwZRq4KZv/QN4 xcKJOcVq8Fjk8dh6gdhNm1q36AL88Vj4Mt2ZdQt2NUhMwYozeS2PtU//u6Vd/OjWKuvUNGFSfVxX GBDdWq0G8GQK213LTzPeAc1HR6EG3pWSzH2UtugH7CWpqV2LXV2KcX2tu+W0PHULLbDPQnAF0J3Z 1nUL0HRD8v2HQjhWqKDWXnPe0tHDq2UK9GWcqN3HrGhME60G7i1grGCGjrvf/h1VF0Rc/IEF/l0K /31O4cgIf1AFVSWsA1uL6sXSvIUKCsbCbr1C9w1Vy0MFfH0IVcjQRFxVUgXgE5kG8a0UpoWKdm0K 5cWPAlbhf/gDa9UKloWKjoMKnHmIWu21Hr5HfKxLIcYfZbofHrbfp4OZ1FNeE47VRymEluVVgPuD LK1VFZ5hgb1dex1V/2qgVrzoVfsphHZ9hfp9lBewH5k1yrsdBV7V2yMWWKCtlIAtsl3FRzw2UXtl 4gMJEoj1k0LYtLl9BSSEWF+1V1uFASDmhBc4yuSVYD0m45gF4X+ABTzmzoeg1kxmigX2CNFdYV6F gTx+ZBOV5Hs9owfOF1695CO+Wghp40023I/95E6eTXvNY3l1C7mo2aV4gUI+Yng1XVgGjyAJv2l4 AT9JhbLN0Gmm1potrj9YjmdFnWrI2PnlYys5ksuCZkuuS22+LHNeih9OZ+XQggj22Jal34eg4QZR psLIBvkt5QylhnZFk3LeYxD2ZiVuXE6AV8O4imWW4GldDnPWGB3u1v9qHWAtgNdunVFo/l1RztAC 3lqIPeaIBWEkRh0gxoxuReWmUOiPZeh2fog4uIMsjWh1ZtdqYGGCzshYjWD74d+nYGHd+mFUtSTT neC2mApVyFKIRR494VVfFTItgIHfXBaytWWonbIfxodCrgbKMFxkhmR8NJljtrxCsM8IhmPwAAMw ALhitmXL62KmwFi9nYqzbQpazgpY+GnDEOqtfgiNido/+GSVDmcnFdjfVWtwZms5ZmD8mcswiEy6 LrOfLjJ86OqYjQP79GunxtKnthKRDeCs+KtIkWAPptVJNtzi6ppsOOAVVud/aNdN0wKJKOBCKJ9W wAzKEmnDPdFmgGT/WLAFK3Hi+W3Zeu5WX/3kD+ZaH85kpM7s4M5Q+WrrP5LrUz3jrzwI3PaI3/bm ma1naahnJ1WOdj0+5Saq3+5uiM1oOpwGxva1pngRUm5cdR5n35ZnxA5fX+3WDNatJxpQkH0I6aOP aRjVXYUMcpUSX31rtkBlzNatgS3wmJ0G2pQMbAhO+HaZeMNYBwFf1bbP1V3ww3btVKCFXcaPpc7s ZUEDSajVIovgLB1P1vZVbl1orIhaAddwTra8Ax/Qmz0RW9Xb2zbsBZdcX0a9ASstHX+LGTfwvK2K 6i3k+rxV+3RsiLiMFgzZy9CCo8lwBfFmB6HodaZvRJZy4e7kaXAF/1T+A1Q47qyQJ6zN2PjebzQ3 XDOn78tV7U2rZ4ylhlqQ73/gtiMHWl4dbZe575g174egP7dghlA47+vO0i63DGpFDmImbT32Ymlo WRGpz6KMFIydbEjR4dkEYS5H5gpGvcekViKGFSfuclGW46co4JOGdFFODhwmKmvlUA51alXAk6J+ gSfJ7gUvZDy3JIxl661NE292hSWfYQuGz3VFVS041tTd8+Q45vqeYHx8ikLX42tHHhR7C4wVXVrn 664WMosGj6ewk2YAUl4t6wP35qnQhmrvb5ytBqVmLQUHUNJxbFp/CgB2auSYCrPdmL9Fylnl9mx0 9xegDzCvcUX+h/8YVu0iy1M+JPE8keN7GO7kcOojOZI/6AP7oetlqedWrl4Ar16SXhTS8mjkEa8m 1hOBuNpPHtfqNWnV1gKLwfGHN2ePteRUOGlNc+LW/odHmGlrt+f6SQWM9wgZh4GyVt4gAXBP1oaZ P5LwG9zj8WbDNff5HXUx8wdytZ/WTtm7FflRbQuIRXMtkAaAa93kQxOi/gd+cRl2R0Xldcpe1QaZ Z9sjUd5iju2HX3VvlniS4kNUKASvvfbqxVhbLYiIzdA/OAXUPWQgP9V79Wj3JvLXCmzPaPpIJBbL d/xWZmHo3WpsimRnqNVjhi/ow/NVmwI8YHV+nnRqp10zBuJaXfT/h39qqUAFy4/3q+1nXpUL+PJ5 NaZNdq19MQbwqaDWsd+0Qi+GdACiiD3o+rh1uUQTzhks3F8cp1Z8W32FI3F8nY9apI7EqP330rkH jJPVt6DXh3eFUqV7nUeZR7ZPjB1XfKhVTs5jXv2DhACIF1pU/Sv4748hgwoN8jG1cGGhhwZVCaSW TZuWF3/+URNI8J8WGDBSvXoRsSAMLQo7aoFFLeNJhYVMgow4LaXCjJr+VFOY6sVHgzNjSpwo8KGq j1qmEbynBZU0ji+0fayGRwu1af9UvaRW8M+LF6imTbsnTWu1sD2FvpjmtWBGjWsL/gyq7V9KVcy0 KszGFx/fovgK/0Z9WBjp0YWpVJHNmAquxmwsP/5B9bggRawc42qZK/Fw0dAG7xYkKnphtofU/lB+ cdogvsGvZxdsRDv16VQbs6Ules8fbYPVRMKiC0ProYXw7i0M+Vr2Q9sZg/6DpVIi83/9iiL7Fzj4 zOsvYRT/B72o8+AP8QEv2h43x9fTFVqf1l592YLAv9Pern72fQrlIxF8Ql3XU3oKefIfgwYx8lqB Er0UVEeXeacff6dVA9YLMPxBTWHJYfgQDDF5laF5EonBkUipeKXKdQtR8xaEx+gXXCdyhKWFaaeV WJR/DRaETzMMajPcSHSRJWRB0xQWZHAoMllQdgt5ZhB/hcSIkv8WUBa04JQGeakePMy8BgN1FLU3 TT9SKhSgaN/BiRkMcwF33kNz/lPNTG3pWdQqobHTZJinTbJVnaH54yZtzP1J4J59agEdaOoF+GhR Vb5mYZz4NUdUIa6kUmlRNJ6GJ6NhUjTXcCplc1Zo/GEqkZ7VDLTSha+5Ipo/poZGSptYSiRlqrQ1 cutpSxpUTDHq+XpahA+Z+Z9FChU7JafuSWQLbX+Q99UrGz1arKYFDahQsIUKmA9LmGmBxlqLZkpr cFDGFVa2uc5bEDa0jTunfQuNK+S9L+T70LXqKqztQgkv/GZokpzWXp8vvEJdQdnAqdWjf05zHqnq WhdWkmhY+1n/sikbxOGHEuHZcIMv6zubm8SKxvJbjJbb4KyEMngtf88+/Fp7/twj80P3BIxaUbGo 4g98fPnzp554pjt0UVHD/Nq02rI7m9BiCtmzyv9pLBppwhblcNjBnT1bYWSP+doqV2JdUNuE8XVt 101mM84/h9knCioNn3W4vsr6fPc/vfa7dlGijGJQNkUa9Irar+V9cmiHvQznokYvivQ/2mweWtp5 GuawYAVZ/hqK8r4WVYY7C8z43awTVtQ4c5cdGPBk/zc1pkYDRnRBd2G+uHBTMuo7ewK3d3XWwnOO OpDqns6mugBPrHB7eeCOdWDbvHaXVvzpjittS5M+W2pwzm33//g733et6a/aPmyDYfS40P6EtDTn bW18CpGN+Az4vf+kTiJpU18A3VM0BSrKIM4gX3DupDqzcYR66jmXupSmrvXxSmzBieBsUAibTaTo NruijTSqZIzTnS8ZahPhzCaGDxb640EMekveZDPD09hoYTikDT5oGBo8YWqImWvewvKzkMOh6HGU GxILi3KwhQDCek4ckmhoWCxjUKKMstlEGUVRFGNkEY1lpMTL+vEbLJYxi+bZhDEW0ow6ltErbizI M673RNGQ0YzccqMaFyKKOuLtjc0w1ZyosYlpUMKOO8yjHuuYxH8sspLts15BCkmJt+yxkngq5ST7 4RXgvC59/P/ZISP/YQxKbuKUmiwIIhkEyn9ES5RvyeU/lvcPYO4RH1t4nUHKBUtPcpIS99iEryRZ RssBMzh7bAYeB8NG81ACma5j5iYeRRq+jEIUxrjmMMuISYns8R/FxEc3FXbNbMqShfBEZjGHmUc8 upMSPpHIJkRBpHgCE4jxFAUL88nPJvEldeubJxk5clA7SrRIoiALP9s5MycZJKDn7GYxsxHQlRCU hdu8Z9mKEjLRQNSf2yREPA3yzm7C0x/SyCcAFTLJjzajmNOIqEIoocZ2ztSbyWQnHO25kIXqdBNt bIae7tMeSqhiiNBh6kP4udBtzsYWwkTqDuOj03W6M4uiECj/HAsSU3/8r5tW8MpV19kTaqSVqGZN pDwY2rhoWTOpKeLqQwD7sbT+o5uM6qZVKYdNhXBVox0lq8Bww1eDSON9mQwrdKbxCqxutZbA2U5M Q0MJf1gVOvcgbD+5h0tMAvZGzGskQpES2lCaM4uVhON3joc3XDrVV1ilEV39iEnHhomusV1IbJAZ 3HvS9YyWk5JT37pUyA6zSPwEDDXuyZe86pVJxrWjU9FYy6aKFzCE3YRRl9rbrJKVq/AE7mwV4tAG Woqkx8USSh/7TULB07KbiAM0H0JcMrpRuPstoIQ6+ToCn6e/XI3nHif4j1gEtrz6lQhXFxkbNC6M Ggo2CIHh/7THkToWvWJdIy3jqprbUq6SidzfZOOktEVNc5jjdWpTB+PU03Y0vQthoym/OUqFoHOR b2Ew7PQTY7TJ6MONQzKI4YiPe9zDGPHQykhfY4w4BHlIsyWjRZlDxg3783awchl6UWtjnRbJvT2m 0h4LUWbGYjOR+ixKaN3I4YXtEKfAcep9FqtPur7Zdcwo48zOmeU7k3Qwi20GabCaNCv+p7JpvuSB V/tNQuPydaWcc+BkWeeCmI+4suTjeXCc0ovgZ059TitfnNqPU3Q0HszY8w4p2k9EK3LU/SzSfdzr lnSyeIOCqeWQZTpneL6R12+27AzvK+lMM1bXYdrhew3ij/92tsfE/eyvWotkn3EfNZTUAKyk3TtK 9N7F1LdjkjSQ7WEW3oO4xy0mYeObNFnO+4DJziTAU/ofrdAXMP4YZWCawZdT5AM6J6UEdQnZb3Tq S6NTNlVrtQzNNK+54z9mIV2LBG7RIBabRYrKtIdp54f7uNwal2Q7cRzvLA4GoYMJq4kdmyHQNkPR luuViIdcTIRi2dqCVA8bYe7PPWKZrHs0cM5BjeefmjyfxtBUMRe1zzYaHW/VuKAAXRvKjTfjaKre RN+MQWuUQjxZ00hNydEbcpejdEnTsKe+T9PJIS/zxu3N4qenQV896hlLC83n3OnY9tf47iGdtAdc 0XgWHRv/wx99Bw5da8xL92Azlpr+9qlr3Pf37VIhe1/lacE53FjS9Q55J3wsO7kJ5uRT9sDxh56R psRYjUaRb4x8GSt75x2eQqi7dmTDoNR5T+69jNNoRjYGk/lwmoeSi/9PWCHy1fbRT76+OvNp+sFd uAVnh+VaKcROPJsvlqpnbSPhCsXuD2306jnlWb/QLCs7MJQqNEsepMBkX/uoUGiwH8TQ19Iozm4p TBP4y2kM3mtByjxEydE9RIQ03vhY3miYj8uUkL4EiA8t0GkkRGhQQ/GIhmygEP/1RZ6cBwSe0GRF VZX838TQnwPRy4ikSPcBYFHgQQZ1CoOgwaFcCFkU4XdQ/5jLFQv6UZDYLZH1fIdq/cP/NMgWPIeU wIk00BqV4FdB3B/2YIn3OM/+7IymwAcH+ovgiQZ8xBDk/MMR8U+D+AEVhAYBjg8SFoR/SMOs+AXu lB4OUuCbTA0TIo+lSF88fGH6XVGYAIempOH7vOD1kBAknpB6vM0gZkyhgN9pvJB7WFb/icYU4M40 nIQnjg0J6QyKaEURwWEiYqLC7EzCgNCwKKB6TCKAZJAtjg8NimAO7Y52pIogPowPtuL58MoK+qFE ZIG2YeAleqAi/hB2IAxtyGLDwJ/CSE2cDF6EUAMKUMMo3ME/+EEoumEzsmJ3uZyQcCM1pAIKhOM4 qsdgMP8j0yCRoAxKM6xiaKjEokyWOrKjO0JjlDBDK7SCsYWJF9JIudQhR3SjP4ojDz5MsezSAD1E QyojMkKkujDDEhpEQ75jrECNvERPfZVjcHQkr8hKlDDKCaJLFDojgtGGST5koSzCoaCINmgNIGpR O4ojlckOMXrHLtJGLhrEloRJQ1rW200DLcCGNWLN7oVGTN5gBopGIxYKCUXlzNigwsTEfbAaXaCA NqAAClzGFIjlFMwICpRlKkwDKTjDFJRlWi7kOrZjWSBNGM6GKoDdxBRLM0zBT4xlQcDlWXKjWhrE W5qlXGLladRCk3jiihSKxuBGdrAjXJKlWaJlYQamYCb/5k6+YykukSiWZFqKpWXew2COpoUcZlz2 Y2e+QQTezaOwYyr4AztSg0O6Izf6wVaw4Vt6xRT4AWv+4x8GByfgjmz+Q23epjjm5kL05j/8ZnDe ZlE8AvP4ZGgkBB8qEuxk58kcZ3KO43KigG4qhHNCJ0N25vCY4AAp5M+oh3d2ozjCwjSE53ga5lk+ J3Cep3eEIhE05exkCH/4Y0GMpVgWaDcC5j+sglb4ZUGE51wK53owyOQwXoMI6D8QqIEeaLYwKG7q p3RKRCI0ofQly5/YmZG0STsOKDtmKDdu6GU4KDviw4cyiUKyju5YKIb+QYG2aHO+6Fl6KBRiDfUE yHfg/+hxGgSPYgmHwih6SuMtekqFpuiFHineIKhh+mh0vqPD+KcO+V8qFI6KWql3iOlzYilDFslt WqMKmUpLPoyRimmSXmmD/uiDSifBWc8hkOBsMIM9lI618MV7Cmd4gkY/vCVH+GV0UsFnDieFCkmg KuePbmgoUgOiemgoqoQSmeAlwslFREVM+oErxClzGCqlukg33kOTyuMvRuhp6KWYcClFAuanRmpz Tmql1uk4Ehx03ALDPIw6IOc0wOVb+MFltij4qeakWmovOmD7aJt6NCBliuWwFiuZIitnhmOzuEaz Ng7WMMtssGNYdmODmqVbiKk0WCs3TkNMAs/COEM1vP+fsMAfaUSruIYjtVrIgm5mlvKXQoQgbdRn g6hDNkgp/CxovsCqkFgibYSiP65CIAUHhxJScDzl5mGNP0ZVBPqlVLHqkWCJqj7M7UnE+H2hhabk FskJt9IjRTKJVpQsxB4MLYZGJ5zGwy4r51AD2AmPyy7sFt1NM7jqaxolwRaQVnTNFNzHzgwIPgye Bz0MqsRYd0ALcg7two5FGw4J67CnugQlxCQMPmZOT+hOMJLkf2itBXJtmKjPP8CDszZJ6ZEQ/VwJ p05J2iyqk0rjx8TMaWQHwr7dDxZKlbyhjJjj1UqlAn3W1jLq3r4tkiLXRarHGZ4KujyEF1LuQoyT S0L/aYNIEcLsI8Jq2y4+rtp87DN2ykoebqH460+GEcs2oeuqR99EEQ/mjVcsgivqH25o4LYyCHTA R7roCdtSkOh6LINQmu88SfqQrfoxieqmrPLKpJYBStgFLeGCgeych5uIpMAJSZX0S2DE2DIwDq9i zc7wwjkMz902TioOIjLaArf0ah8uzNeeBsbsbsJsRMUuhDPIwyvRSvg26vMySQJJRPMa0BPeLaMo YNTSDHde4okw4fAaxPxSr+bm72nM4d6mr0GAAvk5SwAvxAB/cAWTLh4qxKBQid2KMIPs4Oo+RJs0 bQkuIAG17dBI1WDozueqsHcVSgQXim6FhskUrg4v/0TNMo44DSVJKuO7PbBo1G8OL+LzDu+foO0r ko5twK/ThsYhXtvCYAoSk2RRkiMFF0SgTK7eMquSVdA/RO4gpjD7dE7rgubQcMz8jc0dJpPMfMws zfBsaG9BGu4QZ7DNfrBszIrvkAYgAO0/xC4N+wspPMETsPC+zUY16AEklx8hUi9wRHKm9EOEhCza SNiETTL5/i0WP8QXM04i824PG/HuahtfWAEpYBj/AAIkJ4UVxIkkE25oOEMuF4QeAIJo8F+VQCIj Zu9aOMMTSIlfsCd8zAoJWYbkEo1KJtk/xMMEV+Bs5MHMWolCyHIgG0QwGzCtWHI1qMITYEw1PDIk z/+y6wgzKQhzE+sBgyikHtTvVrizQiyCpkxiuUANbPxyI7Pg82or9qGxAV3LRp7C/+6JOaMzPheE Lafzw0CiPPPi0OCDHpyzOt/zVnDyPzhDM+xyQVjBR8Rs65CycDyBIlfDNCjy5fax2xpEMpTCOKNj OKfAwmxkH1Ps8hqGGCvERm50UoSGFcAzPUNu2Ngi/m6udcaMJWPMfQBCUv8DIFz0aVADS08kRotd PnAXOksEOqcKEkdLNVA0Ti/EBIZzHN/NAr+baFQWx2jzN0d1UZCCQD9MjFWDSY+NG0uEM3RRJS+E KtDzNKD1P6A1Xxu2NkyDFUByT4T1YWO1QlQyJNP/M0SHdCQzRzVMtDxTNWYs81lD8jIX9i/7spXo wUab8yPLM18/QVWjM2Q79BPIhmwThC07g7vqQS63dkFYthX0xGtvNO749BTtsGi8NfR6B/Y2iTCI RmA7tEScNT5bNierwmNTdDADByBgzCuwtGxHtknPcmZLNCRfEHCT9JR0DGmTdk84A3Z/hCqQ9y8D wlFXwz3gc2EXRDoHAzpfEF4DRyVv8kf0dVI8QXv0tXfw9SxXAzJVshUEMzoDAnWHdHBjd0HE81bk 8jqDtlULs2p39xPsCVXfN0Xz9ddx8j2f9aKOrL98Fk+zNV2H2jAwCTrbjS9XA1+b9EZftWbPsj8U /7VBiDiFU3c8PwEpcDRLA7Mq8HWTB3cWdh8bCyleD/kv6/iSR/c/6IE7P7aOW62VnPYTUEM1BMOI /4MVxHI1aIMyC/dWn/OIH8mSN0lYC4MNTYQyz7J9a3ZPjHdwbzgwC3OfEwSGC8c07AWiYzYnX3V8 S/RFN5houLi/4ENUrII+N4hxD03zJnAMe8f2lfRH2HJS3PhHr0VeFoaOV8GfnzV8Q3Q+wLmjKwQg kEKjF4X5IOyc9MNRG8SuY8Yv9zWr7wlFY/dLt7dVf0T9bbmgL7kqAMJdePhYA/MsZ0NYW8syMwVh c3JfgzY6ezSo8/dHtLmyLwRaiztoj/alM3gjt/+yUEfwXzPJ4EmMyvqplWiMgisEqW95UvN2aAu3 PFfJTRc6vwc6uK/0E0xorJAwAHuHuGt2UIyzuFe7Mge6KoBGsPvDrle4La+zSQOHglP1NNAzWof8 VujlPUvDlZz7ko+3LRcEfEd8JNM3f3+2ZidDIBW6SR+4v2v4Wa/FK2wfu3sHT/uDeheKqr6gSiZ7 8khjvjP5I68FWvP7a+t4VSvEnCs4YlO0Moc6qTc7rWQIKOnJdnQ8OPc7rzf7jaPzL1d5Ytu3S6/0 09j1jdt3MJ/1LEf1aoc8hafzRsuy1w85IJCFPOglOIe1kdsyVVx4JKt9UVN1s8P2P2j4f+uBP4z/ M3XfczqjOGgfTWCDtOacBu1kR4D8H+O+ssKjTJ6M7UALhxXI8qz3xD1nto+HdjznedVb0KIndcNf fmbHPoJTQ3Dbvc+AzsD9Ax6EsFawM3VY8hP88hPkgYin8+z3OmzbzWO35XU/AYW7vVVrP+OjeV8r c5qDP8ZA9HdoPD2ftTAzhmI3f7MruCUDAj7Ysrd3O/sTxGQLO5ILd3argsF9LkBI+zdw4DSC/wwe POhPYUOH//o9fJgwokSLDQVeJKjNoaonH0F+BPSvmp6Pqg6q0lNtoBWUHUGOHKjKCkFnT6xMm2bl yUqS1J6QQlntyUuEAxkqxKeRYNJpSQsyPVgN/xBLQDKlzqwpNZ9EqA1VyUwqyaI/bUnvafz6MCLU tQ2XFvSXNmvWtw7j1j1qV6/GhEzv9tWIbxrhf3qwSiwsGGFbhVCn0SWYF+nfg5YvhiWoh1RfPYbq xk2bcSBHh1UJ6rxH1uFayq0bUjuY1p/sg2cZ53aIOTZjyQRJ42V8zNlu3kjr8k6azbTeoheP66VN 8JakwF+f6ib4hCXJ51JjDfz+EJbw6AqdGe0b+B/D68CRN/THPqp2+1kNN2x1vv59uffv8ucVxbSJ 7qbu/JOoooNeSy2r8KR6rhor9NArFlLGU2qgATXkb6bOcsPMIIE8NGgajvzxULGL6EtQquMMav/F Lxf7u6+59spTSKeLAOGOxrqoSSpFeabpR0WCIJSoO5o+AjErokBSb6FknnkMIot6dIlGpxbc5iF/ HMstDPpuPKi4srKhMbsEf/tRIyPV9OejP5par0zd1qGxq77S1Iu3QixrcaLg6vIHDIXuhE+7MM6z zSEnH+JomjQZWlOwjBpUaJFDmbrHUTeZkuYvQf/xsqxpbPuUKdygyxTU3MyCqs/QFDp0vjovhdOh WREt5NUVYbsvrSPbs3IaW25p8x9e60ornwUVUvbXrExr5kfIHsJH2vUcSvIfVZNLdMfkFjoR3B+n IbS0aetKFCOmniJWsjQtk0yaNO+JjNiBJJP/LL9/tv01FVSkGuWigB0608Ff76pGyH1f3EshKYMV LN/7IGZXKmi9KlaqFJddWGSPf0RYYyvhFSYrIxEEmFTpUGbwMosyJrmhHA9ihhn7xuX5ZHQHk4i5 oZtrRsQvJQbWoVps+VmwyDTS5uJ/OtFIVH0Hyu/lrDADhL572NvaIo98nJinxPwsi1ynY27ID4JK IcjUX61t6DjbmJ3tOFcTBEThEBlyt7RtqfroMl2ztkibufvizQpS6LP0oLwF86kjrDIklvKBRBFF bBoNlkrwgd4eKJCBcGb7H3WxtVsjNBJM5aDHtUso8I4dmtCijA4EFaqSuPOI4mownCuk7jY//0iP Y8beyqEn/m7qXIc4vg1X1UNXK8HPXURcoeodmgRS3coD3uEMCQoLJMuvS4oatCXSg+LZNJZ8JVWG px0QahKqcCDwDwKIChntIYh5iEcqdhDwbe5EADpZzRpSDVVwD10m0xFdXjG++9zvLSWRH0kO8wR4 /UNLG3kIUaKnuoHwikLoI2F3cjKyi5TwOESZ3z8EWBeOpcmAMzuDfSgomGPcqi4tiw+3aOQ9mTUk X3kBYAId0kLcmGZCKOkRSnp3xAhC7yICQSBgCJKFaTljJCVBj0xQ+A9VsERUqPiI83pUlDgaLmlk Kxvw/FfCHjkDeDhRo/9U4cahIGaNGHrJK/9QArva1Y9qfWHculw3EJXB5SLVeKRewqCQ6QEHYsdx RZrISBI9nKVPQhnITQxylX8sJY7F6SMstrC+CJoEFVap0BUHArxpsCRFIhxIFk4yk5OkKxuiehdT Lpk+mdjRlwhRhU6kYSRn1CSHX2wIKUZCk1NaAQ/aTCMgEOgSorDEjJqZBjh7BAidTMMjVrmhCq+H NPtc0jLskI/GFsE1JIqOIHB8gjr9dxiUPCcs00iFFQM6FStUwxnTKA6FqsLFaVZjQvjwByBI4T9s HqZCmumhguwzTo4ORCb7WxYqXjKNsuEwoenbSg9dgoeFqtGXVKkQd4JyyjU+4R4CnE9DRzT/EGpY MYXwzCXAoAOqfpAhEdkyaoL+oIV25RIrVsgmhdToEs5oZXbz01JCiFITbZIwpdzxh5bGmks5tpSJ yMxKhnTnD2vKdab3KKFCSkhQnBglh+J5yU1eMpIeNYOI7ZSLSg7zs+bQh28NGd0+oeimIBKkO3va jV6a4xMbkpQ7VsgDagjS1zSix0cZMawBDTvS3n30Hxj6YFJXxZTUktR/06gQUVJZxk3wMTG98wgy jtEjnZKVKlkELA5ZkpMUrXGk/HIod+D3K9PwJ0X/otlTE2SayR71H864S/Isso2hirWZVljod+S3 FbSKUIIpecJS2vtMv16lbATdSk5xSEJA/2hjqEb8FSCcZ8WcYGh/tfEHPvTQUe689h+fDN5e1SfB mT7hrPiD3m3/CVo/qvIf4wETUfxGFA36TouTmQtBVuGtSH3usauEJwUD9BAVZ20+B1aSlgrHx3+W xMIU1RKAS9KyHuEjyCSE3E2wKTwcllR+PZINRju8Xw5D0CH5AhczX3LQJ+yySTj8iE88Aj+iNCMs eqAT2V6CW5Z45LV39TI7T7lShtzDj5v90SYDQ6y1sLhEP6vaKZ/mEMGtgpNSmaNIYNiT7pjkn5wd 3kfA+hyVlpHRRjFJVVSqx70q6iDNkB1jjGRBGcK2xPL8hyKVZpGVTs4/231IWljVtheZRv8Vqcta Y+VCZYL8ubuQXQh51KNE7aD6ItpAycvuoiJd68XVNTqSZXogtKIqhCq7Aa9UZLNs/7Znk7mhnKNc tU7s/qMrIJO103ygkTT5ymYWsejMRsiuxpJKVbgu9UOuTdLLLtssSdsYi0S9RF+P+54KyUaMX0UI 3Xyl27Dpx8uO8wd2P+QV7J4Ei2Z0EXxsUl16yTdyD6Kqo4ERknXp+EAU7uKsNJxmy2YXjDLVbIuk fOCjnohFpGrzvlwcd2rTOHRcfkJER1CBkfxYQzjEmKQzMugWCbhE8gGjy+rlieyqOqstMgXr/Yrl K7wuvE4uFXs3rt1ZsbVEuh7vEL1K1Iz/A1emovMXXqi9NxahxrazEvYNFT03affQV17x6ambml0y /5+JmEKlrMWC0FO9z9UtAnmmGIZxALz7QZJJkHwSHt7niBjBHZJ0sFmkbg/JfEM+/jPmBH0probW vmQz9ldRuekF6ReiGJPJm9OoxS/f1j2ETZDSUxu7NfPHrIgIq3sz2+k/+4rJ9tU67Qjq6QohttFr 3/vCS45fCHkLf/D+M0JRYxA0MP+AxPgK82OBIOpfekPW3218qL+Bsjf67qdVpp3ZLRsnStfncyP+ /oH+2E8ipqYvom3UCIH9jIk81i9qGqL8aIBDJPD9NIYusONHokHvIoviaCDltEECCaL8/9pvAi8C FWgg9iyiGsDgC5CKxrziN1iME65FKtyPbdRPNjhiEPrvVPyBBpVPIRawO6qOBLWHIL7ABRfwH5Lw H5aw3aIvY9JiVmpv+h6C14SKBlzQY4zQCQswK3IwcSSCEFyw9T6FLtKgETzGMuzvWwYhe9qQ8y7l V17BBRxlCesla/qPI0RBO76NKZ6QWkwwC75AGwZxC6HQLhoQAKtw+TBOIpgHCVOwTqiBBkxjAU+h LsKwRQgBU86NfroPDGkO9DjQPl6hBu6wAP/iBi7G8Pwtnh4iEG3QBDeEFh9D+mhmQaKvRvxjX1gF ajSiEmlg6wbBNpYwE2fRWjyEEBIiXv9C8euS4wNBbyAIpWaSDnzCEOW+8CBsACFE7RGaSkeohT9k kSlgYRJr0QIng9MmAoJS7+cagrAKBamORP2+wC1izQmT4gvOjyDIz/wGwTRycBpowBWwwBYPYhC+ 4B5owB9MMClegR9pICAH0PwUjiAVLhsiEiDv5BWkwfxoAAs45BWywCINriKlkR9TDhYkkiJR0PwI RiKTsB9LQwK/YEAcMiQJ4SVpABXUz/w+ZUD+sRVEsikM0VEGYRtDjh+lARUU7icJYQG1UDYCRwK1 Ien+UQs5QgAL4g/MLwuWrhwPQipvciAkkgamYSNBkkOksij9QSKp4Sc5ghok0inLTt3//CNThk8t /kJFUNAFY8UhmNEfadEQUw4LtlAnZIMuJ+Uhyo8ZZGMBUwUtUU6MzJIQfqES+68SOeQLLPN7sGAU b/AfFDJrLOMLdpIasID9OLMy05EgCIFDWnMgsGAQapF//iE0s1A2syBRdPMfUPAVcCMbvfAhskAH B8E2aZMGjpMJLdEgCPE2/0EbbCDnonMA/cA23M9gyq85kvIhmrAiR/IhxdM0FJIjSNIV0oUgXyE2 BxE5t7AHVQ4aQSUO+a4hfmgg/nL5COEraJEQPrM2UyQHI1JBlkEy02I2F5Iw2fIL1GFZXNAzGXQ3 RhExGdQ9EnIQBqQJJXQ3zTJAD4IW/1GwOXRzGp5Q/SzTJwVNGr/FFolTFruDGnpzBJFwRltU4UaU IHTzO2kz5dpTO2nxRZVSOl1TPJHC/dJkNJ3QMivxKSdQRr3zMhok+QhiGaalZ47QIvKzIi0zOgZT RzlkIuFN/RYQEQ1OIEwBEWeTBvDhINcv5SQzREMSJFlUIaSB5iqRYHSUGcuk/D4FJN2URW+wPQ+i KJ1zTr8SYFpzEBYQ/TaJGlChJF0UHYvTSiRyJ5sjPGkzQtcPJMXoOj/lHIOSJ5FySLehC4FzEpX0 FdJSPzsVJCWlTs0SLQcBFW6EbwKTIJARVBDPTVbTNqDiFShwG2lRTJHuA5u0IXSFDP+PYjbxwQXv pBy18i73lDD1lDaPQ1rNVCGiMxv+tDOH0XWSUBs+lRDoUiI801ZnsyLv8DMXximzISSR0Ey18B8K IVwVAjH77SCyURu+QBEI5kXdlSS0QRZRUDaUNF5NAwW571uwVD+n4SC/kDIQLrwSJDLskynItBlp cwS30VA7tGPZ1UgLAl9QblxmkyBX6Cr19Amlgb9KUkj84Vqb4jdd8DpbVB2TkldWk1+vlf4GFgsS Ik5rsgQHQSBQITRv6GBfk0hJc0jjMuXSBGRtNFkLAQscJQSZ8EYKMBslVDaYVhsb4hmEtGkFZAIZ 4gaN5C138y8I9SiKMmMdouui69X/QIVhBbJVB6ILDXE8lXMnibQ7j8JKCeIevnA21U85X2FWljBY aaBPCnQtItYFCdUhB8Rfv2DGnJBZyHRDtjULXGHpDLEVsGE6CXExC7FQhXY6zU8bLGssi3Ijf5ZS xTIte3I6ZdQ24JIJZ5RcvwB10dNYAbci5SAP/qEk0ZMf/yIpR08hwlP9okknJvUVKiIpKVA2bTEf 1I9gvLU52cZ5XhHe3KQ91w9VahEkUeEsVXU9pWEpAtUpQVJGBqIYWnT9XoEnu/ZSz5cGToFXhBMg 8Y0k6zVtJTXl1OMnDRJfB5AfQUE5+VWBJfIgdSIEAVJVIjUjklMiKFga7fEf6PQm/+lUT8XBF77l DgjB/DRyXl/ydzdCAoux/fTXg+l0ACV1QD7SPWngI2k2R05YC8OUTn/S/PS2h8FyVtFXqBjV/MqS krBtkSRCbj9nOjDG53Lj4eYxUjSidC1iV9dmddjCafqw5JhwWyWLKdLuE+3j6TIPD7InNxqENGwH jSFQfPVCBRviGIwhX6qvcA2CPZDB68K3LrRYn0wOG1xBHEGlFMNoYE1TbrNiC3zGRWyj6c7YqcQ3 jqMlKyZOjL2vL/DBVcCr6iwKA9uDcoojIQhDUFzuHu7BPo9D8hSiaQjide3GQ4IYIf1D1HRvGkcG ln+NRoKj6QTPIuRTbawLPpStNf8SgpVTpEUw45jpeO00gn4RWTtkeZaPiRf1Ii8MIkjo8xlT41O0 j2sKpO+U9R/EwKg4Ypx5NUunc2FIBXEspfXGbl+abpSZgpoly8Cop4yR4i5Go60qozUMrxEdJJ2L xKCZ4h1VCCreQJGSQpHvjzEY2j+y4QB5mSAW6GGp5R86Z/eOQ1moQD6CrvZ4zUQw2mm0Tz4Dw5cv 4nUZglnKpAky2j7KpE/6YY8XLm2i2WKx+HsM4jd6j040Ih72MuPuIxiOtGnMLTcIN5AFjexcp5It Yk9s405uBA9KhTGeTW+MJOgsiJ23R45fsZtTAwZM7x9yDlFgpE3E2kUypkXesXP/Uroh9LmpO+b4 CPl7uKvVftlNXMUKTscRheUikufgYE/7xGYtZqX1BmKkH0KqxKWmq9kuXNH2FLqB8BKR4yHkhIqq +S8bivmt7Zbu3ESnCy8r2gSav6U2im0tXPpVWHuneZVUwk+qLZlatXnr8K8Xj+5VdAaeRK1EBjkf jtrGelsOAcORXUcbHgvvmJsxToyXVZmYHaIZmKcR484ylpltLru0Uw051mKQ7Vk/aeTd9IIYdMNU po2WgWY3MPQifBm0CVvnQsa6vXu3X8XwNrngNDi3+URkFLov9FlYtkbm6lq31yLg3ukRdaPPVMjl GOIYgPAiqMHexq6/5Vhwvs8f/xXnFa65if2D8SyCFoAELuzZKTAGYr6bRiJxS7qY1JCarD1bt60Q Fu277AQFLTw5NyRjYOqOIGqhUNBCbNqkSFSnxWHmIfJETTzctCdaxjWE5KDpLzjFInAmMgjlsY5a Q8Cluv9ConXDgob598oiL7puu51GyaO8k52PKxBERWD579Qiu3O6Vszxzg8iIwJD674laByrRab7 f8wZyqlYOKiY5SIHiBC7Rc4FfKeYj51GJyqaHQdFyjtQR158vV9DGtjDz0/chNg8yH+mH5hDxC9I XxK8p9GOL85tsC9iFsIRXubMqIykT1p5uEMlvCk6u+xmsj7ZoqKbstEkvlFdMHHwmiluG8dvnJLs GJB73ceTY7ZfzEUaZMDZ5kGJXaOF6mk+5+yUWylk725wbbsqvb4LLti3HTZTbp04et39Q9srmzEm CUD6JMTVjYJ4aSA097tRGz8svaJRYo+x3a/hPaOVBbSxkGfShDUmT9r5XVUCAgA7 ------=_NextPart_000_000E_01C80EC8.58969210-- From LauriewhitakerBingham@westerndemocrat.com Mon Oct 15 11:35:54 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhRz0-0000pJ-DO for nemo-archive@lists.ietf.org; Mon, 15 Oct 2007 11:35:54 -0400 Received: from cust.static.212-90-217-115.cybernet.ch ([212.90.217.115] helo=stzviviana.simatrade.local) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IhRyh-0001qR-Bo for nemo-archive@lists.ietf.org; Mon, 15 Oct 2007 11:35:36 -0400 Message-ID: <11eff801c80f41$02037110$1205a8c0@STZVIVIANA> From: "Ana Delarosa" To: Subject: Guaranteed rate over the life of your loan Date: Mon, 15 Oct 2007 17:32:40 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_11EFF4_01C80F41.02037110" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 This is a multi-part message in MIME format. ------=_NextPart_000_11EFF4_01C80F41.02037110 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Let us assist with the placement of working capital business loans for = small to medium sized businesses in all 50 states We've created an affordable, simple, and flexible approach to providing = working capital of $5,000 to $500,000 or more. No obligation application. No cost to apply. No closing costs. Poor = credit not a problem. Get approved in 48 hours! with a simple application process & quick = funding, Call Us Free on 877-347-3607 ------=_NextPart_000_11EFF4_01C80F41.02037110 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Let us assist with the placement of = working=20 capital business loans for small to medium sized businesses in all 50=20 states
 
We've created an affordable, simple, = and flexible=20 approach to providing working capital of $5,000 to $500,000 or=20 more.
=20
 
No obligation application. No cost = to apply. No=20 closing costs. Poor credit not a problem.
 
Get approved in 48 hours! with a = simple=20 application process & quick funding, Call Us Free on=20 877-347-3607
------=_NextPart_000_11EFF4_01C80F41.02037110-- From Essig@SEEDCO.ORG Tue Oct 16 05:05:47 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhiN1-0005he-EG for nemo-archive@lists.ietf.org; Tue, 16 Oct 2007 05:05:47 -0400 Received: from host3-89-static.88-82-b.business.telecomitalia.it ([82.88.89.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhiN0-0002l2-SB for nemo-archive@lists.ietf.org; Tue, 16 Oct 2007 05:05:47 -0400 Received: from FRANCESCO ([178.197.86.57] helo=FRANCESCO) by host3-89-static.88-82-b.business.telecomitalia.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1tlIsr-000LEI-vQ for nemo-archive@lists.ietf.org; Tue, 16 Oct 2007 11:05:46 +0200 Message-ID: <000a01c80fd3$b4dabf90$03595852@FRANCESCO> From: "Daphne Essig" To: Subject: enetkeff Date: Tue, 16 Oct 2007 11:05:32 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C80FE4.78638F90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.3 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0006_01C80FE4.78638F90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello mom nemo-archive I feel like a full man now that i have an extra 3 inches http://fgroogle.com/ Daphne Essig ------=_NextPart_000_0006_01C80FE4.78638F90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hello mom nemo-archive
I feel like a full man now that i have an = extra 3=20 inches
http://fgroogle.com/
Daphne Essig
------=_NextPart_000_0006_01C80FE4.78638F90-- From Gita-Elsaesser@paintingjobs.co.uk Tue Oct 16 09:36:10 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihmag-00019c-EK for nemo-archive@lists.ietf.org; Tue, 16 Oct 2007 09:36:10 -0400 Received: from host145-194-dynamic.11-87-r.retail.telecomitalia.it ([87.11.194.145] helo=host119-37-dynamic.10-87-r.retail.telecomitalia.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhmaZ-0003Oj-7w for nemo-archive@lists.ietf.org; Tue, 16 Oct 2007 09:36:06 -0400 Received: from gianluca-8d52b8 by paintingjobs.co.uk with ASMTP id AF0899B3 for ; Tue, 16 Oct 2007 15:36:28 +0200 Received: from gianluca-8d52b8 ([185.172.141.22]) by paintingjobs.co.uk with ESMTP id 575A1D5F6DC8 for ; Tue, 16 Oct 2007 15:36:28 +0200 Message-ID: <000e01c80ff9$81b5ae60$77250a57@gianluca8d52b8> From: "Gita Elsaesser" To: Subject: essalifn Date: Tue, 16 Oct 2007 15:36:07 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C8100A.453E7E60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Antivirus: avast! (VPS 000781-2, 15/10/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 2.1 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0006_01C8100A.453E7E60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hey honey nemo-archive my wife wants sex all the time! I cant keep up http://giheatlh.com/ Gita Elsaesser ------=_NextPart_000_0006_01C8100A.453E7E60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hey honey nemo-archive
my wife wants sex all the time! I cant keep=20 up
http://giheatlh.com/
Gita Elsaesser
------=_NextPart_000_0006_01C8100A.453E7E60-- From tim.blatt@efs-ag.at Tue Oct 16 18:15:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhuhH-0002iu-HG for nemo-archive@lists.ietf.org; Tue, 16 Oct 2007 18:15:31 -0400 Received: from [200.85.130.146] (helo=usr146.unete.com.bo) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ihuh2-0000JK-Co for nemo-archive@lists.ietf.org; Tue, 16 Oct 2007 18:15:22 -0400 Received: from kfkv ([76.227.177.209]) by usr146.unete.com.bo (8.13.3/8.13.3) with SMTP id l9GMIIER044211; Tue, 16 Oct 2007 18:18:18 -0400 Message-ID: <471537E1.1020302@efs-ag.at> Date: Tue, 16 Oct 2007 18:14:57 -0400 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: What are your thoughts on this? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Exit Only Inc. Hits US Used Car Market! EXIT ONLY INC E X T O . P K Price: $0.43 EXTO used Canada for it's market testing ground for an online used car market that only charges for interested buyers. Now coming to the USA Used Car market, Private sellers and dealers alike are excited about the new venue. EXTO's sizzle is their fee structure. Sellers only pay for the details of interested buyers, with no hidden fees. In an exciting break Tuesday, EXTO announced that the US expansion to the site is ready to go. This is not one to wait around on. It is already trading and climbing for 2 months, Move on it before this new site hits the market. From raya889@mexicaltzingo.gob.mx Wed Oct 17 01:14:32 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii1Em-0003vT-2S for nemo-archive@lists.ietf.org; Wed, 17 Oct 2007 01:14:32 -0400 Received: from [189.4.174.137] (helo=[189.4.174.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ii1Eb-0006qk-Ti for nemo-archive@lists.ietf.org; Wed, 17 Oct 2007 01:14:22 -0400 Received: from bruno ([102.143.174.42]:23043 "EHLO bruno" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [189.4.174.137] with ESMTP id S22HUMSKTSUFMJTE (ORCPT ); Wed, 17 Oct 2007 02:14:04 -0300 Message-ID: <34C7A9C9.B625E688@mexicaltzingo.gob.mx> Date: Wed, 17 Oct 2007 02:13:47 -0300 From: "raya Dailey" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: traehwor Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.8 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea hello darling nemo-archive stretch her ass wide open with your new dick size http://www.hiothi.com/ raya Dailey From nemo-bounces@ietf.org Wed Oct 17 10:02:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii9RS-00011m-Ij; Wed, 17 Oct 2007 10:00:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii9RP-0000xG-QY; Wed, 17 Oct 2007 10:00:07 -0400 Received: from omta01sl.mx.bigpond.com ([144.140.92.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ii9RB-0005wJ-Mn; Wed, 17 Oct 2007 09:59:59 -0400 Received: from oaamta01sl.mx.bigpond.com ([124.190.106.219]) by omta01sl.mx.bigpond.com with ESMTP id <20071017135917.PJUU26650.omta01sl.mx.bigpond.com@oaamta01sl.mx.bigpond.com>; Wed, 17 Oct 2007 13:59:17 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta01sl.mx.bigpond.com with ESMTP id <20071017135917.WFA13338.oaamta01sl.mx.bigpond.com@PC20005>; Wed, 17 Oct 2007 13:59:17 +0000 From: "Hesham Soliman" To: , Date: Wed, 17 Oct 2007 23:59:07 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgQxeIU3weagNHDSpi4Htm5SEk99A== X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: Pasi.Eronen@nokia.com, 'Basavaraj Patil' Subject: [nemo] DSMIPv6 and IKE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Folks, We had a discussion in a smaller group about this problem, which was initially raised in one of Christain Kaas-Petersen's emails. The problem of integrating IKE and DSMIPv6 is fairly tricky because of the fact that each mechanism has its own NAT traversal method. So after discussing this with a couple of people I'll present three possible ways of solving this issue. Thanks to Pasi for writing up about 7 different options, Raj and Vidya for their input. Problem description: -------------------- DSMIPv6 obviously needs to provide a NAT traversal mechanism. The detection of a NAT relies on the BU/BA message exchange. If a NAT were detected, UDP encapsulation follows. Now, the problem is, for the BU to be sent, we need to run IKE, which has it's own ports/traversal mechanisms. So if we run IKE and send the BU over the IKE tunnel, the HA will not know what port number/address to send the MN's traffic to. Note that the MN cannot include the port number and address because clearly it doesn't know what those values are since they're allocated by the NAT. If we send the BU over port 4500 then we need to send another message (not secured) using DSMIPv6 port to the HA with every handover. I think this is unacceptable because we basically need to send two messages for handover and one of them has zero security. So the idea of using two ports (4500 and DSMIPv6 port) doesn't really work. And we don't have a way today of sending the BU separately over DSMIPv6 port. I.e., what's described in the draft is not possible today. Solution space: --------------- There are basically three ideas that were discussed in a small group: 1. Allow DSMIPv6 to look like a virtual link for IKE. Hence, IKE will simply run over IPv6 and will not be aware of IPv4 at all. 2. Run IKE over port 4500, but add "DSMIPV6_UDP_ENCAPSULATION" notification when negotiating ESP SAs 3. Add a new message in MIP6 that creates a port mapping in the NAT. The BU is still sent over 4500 and the new message is either insecure or (a long shot) secured by a crypto token exchanged in the BU/BA. Message format for solution 1: ------------------------------ IPv4 header (src=V4ADDR, dst=HA_V4ADDR) UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT) IPv6 header (src=V6HOA, dst=HAADDR) ESP header Mobility header BU [IPv4 HAO] IPv4 CoA option And IKE messages would look like: IPv4 header (src=V4ADDR, dst=HA_V4ADDR) UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT) IPv6 header (src=V6HOA, dst=HAADDR) UDP header (src=500, dst=500) IKE message... With this solution, the HA would essentially store the route information for the IKE messages (the port and address received in the outer header) and use them as dst address and port in the respose message. This information must not be stored permanently in the HA, only to respond to the messages. Obviously, if the IKE daemon in the HA silents ignores an IKE message then this information would have to be removed, so there would need to be a timeout or inter-process communication in the implementation. For the MN it's a lot simpler, source address selection for the IKE implementation would always return the V6HoA. Message format for solution 2: ------------------------------ IPv4 header (src=V4ADDR, dst=HA_V4ADDR) UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT) ESP header IPv6 header (src=V6HOA, dst=HAADDR) Mobility header BU [IPv4 HAO] IPv4 CoA option In this option we run IKE over port 4500, but add "DSMIPV6_UDP_ENCAPSULATION" notification when negotiating ESP SAs. Those ESP SAs would use src/dst port DSMIPv6-PORT. But we would still have to rely on IKE to either implicitly or explicitly update its ports and addresses whenever the mobile node moves. Option 3: --------- Basically we didn't work out message formats for this option. I think we all agreed that it's a long shot and, while interesting, it essentially involves designing a new method for MIPv6 security, which is not the best or fastest way to handle this problem. Conclusions: IMO each one of those solutions has it's own flaws. There is no clean and perfect solution above, but there are no clean solutions with NATs unfortunately. I'm personally inclined to go with alternative 1 but let's hear some opinions on this. Time is critical because there is a lot of pressure to move this draft to the IESG. Please send comments. Thanks, Hesham From nemo-bounces@ietf.org Wed Oct 17 14:03:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiDCu-0005ab-RH; Wed, 17 Oct 2007 14:01:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiDCs-0005YH-1L; Wed, 17 Oct 2007 14:01:22 -0400 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiDCq-0005Dh-NB; Wed, 17 Oct 2007 14:01:22 -0400 Received: from localhost ([127.0.0.1]:47096 helo=chardonnay.local ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1IiDCT-0001Su-18; Wed, 17 Oct 2007 20:00:57 +0200 Message-ID: <47164DE5.2060005@levkowetz.com> Date: Wed, 17 Oct 2007 20:01:09 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: Hesham@elevatemobile.com, mip6@ietf.org, nemo@ietf.org, Pasi.Eronen@nokia.com, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -1.4 (-) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: nemo@ietf.org, mip6@ietf.org, Pasi.Eronen@nokia.com Subject: [nemo] Re: [Mip6] DSMIPv6 and IKE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Hesham, all, On 2007-10-17 15:59 Hesham Soliman said the following: > Folks, > > We had a discussion in a smaller group about this problem, which was > initially raised in one of Christain Kaas-Petersen's emails... ... > There are basically three ideas that were discussed in a small group: > > 1. Allow DSMIPv6 to look like a virtual link for IKE. Hence, IKE will simply > run over IPv6 and will not be aware of IPv4 at all. ... ... > IMO each one of those solutions has it's own flaws. There is no clean and > perfect solution above, but there are no clean solutions with NATs > unfortunately. I'm personally inclined to go with alternative 1 but let's > hear some opinions on this. Time is critical because there is a lot of > pressure to move this draft to the IESG. Please send comments. I concur. Alternative 1 would be my preference, too. Henrik From Ilyfokt@aroundtheblocktv.com Wed Oct 17 14:53:07 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiE0x-0006lH-1t for nemo-archive@lists.ietf.org; Wed, 17 Oct 2007 14:53:07 -0400 Received: from host252-32-dynamic.8-79-r.retail.telecomitalia.it ([79.8.32.252]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiE0w-0007Nx-DL for nemo-archive@lists.ietf.org; Wed, 17 Oct 2007 14:53:06 -0400 Received: from pc-sabrina ([103.127.8.157] helo=pc-sabrina) by host252-32-dynamic.8-79-r.retail.telecomitalia.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1tDAeb-000VHW-Lh for nemo-archive@lists.ietf.org; Wed, 17 Oct 2007 20:53:24 +0200 Message-ID: <000301c810ee$f8dc7f00$fc20084f@pcsabrina> From: "bc Il" To: Subject: srotavon Date: Wed, 17 Oct 2007 20:53:14 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C810FF.BC654F00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.5 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0008_01C810FF.BC654F00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nice to meet you nemo-archive watch her jaws drop when you roll out your bid penis http://goupetr.com/ bc Il ------=_NextPart_000_0008_01C810FF.BC654F00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Nice to meet you nemo-archive
watch her jaws drop when you roll out your bid = penis
http://goupetr.com/
bc Il
------=_NextPart_000_0008_01C810FF.BC654F00-- From SheridiligentDuarte@zabasearch.com Wed Oct 17 19:08:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiI0H-0003BX-G4 for nemo-archive@lists.ietf.org; Wed, 17 Oct 2007 19:08:41 -0400 Received: from [201.240.69.220] (helo=luestel) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IiI0D-00084g-87 for nemo-archive@lists.ietf.org; Wed, 17 Oct 2007 19:08:38 -0400 Message-ID: <19e401c81112$abe00d10$2101a8c0@luestel> From: "Lynne Meredith" To: Subject: Receive funds in as little as 5 days Date: Wed, 17 Oct 2007 17:47:12 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_19E0_01C81112.ABE00D10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 2.0 (++) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da This is a multi-part message in MIME format. ------=_NextPart_000_19E0_01C81112.ABE00D10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your credit history does not matter to us! If you have your own business and want IMMEDIATE cash to spend ANY way = you like or need Extra money to give the company a boost or require A = low interest loan - NO STRINGS ATTACHED, here is our deal we can offer = you TODAY (hurry, this deal will expire THIS EVENING): $35,000+ loan Hurry, when the deal is gone, it is gone. Simply Call Us... Don't worry about approval, your credit score will not disqualify you! Call Us Free on 877-347-3607 ------=_NextPart_000_19E0_01C81112.ABE00D10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
Your credit score does = not matter=20 to us!
=20
 
If you have your own = business and=20 need IMMEDIATE cash to spend ANY way you like or wish Extra money to = give your=20 business a boost or wish A low interest loan - NO STRINGS ATTACHED, = here is=20 the deal we can offer you THIS EVENING (hurry, this tender will expire=20 TODAY):
=20
 
$31,000+ = loan
 
Hurry, when best deal = is gone, it=20 is gone. Simply Call Us...
=20
 
Do not worry about = approval, your=20 credit history will not disqualify you!
=20
 
Call Us Free on=20 877-347-3607
------=_NextPart_000_19E0_01C81112.ABE00D10-- From Krystal_Sevor@criminal-lawyer.com Wed Oct 17 20:16:24 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiJ3o-0005Zq-J8 for nemo-archive@lists.ietf.org; Wed, 17 Oct 2007 20:16:24 -0400 Received: from 190-82-60-234.adsl.cust.tie.cl ([190.82.60.234] helo=[164.77.252.134]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiJ3e-0001kU-Se for nemo-archive@lists.ietf.org; Wed, 17 Oct 2007 20:16:15 -0400 Received: from USER2 ([136.149.22.165] helo=USER2) by 190-82-56-177.adsl.cust.tie.cl ( sendmail 8.13.3/8.13.1) with esmtpa id 1NUQmg-000XHP-BF for nemo-archive@lists.ietf.org; Wed, 17 Oct 2007 21:16:27 -0300 Message-ID: <000a01c8111c$1a252ea0$b13852be@USER2> From: "Krystal Sevor" To: Subject: nevahleb Date: Wed, 17 Oct 2007 21:16:17 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C81102.F4D7F6A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.4 (++++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0004_01C81102.F4D7F6A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hay dude nemo-archive keep the kitty kat happy and make ya cock massive http://www.haasacnc.com/ Krystal Sevor ------=_NextPart_000_0004_01C81102.F4D7F6A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hay dude nemo-archive
keep the kitty kat happy and make ya cock=20 massive
http://www.haasacnc.com/
Krystal Sevor
------=_NextPart_000_0004_01C81102.F4D7F6A0-- From MarcfurlongAlvarez@miamiherald.com Wed Oct 17 22:02:57 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiKiv-0003g2-HM for nemo-archive@lists.ietf.org; Wed, 17 Oct 2007 22:02:57 -0400 Received: from pool-72-64-124-123.dllstx.fios.verizon.net ([72.64.124.123] helo=xp.home) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IiKiv-0004Ce-99 for nemo-archive@lists.ietf.org; Wed, 17 Oct 2007 22:02:57 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host41557831.miamiherald.com (8.13.1/8.13.1) with SMTP id pbszlS7J37.728574.0Pm.2K0.0173433745641 for ; Wed, 17 Oct 2007 21:06:57 +0600 Message-ID: From: "Rafael Alvarez" To: Subject: Your order Date: Wed, 17 Oct 2007 21:06:57 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_D00A_01C8112B.E7BEDB90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_D00A_01C8112B.E7BEDB90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_D00A_01C8112B.E7BEDB90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_D00A_01C8112B.E7BEDB90-- From donsimoniGirard@ncbmav.org Thu Oct 18 04:40:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiQw7-0002E4-68 for nemo-archive@lists.ietf.org; Thu, 18 Oct 2007 04:40:59 -0400 Received: from [81.181.118.140] (helo=[81.181.118.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiQw2-0007GB-Dn for nemo-archive@lists.ietf.org; Thu, 18 Oct 2007 04:40:56 -0400 Received: from k-ffc4079c0d554 ([125.129.15.44]:2808 "EHLO k-ffc4079c0d554" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [81.181.118.140] with ESMTP id S22KMDVNMOMEYTWM (ORCPT ); Thu, 18 Oct 2007 11:41:14 +0300 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 18 Oct 2007 11:40:55 +0300 To: nemo-archive@lists.ietf.org From: "donsimoni Girard" Subject: mereel Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Big Hello nemo-archive you think your a decent size? well she dont think so http://www.iingos.com/ donsimoni Girard From nemo-bounces@ietf.org Thu Oct 18 20:34:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iifno-0005Pn-VA; Thu, 18 Oct 2007 20:33:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iifnm-0005Lp-IY; Thu, 18 Oct 2007 20:33:22 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iifng-0007xU-CA; Thu, 18 Oct 2007 20:33:22 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 17:33:05 -0700 Message-ID: <4717FB41.8040807@azairenet.com> Date: Thu, 18 Oct 2007 17:33:05 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2007 00:33:05.0100 (UTC) FILETIME=[9D1B78C0:01C811E7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: nemo@ietf.org, mip6@ietf.org, Pasi.Eronen@nokia.com Subject: [nemo] Re: [Mip6] DSMIPv6 and IKE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Hesham and others, Thanks for coming up with multiple solutions to this problem. I have a few comments below. Hesham Soliman wrote: > Message format for solution 1: > ------------------------------ > > IPv4 header (src=V4ADDR, dst=HA_V4ADDR) > UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT) > IPv6 header (src=V6HOA, dst=HAADDR) > ESP header > Mobility header > BU [IPv4 HAO] > IPv4 CoA option > > And IKE messages would look like: > > IPv4 header (src=V4ADDR, dst=HA_V4ADDR) > UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT) > IPv6 header (src=V6HOA, dst=HAADDR) > UDP header (src=500, dst=500) > IKE message... > > With this solution, the HA would essentially store the route information for > the IKE messages (the port and address received in the outer header) and use > them as dst address and port in the respose message. This solution would work, but I am not too comfortable with the temporary tunnel being setup for IKEv2 messages. We don't have such a thing for a MIPv6 home agent today. All tunnel state is created only after the successful exchange of a BU/BAck. This information must > not be stored permanently in the HA, only to respond to the messages. > Obviously, if the IKE daemon in the HA silents ignores an IKE message then > this information would have to be removed, so there would need to be a > timeout or inter-process communication in the implementation. For the MN > it's a lot simpler, source address selection for the IKE implementation > would always return the V6HoA. > > Message format for solution 2: > ------------------------------ > > IPv4 header (src=V4ADDR, dst=HA_V4ADDR) > UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT) > ESP header > IPv6 header (src=V6HOA, dst=HAADDR) > Mobility header > BU [IPv4 HAO] > IPv4 CoA option > > In this option we run IKE over port 4500, but add > "DSMIPV6_UDP_ENCAPSULATION" > notification when negotiating ESP SAs. Those ESP SAs would use src/dst > port DSMIPv6-PORT. I would like to know more about the "cons" of this solution. In this solution the BU/BAck is always sent over port 4500 using UDP ESP encapsultion, but actual DS-MIPv6 tunnel uses "DSMIPv6-PORT". This should work fine. > But we would still have to rely on IKE to either implicitly or explicitly > update its ports and addresses whenever the mobile node moves. But today we *do not* assume that the exchange of a BU/BAck always updates the IKE SA. What if we assume the 'K' flag is always cleared when the mobile node is attached to an IPv4 access network. Of course this would always result in an IKEv2 exchange, in addition to the BU/BAck exchange every time the CoA changes. This is not so bad, since this defaults to lack of support for the 'K' flag. Vijay From mext-bounces@ietf.org Fri Oct 19 01:41:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IikXK-0007XY-J4; Fri, 19 Oct 2007 01:36:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IikXI-0007RI-C3 for mext@ietf.org; Fri, 19 Oct 2007 01:36:40 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IikX5-0007cG-IS for mext@ietf.org; Fri, 19 Oct 2007 01:36:33 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 07:35:59 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C81211.EDB278C4" Date: Fri, 19 Oct 2007 07:35:58 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222D795@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-korhonen-mip6-service-04.txt Thread-Index: AcgRhw5RAzk6KPClRJe102w+RMSO7gAip/hw From: To: X-OriginalArrivalTime: 19 Oct 2007 05:35:59.0559 (UTC) FILETIME=[EDEDD570:01C81211] X-Spam-Score: -4.0 (----) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [MEXT] FW: I-D Action:draft-korhonen-mip6-service-04.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C81211.EDB278C4 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable FYI.. The draft has now been updated based on Jari's comments. Cheers, Jouni > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Thursday, October 18, 2007 3:30 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-korhonen-mip6-service-04.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 > Title : Service Selection for Mobile IPv6 > Author(s) : J. Korhonen, et al. > Filename : draft-korhonen-mip6-service-04.txt > Pages : 7 > Date : 2007-10-18 >=20 > In some Mobile IPv6 deployments identifying the mobile node=20 > or the mobility service subscriber is not enough to=20 > distinguish between multiple services possibly provisioned to=20 > the said mobile node and its mobility service subscription. =20 > A capability to specify different services in addition to the=20 > mobile node identity can be leveraged to provide flexibility=20 > for mobility service providers on provisioning multiple=20 > services to one mobility service subscription. This document=20 > describes a Service Selection Mobility Option for both=20 > conventional Mobile IPv6 and Proxy Mobile IPv6 that is=20 > intended to assist home agents to make a specific service=20 > selection for the mobility service subscription during the=20 > binding registration procedure. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-korhonen-mip6-service-04.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. ------_=_NextPart_001_01C81211.EDB278C4 Content-Type: text/plain; charset="us-ascii"; name="draft-korhonen-mip6-service-04.txt" Content-Transfer-Encoding: base64 Content-Description: draft-korhonen-mip6-service-04.txt Content-Disposition: attachment; filename="draft-korhonen-mip6-service-04.txt" RklMRSBRVUFSQU5USU5FRA0KLS0tLS0tLS0tLS0tLS0tLQ0KDQpNaWNyb3NvZnQgQW50aWdlbiBm b3IgRXhjaGFuZ2UgcmVtb3ZlZCBhIGZpbGUgc2luY2UgaXQgd2FzIGZvdW5kIHRvIG1hdGNoIGEg ZmlsdGVyLg0KRmlsZSBuYW1lOiAiZHJhZnRfa29yaG9uZW5fbWlwNl9zZXJ2aWNlXzA0LlVSTCIN CkZpbHRlciBuYW1lOiAiRklMRSBGSUxURVI9IHVubmFtZWQ6ICoudXJsIg0K ------_=_NextPart_001_01C81211.EDB278C4 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext ------_=_NextPart_001_01C81211.EDB278C4-- From mike.armstrong@simla.colostate.edu Fri Oct 19 03:11:29 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iim13-0002AV-Mc for nemo-archive@lists.ietf.org; Fri, 19 Oct 2007 03:11:29 -0400 Received: from [59.94.119.166] (helo=nawlp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Iim0w-0001Ro-1s for nemo-archive@lists.ietf.org; Fri, 19 Oct 2007 03:11:24 -0400 Received: (qmail 4457 invoked from network); Fri, 19 Oct 2007 12:40:46 +0530 Received: from unknown (HELO eyr) (119.224.144.164) by nawlp with SMTP; Fri, 19 Oct 2007 12:40:46 +0530 Message-ID: <002001c8121f$2bc11760$a490e077@eyr> From: To: Subject: I could not believe this news break Date: Fri, 19 Oct 2007 12:40:46 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4029.2901 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4029.2901 X-Spam-Score: 2.8 (++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 News For Life Financial Reports: New Options For Online Vehicle Sales Exit Only Inc. EX T0 $0.41 Exit Only's initial web launch was in early May of 2007. Web-marketing of used vehicles is not a new concept. Posting of a sellers vehicle to the site without charge is something new to web based vehicle marketing. Now sellers are only paying for the contact information of actual interested buyers, and at only $2 per lead. Highlights: - The response from the market during the Canadian release was incredible. - The companies year end goals were met in just the first few months. - The US version of the site is now ready to be released to the market. - News in the last few weeks has released partnership agreements with several online vehicle service sites for increased exposure. - Exit is also providing mobile access for sellers. The system will deliver real-time leads of buyer information directly to their mobile phone. Duplication of the Canadian results in the much larger US market base will certainly make this company the next major online player. For more information on Exit Only Inc. contact your financial websites. International Update: Strikes paralyze Paris transport --- PARIS, France -- France's public transportation network came to a halt Thursday as public sector workers staged a series of strikes in what is seen as the first big test for President Nicolas Sarkozy's government. Subways, buses, and regional trains were all out of service, leading to traffic jams as commuters used their cars to get to work. Airlines were operating as usual, but some flights were delayed because employees were having trouble getting to work. Many Parisians took advantage of the capital's free bicycle program. Others hopped on scooters or strapped on Rollerblades, and some workers simply took the day off altogether. The walkout began Wednesday night and was expected to last 24 hours, but the backlog of services could mean the effects of the strike last much longer. Reports In The US: FBI agent: Boss rooted for mob family ----- NEW YORK -- The anecdote is so ingrained in Mafia lore that it was mimicked in a scene from the television show "The Sopranos": A corrupt FBI agent slapping his desk and celebrating news of another killing in a bloody mob civil war. A current FBI agent testified Wednesday that it happened in a real-life slip-up by ex-agent R. Lindley DeVecchio, now on trial for murder. "We're going to win this thing," DeVecchio blurted out at headquarters, according to the witness. Prosecutors said the 1992 outburst was further proof that DeVecchio secretly aligned himself with an informant within one of the warring factions of the Colombo crime family. From nemo-bounces@ietf.org Fri Oct 19 06:27:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iip39-0003ku-Eq; Fri, 19 Oct 2007 06:25:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iip36-0003A4-Hc; Fri, 19 Oct 2007 06:25:48 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iip2s-0006Hq-8H; Fri, 19 Oct 2007 06:25:34 -0400 Received: from oaamta03sl.mx.bigpond.com ([124.190.106.219]) by omta05sl.mx.bigpond.com with ESMTP id <20071019102528.JUQ16667.omta05sl.mx.bigpond.com@oaamta03sl.mx.bigpond.com>; Fri, 19 Oct 2007 10:25:28 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta03sl.mx.bigpond.com with ESMTP id <20071019102528.YAVK23886.oaamta03sl.mx.bigpond.com@PC20005>; Fri, 19 Oct 2007 10:25:28 +0000 From: "Hesham Soliman" To: , Date: Fri, 19 Oct 2007 20:25:18 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgR56BYSVhv7v+ERrmvTneqpYKa3QAQLYRgAARdbMA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] RE: [Mip6] DSMIPv6 and IKE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org I'll reply to both comments below. > > This solution would work, but I am not too comfortable with the > > temporary tunnel being setup for IKEv2 messages. We don't have > > such a thing for a MIPv6 home agent today. All tunnel state is > > created only after the successful exchange of a BU/BAck. > > I'm not also quite sure what exactly would be the tunnel > state created. For example, a message seen by the IKE daemon > would be simply: > > IPv6 header (src=V6HOA, dst=HAADDR) > UDP header (src=500, dst=500) > IKE message (IKE_SA_INIT request) > > and the reply sent would be > > IPv6 header (src=HAADDR, dst=V6HOA) > UDP header (src=500, dst=500) > IKE message (IKE_SA_INIT response) > > How would this actually get routed to the tunnel? To the kernel, > this looks just like an ordinary UDP packet going to V6HOA, and > would get sent out as usual (if we haven't done BU for the new > V4ADDR yet, it won't get sent there). => Basically the DSMIP6 code would have to capture any packet sent by the IKE daemon (known port)to the IPv6 home address that has already sent the original message. I think that would work. As you (Pasi) said, we would not create a route in the routing table, it would have to be treated as temporary state in the DSMIPv6 implementation. > In theory, we could have a modified DSMIPv6-only IKE daemon > that would understand the tunnel headers, and construct appropriate > replies, but then we're not talking about standard IPsec anymore. => I think we can do it without touching the IKE daemon. > > One solution that might work is putting the state information for > reply in the packet (as seen by IKE) itself: e.g. the source address > (as seen by IKE) would be "magic prefix:V4_ADDR:V4_PORT". But this > would be IPv6 NAT (although just inside a host -- so maybe not that > different to what e.g. HIP does by exposing just HITs to > applications)... => That's another way of doing it but we've been advised by the AD to not use mapped addresses at all and this is basically a mapped address. > > > > In this option we run IKE over port 4500, but add > > > "DSMIPV6_UDP_ENCAPSULATION" > > > notification when negotiating ESP SAs. Those ESP SAs would > > > use src/dst port DSMIPv6-PORT. > > > > I would like to know more about the "cons" of this solution. > > One obvious "con" is that it requires extensions to IPsec/IKE > (or in other words, IPsec/IKE implementation with DSMIPv6-specific > changes). => Agreed. > > > In this solution the BU/BAck is always sent over port 4500 > > using UDP ESP encapsultion, but actual DS-MIPv6 tunnel uses > > "DSMIPv6-PORT". This should work fine. > > Well... if the BU/BAck is sent over port 4500, we need some other > "BU-like" message that is sent over DSMIPv6-PORT. => Exactly. Hesham From nemo-bounces@ietf.org Fri Oct 19 07:25:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IipyE-0001VZ-Q0; Fri, 19 Oct 2007 07:24:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IipyD-0001BF-2n; Fri, 19 Oct 2007 07:24:49 -0400 Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iipxw-0007vG-II; Fri, 19 Oct 2007 07:24:33 -0400 Received: from oaamta02sl.mx.bigpond.com ([124.190.106.219]) by omta04sl.mx.bigpond.com with ESMTP id <20071019112428.SKMP21837.omta04sl.mx.bigpond.com@oaamta02sl.mx.bigpond.com>; Fri, 19 Oct 2007 11:24:28 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta02sl.mx.bigpond.com with ESMTP id <20071019112428.YPJL10066.oaamta02sl.mx.bigpond.com@PC20005>; Fri, 19 Oct 2007 11:24:28 +0000 From: "Hesham Soliman" To: , Date: Fri, 19 Oct 2007 21:24:15 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgR56BYSVhv7v+ERrmvTneqpYKa3QAQLYRgAARdbMAAAKdaoAABTTlg X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] RE: [Mip6] DSMIPv6 and IKE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > => Basically the DSMIP6 code would have to capture any packet sent > > by the IKE daemon (known port)to the IPv6 home address that has > > already sent the original message. I think that would work. As you > > (Pasi) said, we would not create a route in the routing table, it > > would have to be treated as temporary state in the DSMIPv6 > > implementation. > > This requires some special kernel tweaks to capture all traffic > sent by the IKE daemon (and apply special processing to some part > of it). > > If this special requirement only applies to IKE traffic (but not > ESP), it might be almost doable...but it's not exactly nice, > as all the messages at this point are unauthenticated. => Right, no disagreement about that it's not nice :) I just don't think any of the solutions we came up with are nice. At least with this option we can do everything with one message and without modifying IKE. I guess the lack of authentication affects things for a very short time. That is, if state is stored for T then T = P where P is the time it takes the IKE daemon to process the message. It's not that bad really, just a little bit longer than any connection request that a server would receive. > > BTW, ESP actually has a similar problem vs. the virtual link > tunnel. When the BU arrives in the HA, it would look like this: > > IPv4 header (src=NATTED_V4ADDR, dst=HA_V4ADDR) > UDP header (src=NATTED_DSMIPv6-PORT, dst=DSMIPv6-PORT) > IPv6 header (src=V6HOA, dst=HAADDR) > ESP header > Mobility header > BU [IPv4 HAO] > IPv4 CoA option > > After doing the "virtual link" decapsulation the packet > would look like this: > > IPv6 header (src=V6HOA, dst=HAADDR) > ESP header > Mobility header > BU [IPv4 HAO] > IPv4 CoA option > > And after IPsec processing, the module actually parsing > the MH will see: > > IPv6 header (src=V6HOA, dst=HAADDR) > Mobility header > BU [IPv4 HAO] > IPv4 CoA option > > In other words: it won't see the information it really needs > (NATTED_V4ADDR and NATTED_DSMIPv6_PORT)! Again, the host > clearly has this information, but getting it might require > some serious architectural tweaking of IPsec and TCP/IP > stack in general.... => I don't think this needs architectural changes to IPsec implementations. The module that calls IPsec will already have this information. When the packet comes back from IPsec to the calling module it can append this information for the next function. This is totally transparent to IPsec and limited to the DSMIPv6 implementation. Thanks, Hesham From nemo-bounces@ietf.org Fri Oct 19 08:07:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiqcP-00033J-Ho; Fri, 19 Oct 2007 08:06:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiqcN-000303-Db; Fri, 19 Oct 2007 08:06:19 -0400 Received: from mail1.tieto.com ([194.110.47.24] helo=tietoe03.tietoenator.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiqcH-0004DA-LR; Fri, 19 Oct 2007 08:06:19 -0400 X-AuditID: c26e2f18-0000229400001c7c-c2-47189d8830c5 Received: from stingray.eu.tieto.com ([192.176.143.13]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 15:05:28 +0300 Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 14:05:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Oct 2007 14:05:47 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIPv6 and IKE Thread-Index: AcgQxeIU3weagNHDSpi4Htm5SEk99ABeeK7A References: From: To: , , X-OriginalArrivalTime: 19 Oct 2007 12:05:48.0763 (UTC) FILETIME=[62FB22B0:01C81248] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: Pasi.Eronen@nokia.com Subject: [nemo] RE: [Mip6] DSMIPv6 and IKE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, I find that the problem description to be a little off from what I understood the problem to be and therefore I am also not totally in line with the proposed solutions. >=20 > Problem description: > -------------------- >=20 > DSMIPv6 obviously needs to provide a NAT traversal mechanism.=20 > The detection > of a NAT relies on the BU/BA message exchange. If a NAT were=20 > detected, UDP > encapsulation follows. Now, the problem is, for the BU to be=20 > sent, we need > to run IKE, which has it's own ports/traversal mechanisms.=20 > So if we run IKE and send the BU over the IKE tunnel, the HA=20 > will not know > what port number/address to send the MN's traffic to. Note that the MN > cannot include the port number=20 > and address because clearly it doesn't know what those values=20 > are since > they're allocated by the NAT.=20 >=20 > If we send the BU over port 4500 then we need to send another=20 > message (not > secured) using DSMIPv6 port to the HA with every handover. I=20 > think this is > unacceptable because we basically need to send two messages=20 > for handover and > one of them has zero security. So the idea of using two ports=20 > (4500 and > DSMIPv6 port) doesn't really work.=20 > And we don't have a way today of sending the BU separately=20 > over DSMIPv6 > port. I.e., what's described in the draft is not possible today.=20 A lot is said about sending the BU "over the IKE tunnel" and over the same ports=20 as IKE and IPSEC RFC 3948. Nothing is said about keeping the current design of sending the BU over a specific DSMIP port and then fixing the IKE and IPSEC port issues by a subsequent specific run of IKE to create the NAT port mappings for the 4500 port used by IKE and IPSec 3948.=20 By excluding this from the problem description, the solution is also excluded from the solution space. This way of looking at the problem do require multiple messages to complete the handover. Though still only one exchange for the BU to go through. The additional exchanges to ensure that all security SAs are up and running, that is: the IKE_SA which will ensure the continued aliveness of the ESP transport SA used to protect the BU as well as potential additional SAs for secure tunneling of payload=20 Is there a special reason why this solution is not looked at ? The solution does not fall into the category described above where it is said that one of the additional exchanges has zero security. > Solution space: > --------------- >=20 > There are basically three ideas that were discussed in a small group: >=20 > 1. Allow DSMIPv6 to look like a virtual link for IKE. Hence,=20 > IKE will simply > run over IPv6 and will not be aware of IPv4 at all.=20 >=20 > 2. Run IKE over port 4500, but add=20 > "DSMIPV6_UDP_ENCAPSULATION" notification > when negotiating ESP SAs >=20 > 3. Add a new message in MIP6 that creates a port mapping in=20 > the NAT. The BU > is still sent over 4500 and the new message is either=20 > insecure or (a long > shot) secured by a crypto token exchanged in the BU/BA.=20 Looking into the solutions proposed.=20 The first have the disadvantage that=20 we cannot benefit from IPSec and IKEs NAT traversal intelligence (e.g. RFC 3948), IPSEC SAs as IPSEC and IKE are now kept in the dark about the outer IP layers and NAT. Further it seems to make it even more complicated to handle IKE during movements, now IKE should be run on the CoA when in an Ipv6 foreign network (or Ipv6 homenetwork) but on the HoA when on an Ipv4 foreign network. Not so nice. Solution 2 seems to attempt to run IKE as normal but to have the RFC 3948 IPSEC SAs use a different port, namely the DSMIPv6 port. But then we distort the NAT traversality of IKE and IPSec which rely on the ports used in IKE to be the same as the port used in the 3948. (The latter has implications for when and how ports are updated in the IKE_SAs and the IPSec SAs when the NAT changes mappings). Solution 3 has the disadvantage that port 4500 is being overloaded. Today both IKE and 3948 ESP IPSec uses this port and there are rules for how one can detect whether a received packet is an IKE packet or an IPSec ESP packet, these rules are based on the fact that the SPI in the ESP header can never coincide with the beginning of the IKE header. With DSMIPv6, the next header will be an Ipv6 header and can it be guaranteed that the beginning of the Ipv6 header could not coincide with the SPI in the ESP header ? BR, Karen From alessioSaeleaw@remknetworks.com Fri Oct 19 13:12:05 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IivOH-00021p-5G for nemo-archive@lists.ietf.org; Fri, 19 Oct 2007 13:12:05 -0400 Received: from [67.65.113.59] (helo=ch-67-65-113-59.lcisp.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IivOB-00049I-JF for nemo-archive@lists.ietf.org; Fri, 19 Oct 2007 13:12:00 -0400 Received: from BARBARA ([168.155.15.195] helo=BARBARA) by ch-67-65-113-59.lcisp.com ( sendmail 8.13.3/8.13.1) with esmtpa id 1xWZLl-000WWF-ub for nemo-archive@lists.ietf.org; Fri, 19 Oct 2007 12:12:42 -0500 Message-ID: <000501c81273$305624b0$3b714143@BARBARA> From: "alessio Saeleaw" To: Subject: jakkeren Date: Fri, 19 Oct 2007 12:12:12 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C81249.47801CB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.6 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d ------=_NextPart_000_0008_01C81249.47801CB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Monday update. Symb: T A D F (Tactical Air Defense Services) Tactical Air Defense Services (TADS), a leading provider of tactical = aviation training and services to the United States and Allied Nations, has = quietly positioned itself to utilize a fleet of the most advanced fighter jets = and aerial refueling tankers in the world for military aviation training = needs. Those who get in now are likely to see profits soar through the = stratosphere. Headquartered at the Grayson County Airport in Denison, Texas =96 formerly the Perrin Air Force Base =96 Tactical Air Defense has the = capability to provide clients with the most comprehensive logistical, repair, and = aircraft training support available. TADS IS AS CLOSE AS IT COMES TO A SUREFIRE = MONEY-MAKER. ------=_NextPart_000_0008_01C81249.47801CB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Monday update.
Symb: T A D F (Tactical Air Defense = Services)
Tactical Air Defense Services (TADS), a = leading provider=20 of tactical aviation
training and services to the United States and = Allied=20 Nations, has quietly
positioned itself to utilize a fleet of the = most=20 advanced fighter jets and
aerial refueling tankers in the world for = military=20 aviation training needs.
Those who get in now are likely to see profits = soar=20 through the stratosphere.
Headquartered at the Grayson County Airport in = Denison,=20 Texas =96
formerly the Perrin Air Force Base =96 = Tactical Air=20 Defense has the capability
to provide clients with the most comprehensive = logistical, repair, and aircraft
training support available. TADS IS AS CLOSE = AS IT=20 COMES TO A SUREFIRE MONEY-MAKER.
------=_NextPart_000_0008_01C81249.47801CB0-- From nemo-bounces@ietf.org Fri Oct 19 20:03:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij1nS-0007Z6-DO; Fri, 19 Oct 2007 20:02:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij1nR-0007Us-09; Fri, 19 Oct 2007 20:02:29 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ij1nG-0008Hq-Bn; Fri, 19 Oct 2007 20:02:24 -0400 Received: from oaamta01sl.mx.bigpond.com ([124.190.106.219]) by omta05sl.mx.bigpond.com with ESMTP id <20071020000141.JSMY16667.omta05sl.mx.bigpond.com@oaamta01sl.mx.bigpond.com>; Sat, 20 Oct 2007 00:01:41 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta01sl.mx.bigpond.com with ESMTP id <20071020000136.BEAP23516.oaamta01sl.mx.bigpond.com@PC20005>; Sat, 20 Oct 2007 00:01:36 +0000 From: "Hesham Soliman" To: , , Date: Sat, 20 Oct 2007 10:01:27 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgQxeIU3weagNHDSpi4Htm5SEk99ABeeK7AABrNX5A= X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: Pasi.Eronen@nokia.com Subject: [nemo] RE: [Mip6] DSMIPv6 and IKE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > DSMIPv6 obviously needs to provide a NAT traversal mechanism. > > The detection > > of a NAT relies on the BU/BA message exchange. If a NAT were > > detected, UDP > > encapsulation follows. Now, the problem is, for the BU to be > > sent, we need > > to run IKE, which has it's own ports/traversal mechanisms. > > So if we run IKE and send the BU over the IKE tunnel, the HA > > will not know > > what port number/address to send the MN's traffic to. Note > that the MN > > cannot include the port number > > and address because clearly it doesn't know what those values > > are since > > they're allocated by the NAT. > > > > If we send the BU over port 4500 then we need to send another > > message (not > > secured) using DSMIPv6 port to the HA with every handover. I > > think this is > > unacceptable because we basically need to send two messages > > for handover and > > one of them has zero security. So the idea of using two ports > > (4500 and > > DSMIPv6 port) doesn't really work. > > And we don't have a way today of sending the BU separately > > over DSMIPv6 > > port. I.e., what's described in the draft is not possible today. > > > A lot is said about sending the BU "over the IKE tunnel" and over the > same ports > as IKE and IPSEC RFC 3948. > > Nothing is said about keeping the current design of sending > the BU over > a specific DSMIP port and then fixing the IKE and IPSEC port issues > by a subsequent specific run of IKE to create the NAT port > mappings for > the 4500 port > used by IKE and IPSec 3948. => How can we send the BU over DSMIP port? Can you provide a solution for this? Hos is the SA established ? > > By excluding this from the problem > description, the solution is also excluded from the solution space. > > This way of looking at the problem do require multiple messages to > complete the handover. Though still only one exchange for > the BU to go > through. => The point is, there are alternatives that would solve the problem with two messages every handover, but why should we do that if we can avoid it? > The additional exchanges to ensure that all security SAs are up and > running, that is: > the IKE_SA which will ensure the continued aliveness of the ESP > transport SA used to protect the BU > as well as potential additional SAs for secure tunneling of payload > > Is there a special reason why this solution is not looked at ? => What is the solution? We have two classes of solutions in the three alternatives I sent. One class covers the "two message approach", the other (alternative 1) does it with one message. What other solution do you propose? Please send it to the list. I saw an email from Christian that I haven't read yet, may be that's what you mean. But it sounds like you're proposing another alternative for the "two message" approach. All things being the same, I'm personally not in favour of doing two messages every handover because we have two NAT traversal mechanisms running in parallel. Seems very inefficient. > > The solution does not fall into the category described above where > it is said that one of the additional exchanges has zero security. > > > Solution space: > > --------------- > > > > There are basically three ideas that were discussed in a > small group: > > > > 1. Allow DSMIPv6 to look like a virtual link for IKE. Hence, > > IKE will simply > > run over IPv6 and will not be aware of IPv4 at all. > > > > 2. Run IKE over port 4500, but add > > "DSMIPV6_UDP_ENCAPSULATION" notification > > when negotiating ESP SAs > > > > 3. Add a new message in MIP6 that creates a port mapping in > > the NAT. The BU > > is still sent over 4500 and the new message is either > > insecure or (a long > > shot) secured by a crypto token exchanged in the BU/BA. > > > Looking into the solutions proposed. > > The first have the disadvantage that > we cannot benefit from IPSec and IKEs NAT traversal > intelligence (e.g. > RFC 3948), > IPSEC SAs as IPSEC and IKE are now kept in the dark about > the outer IP > layers and NAT. => What is IKEs NAT traversal intelligence? We don't use 3948 but I don't understand what features we're missing. > Further it seems to make it even more complicated to handle > IKE during > movements, now IKE should > be run on the CoA when in an Ipv6 foreign network (or Ipv6 > homenetwork) > but on the HoA when on an Ipv4 foreign network. => No, you don't actually have to do that, but you can do what you suggest above. But at worste this is only an issue when changing admin domains. I still think it's much better to live with this corner case than having the norm be two messages per handover. I think we should optimise the more common case. Hesham From Ivantra@1uno1.com Fri Oct 19 21:18:36 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij2z6-0006Xw-Bx for nemo-archive@lists.ietf.org; Fri, 19 Oct 2007 21:18:36 -0400 Received: from host-84-221-137-5.cust-adsl.tiscali.it ([84.221.137.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ij2yx-0001og-IT for nemo-archive@lists.ietf.org; Fri, 19 Oct 2007 21:18:36 -0400 Received: from angius-d1da9313 by 1uno1.com with ASMTP id 4613DA45 for ; Sat, 20 Oct 2007 03:19:08 +0200 Received: from angius-d1da9313 ([104.104.26.133]) by 1uno1.com with ESMTP id AD8D358AC322 for ; Sat, 20 Oct 2007 03:19:08 +0200 Message-ID: <000601c812b7$22ad3170$0589dd54@angiusd1da9313> From: "Ivantra Miguel" To: Subject: n{{silep Date: Sat, 20 Oct 2007 03:18:35 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C812C7.E6360170" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.5 (+++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0005_01C812C7.E6360170 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable How's tricks? nemo-archive ever think shes faking? make it the real deal every time http://keeleds.com/ Ivantra Miguel ------=_NextPart_000_0005_01C812C7.E6360170 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
How's tricks? nemo-archive
ever think shes faking? make it the real deal = every=20 time
http://keeleds.com/
Ivantra Miguel
------=_NextPart_000_0005_01C812C7.E6360170-- From ChelseasolemnCarmichael@williebird.com Sun Oct 21 06:29:22 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjY3e-0006T6-Iv for nemo-archive@lists.ietf.org; Sun, 21 Oct 2007 06:29:22 -0400 Received: from pool-70-104-138-208.nycmny.fios.verizon.net ([70.104.138.208] helo=laptop1.home) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IjY33-0004JE-Vt for nemo-archive@lists.ietf.org; Sun, 21 Oct 2007 06:28:46 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host44659792.williebird.com (8.13.1/8.13.1) with SMTP id W8rgmdey01.329378.vn0.XnB.7635744195457 for ; Sun, 21 Oct 2007 06:29:39 +0500 Message-ID: From: "Kendra Kern" To: Subject: Confirmation link Date: Sun, 21 Oct 2007 06:29:39 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_F59348_01C813CD.A4E1E430" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_F59348_01C813CD.A4E1E430 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_F59348_01C813CD.A4E1E430 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_F59348_01C813CD.A4E1E430-- From MarielNemes@datamax.gr Sun Oct 21 15:40:29 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijgez-0007hj-5g for nemo-archive@lists.ietf.org; Sun, 21 Oct 2007 15:40:29 -0400 Received: from [89.159.83.247] (helo=089159083247.chello.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ijgel-0004vx-8z for nemo-archive@lists.ietf.org; Sun, 21 Oct 2007 15:40:24 -0400 Received: by 10.184.109.47 with SMTP id VJPAMnDDgKGAK; Sun, 21 Oct 2007 21:40:11 +0200 (GMT) Received: by 192.168.162.47 with SMTP id tVXYKsRukEAZZN.1672517904505; Sun, 21 Oct 2007 21:40:09 +0200 (GMT) Message-ID: <000701c8141a$2ebe2e60$f7539f59@home> From: "Mariel Nemes" To: Subject: ngladder Date: Sun, 21 Oct 2007 21:40:06 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C8142A.F246FE60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Antivirus: avast! (VPS 000783-0, 21/10/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 3.7 (+++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0009_01C8142A.F246FE60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hey honey nemo-archive dont settle for average when you can have a pornstar dick http://lcgspllc.com/ Mariel Nemes ------=_NextPart_000_0009_01C8142A.F246FE60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hey honey nemo-archive
dont settle for average when you can have a = pornstar=20 dick
http://lcgspllc.com/
Mariel Nemes
------=_NextPart_000_0009_01C8142A.F246FE60-- From GrovertroutmanHeath@rotax-owner.com Sun Oct 21 15:59:49 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjgxA-0000vK-Oz for nemo-archive@lists.ietf.org; Sun, 21 Oct 2007 15:59:16 -0400 Received: from c-68-56-84-49.hsd1.fl.comcast.net ([68.56.84.49] helo=anne.hsd1.fl.comcast.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IjgxA-0007ZL-Gu for nemo-archive@lists.ietf.org; Sun, 21 Oct 2007 15:59:16 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host90476598.rotax-owner.com (8.13.1/8.13.1) with SMTP id 7EjABwlA29.550164.vqD.Uq6.1373516326663 for ; Sun, 21 Oct 2007 15:59:51 +0500 Message-ID: From: "Monte Fischer" To: Subject: Your order approved Date: Sun, 21 Oct 2007 15:59:51 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_DC46D_01C8141D.7A7FEBB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_DC46D_01C8141D.7A7FEBB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_DC46D_01C8141D.7A7FEBB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_DC46D_01C8141D.7A7FEBB0-- From Frigoiwy@barefootjeweler.com Sun Oct 21 17:37:53 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjiUb-0007oi-3f for nemo-archive@lists.ietf.org; Sun, 21 Oct 2007 17:37:53 -0400 Received: from pc-67-89-46-190.cm.vtr.net ([190.46.89.67]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjiUa-0002gR-GE for nemo-archive@lists.ietf.org; Sun, 21 Oct 2007 17:37:53 -0400 Received: from desktop ([180.135.104.24] helo=desktop) by pc-67-89-46-190.cm.vtr.net ( sendmail 8.13.3/8.13.1) with esmtpa id 1gKJsn-000THC-MZ for nemo-archive@lists.ietf.org; Sat, 20 Oct 2007 18:39:47 +0200 Message-ID: <02C9DF24.2CCD4C9B@barefootjeweler.com> Date: Sat, 20 Oct 2007 18:39:09 +0200 From: "zoran Frigo" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: lissaden Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.5 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea hello dad nemo-archive she told you she wasn't happy so make her day with a fat cock http://www.lenoxz.com/ zoran Frigo From OrvaluppercutMcfadden@driver-repository.be Sun Oct 21 19:25:51 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjkB4-0005Te-Uq for nemo-archive@lists.ietf.org; Sun, 21 Oct 2007 19:25:51 -0400 Received: from [195.224.48.34] (helo=travlap006.travco.co.uk) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IjkB4-0007MI-Ka for nemo-archive@lists.ietf.org; Sun, 21 Oct 2007 19:25:50 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host28404408.driver-repository.be (8.13.1/8.13.1) with SMTP id E9kN4oMa15.935371.fY1.wcN.7806297182859 for ; Mon, 22 Oct 2007 00:23:14 +0000 Message-ID: <793bb301c81439$b7262180$0c1fa8c0@TRAVLAP006> From: "Mauro Kaufman" To: Subject: Approval process Date: Mon, 22 Oct 2007 00:23:14 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_793BAF_01C81439.B7262180" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_793BAF_01C81439.B7262180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_793BAF_01C81439.B7262180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_793BAF_01C81439.B7262180-- From nemo-bounces@ietf.org Mon Oct 22 05:47:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijtqd-0002fN-11; Mon, 22 Oct 2007 05:45:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijtqa-0002bd-C1; Mon, 22 Oct 2007 05:45:20 -0400 Received: from ws000774.tietoenator.com ([193.12.181.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjtqO-00079W-84; Mon, 22 Oct 2007 05:45:15 -0400 X-AuditID: c10cb581-0000122400000124-4b-471c710d79a8 Received: from camaro.eu.tieto.com ([192.176.143.43]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 11:44:45 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 11:44:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Oct 2007 11:44:45 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIPv6 and IKE Thread-Index: AcgQxeIU3weagNHDSpi4Htm5SEk99ABeeK7AABrNX5AAdSpmEA== References: From: To: , , X-OriginalArrivalTime: 22 Oct 2007 09:44:46.0131 (UTC) FILETIME=[2E193830:01C81490] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: Pasi.Eronen@nokia.com Subject: [nemo] RE: [Mip6] DSMIPv6 and IKE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org =20 Hi Hesham, >=20 > =3D> How can we send the BU over DSMIP port? Can you provide a=20 > solution for > this?=20 > Hos is the SA established ?=20 >=20 Pls. see below. > >=20 > > By excluding this from the problem > > description, the solution is also excluded from the solution space. > >=20 > > This way of looking at the problem do require multiple messages to > > complete the handover. Though still only one exchange for=20 > > the BU to go > > through. >=20 > =3D> The point is, there are alternatives that would solve the=20 > problem with > two messages every handover, but why should we do that if we=20 > can avoid it?=20 >=20 Yes, 2 messages is a con, but it may still be less worse that the cons of the proposed 1 message alternatives. > > The additional exchanges to ensure that all security SAs are up and > > running, that is: > > the IKE_SA which will ensure the continued aliveness of the ESP > > transport SA used to protect the BU > > as well as potential additional SAs for secure tunneling=20 > of payload=20 > >=20 > > Is there a special reason why this solution is not looked at ? >=20 > =3D> What is the solution? We have two classes of solutions in the = three > alternatives I sent. One class covers the "two message=20 > approach", the other > (alternative 1) does it with one message. What other solution do you > propose? Please send it to the list. I saw an email from=20 > Christian that I > haven't read yet, may be that's what you mean. But it sounds=20 > like you're > proposing another alternative for the "two message" approach.=20 > All things > being the same, I'm personally not in favour of doing two=20 > messages every > handover because we have two NAT traversal mechanisms running=20 > in parallel. > Seems very inefficient. >=20 Yes, but it is only in the NAT traversal situation that we have 2 messages. When there is no NAT detected in the BU, the second message exchange (IKE run, pls. see below) need not be run. Yes, it is inefficient, but perhaps it is as efficient as it can be (?). > >=20 > >=20 > > Looking into the solutions proposed.=20 > >=20 > > The first have the disadvantage that=20 > > we cannot benefit from IPSec and IKEs NAT traversal=20 > > intelligence (e.g. > > RFC 3948), > > IPSEC SAs as IPSEC and IKE are now kept in the dark about=20 > > the outer IP > > layers and NAT. >=20 > =3D> What is IKEs NAT traversal intelligence? We don't use 3948=20 > but I don't > understand what features we're missing. How should we handle IPSec tunneling of payload from the MN to the HA: If IKE is kept unaware of the DSMIP tunnel, then it cannot negotiate Ipv6 in Ipv4 ESP tunnels and specifically it can not negotiate RFC 3948 tunnels for Ipv6 in Udp in Ipv4 tunnels for NAT traversal. Consequently IPSec tunneling of payload will have to be double=20 tunneled on the MN HA link, i.e.,: IPv4-UDP-IPv6-ESP-IPv6-Payload (for NAT traversal) or=20 IPv4-IPv6-ESP-IPv6-Payload for no NAT traversal. Whereas today when IKE uses the CoA, it can negotiate RFC 3948 tunnels for this purpose, which will result in: IPv4-UDP-ESP-IPv6-Payload=20 or standard tunnels IPv4-ESP-IPv6-Payload=20 for no NAT traversal. yes, IPSec tunneling is only a SHOULD, and a corner case, as RO is no point really on an Ipv4 only link. But is that the same as we will go with this (inefficient :-) way of doing it ? Perhaps there is another way, without the double tunneling, which is escaping me ? I would like to advocate the solution described by Christian. He has described the solution in=20 a couple of mails, please see the last mail. I will here only highlight the details. Solution 4. Run BU, BACK as described in DSMIP to a specific port. The IPSEC transport ESP negotiated=20 for IPv6 can be used to protect the BU, BACK. The DSMIP layer will remove (respectively add) the outer IP-UDP headers before (respectively after) the packet is being IPSec decrypted (respectively encrypted). IKE can negotiate the transport SAs regardless of whether the CoA is the Ipv6 HoA or an Ipv4 (private or public) or and Ipv6 CoA. As in standard Mipv6 the transport SA in place is expected to be OK although the IKE SA is no longer valid as the MN end-point (the CoA) has moved.=20 When the BU detects no NAT. The IKE SA and all IPSec tunnel SAs can be updated as in standard MIPv6 as no UDP ports are in play, only the new CoA must be inserted in the IKE SA and the IPSEC SA. When the BU/BACK exchange informs the MN that a NAT was present then it need to start en IKE exchange so the ports in the IKE SA and associated IPSEC tunnel SAs can be appropriately updated. Now we are done. Yes it requires multiple exchanges to fix the IKE and IPSEC ports, but only in the case where a NAT is detected. Further it is only the traffic which relies on IPSEc tunneling which is impacted by the delay caused by the=20 additional IKE exchange. Hope this explains. BR, Karen From nemo-bounces@ietf.org Mon Oct 22 05:52:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjtxC-0005BD-Qi; Mon, 22 Oct 2007 05:52:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjtxA-00059d-89; Mon, 22 Oct 2007 05:52:08 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ijtx9-0004C4-Fa; Mon, 22 Oct 2007 05:52:08 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9M9pjnt010249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Oct 2007 02:51:46 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9M9pjRe000375; Mon, 22 Oct 2007 02:51:45 -0700 (PDT) Received: from NAEX16.na.qualcomm.com ([10.47.6.158]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Oct 2007 02:51:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Oct 2007 02:51:42 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF4B9543C@NAEX16.na.qualcomm.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIPv6 and IKE Thread-Index: AcgQxeIU3weagNHDSpi4Htm5SEk99ABeeK7AABrNX5AAeVJfYA== References: From: "Tsirtsis, George" To: "Hesham Soliman" , , , X-OriginalArrivalTime: 22 Oct 2007 09:51:45.0210 (UTC) FILETIME=[27E399A0:01C81491] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: Pasi.Eronen@nokia.com Subject: [nemo] RE: [Mip6] DSMIPv6 and IKE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi all, I also think that requiring more messages on every handoff should not be done lightly here. The solution proposed by Hesham seems efficient and others have also indicates that although it requires special processing of a limited number of messages, it looks doable....so IMO this is the preferred option here. Thanks George -----Original Message----- From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 Sent: Saturday, October 20, 2007 1:01 AM To: Karen.Nielsen@tietoenator.com; mip6@ietf.org; nemo@ietf.org Cc: Pasi.Eronen@nokia.com Subject: RE: [Mip6] DSMIPv6 and IKE > > DSMIPv6 obviously needs to provide a NAT traversal mechanism.=20 > > The detection > > of a NAT relies on the BU/BA message exchange. If a NAT were=20 > > detected, UDP > > encapsulation follows. Now, the problem is, for the BU to be=20 > > sent, we need > > to run IKE, which has it's own ports/traversal mechanisms.=20 > > So if we run IKE and send the BU over the IKE tunnel, the HA=20 > > will not know > > what port number/address to send the MN's traffic to. Note=20 > that the MN > > cannot include the port number=20 > > and address because clearly it doesn't know what those values=20 > > are since > > they're allocated by the NAT.=20 > >=20 > > If we send the BU over port 4500 then we need to send another=20 > > message (not > > secured) using DSMIPv6 port to the HA with every handover. I=20 > > think this is > > unacceptable because we basically need to send two messages=20 > > for handover and > > one of them has zero security. So the idea of using two ports=20 > > (4500 and > > DSMIPv6 port) doesn't really work.=20 > > And we don't have a way today of sending the BU separately=20 > > over DSMIPv6 > > port. I.e., what's described in the draft is not possible today.=20 >=20 >=20 > A lot is said about sending the BU "over the IKE tunnel" and over the > same ports=20 > as IKE and IPSEC RFC 3948. >=20 > Nothing is said about keeping the current design of sending=20 > the BU over > a specific DSMIP port and then fixing the IKE and IPSEC port issues > by a subsequent specific run of IKE to create the NAT port=20 > mappings for > the 4500 port > used by IKE and IPSec 3948.=20 =3D> How can we send the BU over DSMIP port? Can you provide a solution for this?=20 Hos is the SA established ?=20 >=20 > By excluding this from the problem > description, the solution is also excluded from the solution space. >=20 > This way of looking at the problem do require multiple messages to > complete the handover. Though still only one exchange for=20 > the BU to go > through. =3D> The point is, there are alternatives that would solve the problem with two messages every handover, but why should we do that if we can avoid it?=20 > The additional exchanges to ensure that all security SAs are up and > running, that is: > the IKE_SA which will ensure the continued aliveness of the ESP > transport SA used to protect the BU > as well as potential additional SAs for secure tunneling of payload=20 >=20 > Is there a special reason why this solution is not looked at ? =3D> What is the solution? We have two classes of solutions in the three alternatives I sent. One class covers the "two message approach", the other (alternative 1) does it with one message. What other solution do you propose? Please send it to the list. I saw an email from Christian that I haven't read yet, may be that's what you mean. But it sounds like you're proposing another alternative for the "two message" approach. All things being the same, I'm personally not in favour of doing two messages every handover because we have two NAT traversal mechanisms running in parallel. Seems very inefficient. >=20 > The solution does not fall into the category described above where > it is said that one of the additional exchanges has zero security. >=20 > > Solution space: > > --------------- > >=20 > > There are basically three ideas that were discussed in a=20 > small group: > >=20 > > 1. Allow DSMIPv6 to look like a virtual link for IKE. Hence,=20 > > IKE will simply > > run over IPv6 and will not be aware of IPv4 at all.=20 > >=20 > > 2. Run IKE over port 4500, but add=20 > > "DSMIPV6_UDP_ENCAPSULATION" notification > > when negotiating ESP SAs > >=20 > > 3. Add a new message in MIP6 that creates a port mapping in=20 > > the NAT. The BU > > is still sent over 4500 and the new message is either=20 > > insecure or (a long > > shot) secured by a crypto token exchanged in the BU/BA.=20 >=20 >=20 > Looking into the solutions proposed.=20 >=20 > The first have the disadvantage that=20 > we cannot benefit from IPSec and IKEs NAT traversal=20 > intelligence (e.g. > RFC 3948), > IPSEC SAs as IPSEC and IKE are now kept in the dark about=20 > the outer IP > layers and NAT. =3D> What is IKEs NAT traversal intelligence? We don't use 3948 but I don't understand what features we're missing. > Further it seems to make it even more complicated to handle=20 > IKE during > movements, now IKE should > be run on the CoA when in an Ipv6 foreign network (or Ipv6=20 > homenetwork) > but on the HoA when on an Ipv4 foreign network. =3D> No, you don't actually have to do that, but you can do what you suggest above. But at worste this is only an issue when changing admin domains. I still think it's much better to live with this corner case than having the norm be two messages per handover. I think we should optimise the more common case.=20 Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mext-bounces@ietf.org Mon Oct 22 05:59:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iju1d-0000kY-A9; Mon, 22 Oct 2007 05:56:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iju1b-0000jP-J7 for mext@ietf.org; Mon, 22 Oct 2007 05:56:43 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iju1S-0007fT-56 for mext@ietf.org; Mon, 22 Oct 2007 05:56:43 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id EDBFF198683; Mon, 22 Oct 2007 12:56:27 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 943D2198670; Mon, 22 Oct 2007 12:56:27 +0300 (EEST) Message-ID: <471C3B28.7020107@piuha.net> Date: Mon, 22 Oct 2007 08:54:48 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Jouni Korhonen Subject: Re: [MEXT] AD review of draft-korhonen-mip6-service-03.txt References: <4700A05C.3070905@piuha.net> In-Reply-To: <4700A05C.3070905@piuha.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 1.4 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org The new version addresses the concerns I had. Thanks. The document will now be moved forward. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From HadassahSanford@getdestroyed.de Mon Oct 22 07:51:06 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjvoI-0003Lm-CY for nemo-archive@lists.ietf.org; Mon, 22 Oct 2007 07:51:06 -0400 Received: from p54ae5f53.dip.t-dialin.net ([84.174.95.83]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjvoD-00018M-Dz for nemo-archive@lists.ietf.org; Mon, 22 Oct 2007 07:51:02 -0400 Received: from GESEC ([107.127.37.155] helo=GESEC) by p54AE5F53.dip.t-dialin.net ( sendmail 8.13.3/8.13.1) with esmtpa id 1uRwUq-000SCP-eS for nemo-archive@lists.ietf.org; Mon, 22 Oct 2007 15:01:58 +0200 Message-ID: <000b01c814ab$abee8d80$535fae54@GESEC> From: "Hadassah Sanford" To: Subject: ncollant Date: Mon, 22 Oct 2007 15:01:33 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C814BC.6F775D80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0003_01C814BC.6F775D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Watcha! nemo-archive bang your bitch in all positions with a massive meat http://ohberg.com/ Hadassah Sanford ------=_NextPart_000_0003_01C814BC.6F775D80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Watcha! nemo-archive
bang your bitch in all positions with a = massive=20 meat
http://ohberg.com/
Hadassah Sanford
------=_NextPart_000_0003_01C814BC.6F775D80-- From Helmand.kjguu@alexanderhdamsbo.dk Mon Oct 22 09:26:36 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjxIi-0004yz-5i for nemo-archive@lists.ietf.org; Mon, 22 Oct 2007 09:26:36 -0400 Received: from d83-186-157-20.cust.tele2.be ([83.186.157.20] helo=d83-186-152-85.cust.tele2.be) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjxIe-0000L4-LE for nemo-archive@lists.ietf.org; Mon, 22 Oct 2007 09:26:32 -0400 Received: from acer-36adea1256 by alexanderhdamsbo.dk with ASMTP id CCD5553B for ; Mon, 22 Oct 2007 15:26:04 +0200 Received: from acer-36adea1256 ([151.150.182.24]) by alexanderhdamsbo.dk with ESMTP id 26BDED5501D1 for ; Mon, 22 Oct 2007 15:26:04 +0200 Message-ID: <000401c814af$113816e0$5598ba53@acer36adea1256> From: "Helmand kjguu" To: Subject: lawaive Date: Mon, 22 Oct 2007 15:25:52 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C814BF.D4C0E6E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Antivirus: avast! (VPS 000783-0, 21/10/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 3.5 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0007_01C814BF.D4C0E6E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello love nemo-archive impress the girls with you new enlarged whopper http://obesuite.com/ Helmand kjguu ------=_NextPart_000_0007_01C814BF.D4C0E6E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hello love nemo-archive
impress the girls with you new enlarged=20 whopper
http://obesuite.com/
Helmand kjguu
------=_NextPart_000_0007_01C814BF.D4C0E6E0-- From nemo-bounces@ietf.org Mon Oct 22 09:58:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijxmg-0006H1-Fs; Mon, 22 Oct 2007 09:57:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjxlG-0004Gl-0w; Mon, 22 Oct 2007 09:56:06 -0400 Received: from omta02sl.mx.bigpond.com ([144.140.93.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ijxky-0003Dd-Eo; Mon, 22 Oct 2007 09:55:55 -0400 Received: from oaamta01sl.mx.bigpond.com ([124.190.106.219]) by omta02sl.mx.bigpond.com with ESMTP id <20071022135532.EZUU20745.omta02sl.mx.bigpond.com@oaamta01sl.mx.bigpond.com>; Mon, 22 Oct 2007 13:55:32 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta01sl.mx.bigpond.com with ESMTP id <20071022135531.ZCDY23516.oaamta01sl.mx.bigpond.com@PC20005>; Mon, 22 Oct 2007 13:55:31 +0000 From: "Hesham Soliman" To: , , Date: Mon, 22 Oct 2007 23:55:21 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgQxeIU3weagNHDSpi4Htm5SEk99ABeeK7AABrNX5AAdSpmEAAG8pfg X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: Pasi.Eronen@nokia.com Subject: [nemo] RE: [Mip6] DSMIPv6 and IKE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > > > => The point is, there are alternatives that would solve the > > problem with > > two messages every handover, but why should we do that if we > > can avoid it? > > > > Yes, 2 messages is a con, but it may still be less worse > that the cons of the proposed 1 message alternatives. => It's difficult to say what "less worse" means unless you can quantify it. > > => What is the solution? We have two classes of solutions > in the three > > alternatives I sent. One class covers the "two message > > approach", the other > > (alternative 1) does it with one message. What other > solution do you > > propose? Please send it to the list. I saw an email from > > Christian that I > > haven't read yet, may be that's what you mean. But it sounds > > like you're > > proposing another alternative for the "two message" approach. > > All things > > being the same, I'm personally not in favour of doing two > > messages every > > handover because we have two NAT traversal mechanisms running > > in parallel. > > Seems very inefficient. > > > > Yes, but it is only in the NAT traversal situation that we have 2 > messages. => Which is most of the time! > > > Looking into the solutions proposed. > > > > > > The first have the disadvantage that > > > we cannot benefit from IPSec and IKEs NAT traversal > > > intelligence (e.g. > > > RFC 3948), > > > IPSEC SAs as IPSEC and IKE are now kept in the dark about > > > the outer IP > > > layers and NAT. > > > > => What is IKEs NAT traversal intelligence? We don't use 3948 > > but I don't > > understand what features we're missing. > > How should we handle IPSec tunneling of payload from the MN > to the HA: > > If IKE is kept unaware of the DSMIP tunnel, then it cannot negotiate > Ipv6 in Ipv4 ESP tunnels and specifically it can not > negotiate RFC 3948 > tunnels > for Ipv6 in Udp in Ipv4 tunnels for NAT traversal. => Forgetting about 3948 tunnels because it's not an accident that we don't use it, why can't IKE negotiate those tunnels? > > IPv4-UDP-IPv6-ESP-IPv6-Payload (for NAT traversal) > > or > > IPv4-IPv6-ESP-IPv6-Payload > > for no NAT traversal. => Correct, I thought you were saying that it can't be done (above). > > Whereas today when IKE uses the CoA, it can negotiate RFC > 3948 tunnels > for this purpose, > which will result in: > > IPv4-UDP-ESP-IPv6-Payload > > or standard tunnels > > IPv4-ESP-IPv6-Payload > > for no NAT traversal. > > yes, IPSec tunneling is only a SHOULD, and a corner case, as RO is no > point really on an Ipv4 only link. > But is that the same as we will go with this (inefficient :-) way of > doing it ? > > Perhaps there is another way, without the double tunneling, which is > escaping me ? => I don't know if there can be another way and I doubt that there is one. I agree that we should try to reduce the tunnels but this is the choice that we're faced with. an extra header for the VPN case Vs two RTTs for handover. I'd like to get rid of both problems but it's not possible because of NATs. > Solution 4. > > Run BU, BACK as described in DSMIP to a specific port. The IPSEC > transport ESP negotiated > for IPv6 can be used to protect the BU, BACK. The DSMIP layer will > remove (respectively add) > the outer IP-UDP headers before (respectively after) the > packet is being > IPSec decrypted (respectively encrypted). > > IKE can negotiate the transport SAs regardless of whether > the CoA is the > Ipv6 HoA or an Ipv4 (private or public) > or and Ipv6 CoA. > > As in standard Mipv6 the transport SA in place is expected to be OK > although the IKE SA is no longer > valid as the MN end-point (the CoA) has moved. > > When the BU detects no NAT. The IKE SA and all IPSec tunnel > SAs can be > updated as in standard MIPv6 as no UDP ports are in play, > only the new CoA must be inserted in the IKE SA and the IPSEC SA. > > When the BU/BACK exchange informs the MN that a NAT was > present then it > need to start en IKE exchange so the > ports in the IKE SA and associated IPSEC tunnel SAs can be > appropriately > updated. > > Now we are done. > > Yes it requires multiple exchanges to fix the IKE and IPSEC > ports, but > only in the case where a NAT is detected. => Yes of course, but that's the majority of the cases! > Further it is only the traffic which relies on IPSEc > tunneling which is > impacted by the delay caused by the > additional IKE exchange. > > Hope this explains. => Ok but I want to make it clear that this falls under the "two message" class of solutions. You seemed to indicate in your last email that there was a class of solutions missing. So we still have to consider the same tradeoff that we're talking about now. I'm assuming that when you say IKE sets up the SA, you mean that there is no modification needed for IKE, correct? I'm not an IKE expert so can you elaborate on the IKE messages that will be sent over port 4500 to setup an SA for DSMIPv6 ports? Hesham > > BR, Karen > > From GalenresolutionLivingston@blinddogs.com Mon Oct 22 10:00:53 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijxpt-0001e8-PF for nemo-archive@lists.ietf.org; Mon, 22 Oct 2007 10:00:53 -0400 Received: from pc-227-83-83-200.cm.vtr.net ([200.83.83.227] helo=macultrun) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ijxps-0002eY-Nm for nemo-archive@lists.ietf.org; Mon, 22 Oct 2007 10:00:53 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host48031197.blinddogs.com (8.13.1/8.13.1) with SMTP id 5Qz7MUSd39.314648.SOt.GQG.5592089932626 for ; Mon, 22 Oct 2007 10:56:35 +0400 Message-ID: <30aa301c814b3$f352f1e0$e35353c8@macultrun> From: "Weldon Bean" To: Subject: Approval process Date: Mon, 22 Oct 2007 10:56:35 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_30A9F_01C814B3.F352F1E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Antivirus: avast! (VPS 0635-3, 31-08-2006), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_30A9F_01C814B3.F352F1E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_30A9F_01C814B3.F352F1E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_30A9F_01C814B3.F352F1E0-- From AlexisfrozeCummins@botjunkie.com Mon Oct 22 12:19:25 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijzzx-0004vR-Q0 for nemo-archive@lists.ietf.org; Mon, 22 Oct 2007 12:19:25 -0400 Received: from [190.41.7.171] (helo=paicom) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ijzzv-0003RR-CV for nemo-archive@lists.ietf.org; Mon, 22 Oct 2007 12:19:23 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host49583729.botjunkie.com (8.13.1/8.13.1) with SMTP id 6UYHVXHH08.372425.oTn.IFS.6972622845093 for ; Mon, 22 Oct 2007 11:18:57 +0500 Message-ID: <9228b01c814c7$9d72c110$2101a8c0@paicom> From: "Elvira Salgado" To: Subject: Your order approved Date: Mon, 22 Oct 2007 11:18:57 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_92287_01C814C7.9D72C110" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_92287_01C814C7.9D72C110 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_92287_01C814C7.9D72C110 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_92287_01C814C7.9D72C110-- From nemo-bounces@ietf.org Mon Oct 22 16:54:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik4Gc-0004QG-C4; Mon, 22 Oct 2007 16:52:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik4GZ-0004Mh-Vr; Mon, 22 Oct 2007 16:52:52 -0400 Received: from mail1.tieto.com ([194.110.47.24] helo=tietoe03.tietoenator.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik4GY-0001Jc-Up; Mon, 22 Oct 2007 16:52:51 -0400 X-AuditID: c26e2f18-00001ea8000021a8-2e-471d0d8c22cd Received: from camaro.eu.tieto.com ([192.176.143.42]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 23:52:28 +0300 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 22:52:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Oct 2007 22:51:29 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIPv6 and IKE Thread-Index: AcgQxeIU3weagNHDSpi4Htm5SEk99ABeeK7AABrNX5AAdSpmEAAG8pfgABFwDSA= References: From: To: X-OriginalArrivalTime: 22 Oct 2007 20:52:48.0168 (UTC) FILETIME=[80DAB280:01C814ED] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] RE: [Mip6] DSMIPv6 and IKE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Hesham,=20 > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Monday, October 22, 2007 3:55 PM > To: Nielsen Karen E; mip6@ietf.org; nemo@ietf.org > Cc: Pasi.Eronen@nokia.com > Subject: RE: [Mip6] DSMIPv6 and IKE >=20 >=20 > > >=20 > > > =3D> The point is, there are alternatives that would solve the=20 > > > problem with > > > two messages every handover, but why should we do that if we=20 > > > can avoid it?=20 > > >=20 > >=20 > > Yes, 2 messages is a con, but it may still be less worse > > that the cons of the proposed 1 message alternatives. >=20 > =3D> It's difficult to say what "less worse" means unless you=20 > can quantify it. In my opinion, I was doing that below. But I apologize for=20 giving soft words instead of technical arguments. >=20 >=20 > > > =3D> What is the solution? We have two classes of solutions=20 > > in the three > > > alternatives I sent. One class covers the "two message=20 > > > approach", the other > > > (alternative 1) does it with one message. What other=20 > > solution do you > > > propose? Please send it to the list. I saw an email from=20 > > > Christian that I > > > haven't read yet, may be that's what you mean. But it sounds=20 > > > like you're > > > proposing another alternative for the "two message" approach.=20 > > > All things > > > being the same, I'm personally not in favour of doing two=20 > > > messages every > > > handover because we have two NAT traversal mechanisms running=20 > > > in parallel. > > > Seems very inefficient. > > >=20 > >=20 > > Yes, but it is only in the NAT traversal situation that we have 2 > > messages. >=20 > =3D> Which is most of the time!=20 >=20 OK, I accept that. > > > > Looking into the solutions proposed.=20 > > > >=20 > > > > The first have the disadvantage that=20 > > > > we cannot benefit from IPSec and IKEs NAT traversal=20 > > > > intelligence (e.g. > > > > RFC 3948), > > > > IPSEC SAs as IPSEC and IKE are now kept in the dark about=20 > > > > the outer IP > > > > layers and NAT. > > >=20 > > > =3D> What is IKEs NAT traversal intelligence? We don't use 3948=20 > > > but I don't > > > understand what features we're missing. > >=20 > > How should we handle IPSec tunneling of payload from the MN=20 > > to the HA: > >=20 > > If IKE is kept unaware of the DSMIP tunnel, then it cannot=20 > negotiate > > Ipv6 in Ipv4 ESP tunnels and specifically it can not=20 > > negotiate RFC 3948 > > tunnels > > for Ipv6 in Udp in Ipv4 tunnels for NAT traversal. >=20 > =3D> Forgetting about 3948 tunnels because it's not an accident=20 > that we don't > use it, why can't IKE negotiate those tunnels?=20 >=20 Why don't you want 3948 tunnels ? > >=20 > > IPv4-UDP-IPv6-ESP-IPv6-Payload (for NAT traversal) > >=20 > > or=20 > >=20 > > IPv4-IPv6-ESP-IPv6-Payload > >=20 > > for no NAT traversal. >=20 > =3D> Correct, I thought you were saying that it can't be done (above). I was saying that IKEv2 in this situation cannot negotiate Ipv6 in Ipv4 ESP tunnels, which is true. >=20 > >=20 > > Whereas today when IKE uses the CoA, it can negotiate RFC=20 > > 3948 tunnels > > for this purpose, > > which will result in: > >=20 > > IPv4-UDP-ESP-IPv6-Payload=20 > >=20 > > or standard tunnels > >=20 > > IPv4-ESP-IPv6-Payload=20 > >=20 > > for no NAT traversal. > >=20 > > yes, IPSec tunneling is only a SHOULD, and a corner case,=20 > as RO is no > > point really on an Ipv4 only link. > > But is that the same as we will go with this (inefficient=20 > :-) way of > > doing it ? > >=20 > > Perhaps there is another way, without the double=20 > tunneling, which is > > escaping me ? >=20 > =3D> I don't know if there can be another way and I doubt that=20 > there is one. I > agree that we should try to reduce the tunnels but this is=20 > the choice that > we're faced with. an extra header for the VPN case Vs two=20 > RTTs for handover. > I'd like to get rid of both problems but it's not possible=20 > because of NATs. >=20 > > Solution 4. > >=20 > > Run BU, BACK as described in DSMIP to a specific port. The IPSEC > > transport ESP negotiated=20 > > for IPv6 can be used to protect the BU, BACK. The DSMIP layer will > > remove (respectively add) > > the outer IP-UDP headers before (respectively after) the=20 > > packet is being > > IPSec decrypted (respectively encrypted). > >=20 > > IKE can negotiate the transport SAs regardless of whether=20 > > the CoA is the > > Ipv6 HoA or an Ipv4 (private or public) > > or and Ipv6 CoA. > >=20 > > As in standard Mipv6 the transport SA in place is expected to be OK > > although the IKE SA is no longer > > valid as the MN end-point (the CoA) has moved.=20 > >=20 > > When the BU detects no NAT. The IKE SA and all IPSec tunnel=20 > > SAs can be > > updated as in standard MIPv6 as no UDP ports are in play, > > only the new CoA must be inserted in the IKE SA and the IPSEC SA. > >=20 > > When the BU/BACK exchange informs the MN that a NAT was=20 > > present then it > > need to start en IKE exchange so the > > ports in the IKE SA and associated IPSEC tunnel SAs can be=20 > > appropriately > > updated. > >=20 > > Now we are done. > >=20 > > Yes it requires multiple exchanges to fix the IKE and IPSEC=20 > > ports, but > > only in the case where a NAT is detected. >=20 > =3D> Yes of course, but that's the majority of the cases!=20 Ok, I accept. >=20 > > Further it is only the traffic which relies on IPSEc=20 > > tunneling which is > > impacted by the delay caused by the=20 > > additional IKE exchange. > >=20 > > Hope this explains. >=20 > =3D> Ok but I want to make it clear that this falls under the=20 > "two message" > class of solutions. You seemed to indicate in your last email=20 > that there was > a class of solutions missing.=20 I am sorry if I mislead you. I was only trying to say that this 2 message exchange=20 solution wasn't one in which one of the messages had zero security, so I felt that it was missing from the general descriptions about 2 message exchange solutions given in your mail. I wanted to make sure that this solution was discarded for the right reasons. So we still have to consider=20 > the same tradeoff > that we're talking about now. I think that it is worthwhile to notice that the handover for all traffic which is not IPSec tunnel encapsulated on the MN=3DHA path is achieved in 1 RTT. I'm assuming that when you say=20 > IKE sets up the > SA, you mean that there is no modification needed for IKE,=20 > correct? I am not sure what you mean here.=20 But standard IKEv2 can negotiate=20 * the Ipv6 transport ESP SA from the MN to the HA required for Ipv6 level protection of the BU * standard IPSec tunnel (Ipv6 in Ipv4 or Ipv4 in Ipv4), the local end-point in the outer Ipv4 header of the tunnel SA being the HA's Ipv4 address, when there is no NAT * and, when there's a NAT in between the MN and the HA, ESP UDP encapsulated tunnel IPSec Sas (RFC 3948), the local end-point in the outer Ipv4 header of the tunnel SA being the HA's Ipv4 address and with an UDP header inserted. I'm not > an IKE expert so can you elaborate on the IKE messages that=20 > will be sent > over port 4500 to setup an SA for DSMIPv6 ports?=20 I am not entirely sure what you mean. If you mean whether IKE can negotiate an IPSEC ESP SA that takes an Ipv6 (or an Ipv4 packet) packet, encrypts it and append and Ipv4 header, UDP header to DSMIP port and ESP=20 header (in reverse order), then I don't think that standard IKE can do that over port 4500. If that it what you mean, then I may suddenly understand why we fail to understand one another. If you want the IPSec tunneled packets to look as if they were destined for the DSMIP port, then forget about everything I have=20 said. I don't understand why you would like to have that, if that is what you want indeed - ? - but that's a different discussion. Thanks ! Karen From Iwona_Villapando@moorestephens-santacana.es Mon Oct 22 18:11:12 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik5UO-0003i9-Eb for nemo-archive@lists.ietf.org; Mon, 22 Oct 2007 18:11:12 -0400 Received: from ip-63-131.powernet.bg ([85.187.63.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik5U9-0007i4-F9 for nemo-archive@lists.ietf.org; Mon, 22 Oct 2007 18:10:57 -0400 Received: from HOME-E827BDED81 ([152.191.7.172] helo=HOME-E827BDED81) by ip-63-131.powernet.bg ( sendmail 8.13.3/8.13.1) with esmtpa id 1fTRov-000MEC-FF for nemo-archive@lists.ietf.org; Tue, 23 Oct 2007 01:13:57 +0300 Message-ID: <000201c814f8$c7824f30$833fbb55@HOMEE827BDED81> From: "Iwona Villapando" To: Subject: onie`mes Date: Tue, 23 Oct 2007 01:13:31 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C81511.ECCF8730" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0006_01C81511.ECCF8730 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable hello friend nemo-archive never be nervous in bed again with a big strong dick http://onazaez.com/ Iwona Villapando ------=_NextPart_000_0006_01C81511.ECCF8730 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
hello friend nemo-archive
never be nervous in bed again with a big = strong=20 dick
http://onazaez.com/
Iwona Villapando
------=_NextPart_000_0006_01C81511.ECCF8730-- From nemo-bounces@ietf.org Mon Oct 22 18:14:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik5XN-0007sO-OV; Mon, 22 Oct 2007 18:14:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik5XL-0007nf-WA; Mon, 22 Oct 2007 18:14:16 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik5XI-0007yX-0M; Mon, 22 Oct 2007 18:14:12 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 15:14:11 -0700 Message-ID: <471D20B2.90001@azairenet.com> Date: Mon, 22 Oct 2007 15:14:10 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Tsirtsis, George" References: <2309978910A6A6478C2C7585692B0AF4B9543C@NAEX16.na.qualcomm.com> In-Reply-To: <2309978910A6A6478C2C7585692B0AF4B9543C@NAEX16.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2007 22:14:11.0163 (UTC) FILETIME=[DF589AB0:01C814F8] X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: nemo@ietf.org, mip6@ietf.org, Pasi.Eronen@nokia.com Subject: [nemo] Re: [Mip6] DSMIPv6 and IKE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Tsirtsis, George wrote: > Hi all, > > I also think that requiring more messages on every handoff should not be > done lightly here. This statement is not entirely correct. The IKEv2 exchange following a handover is not in the critical path. It can done much later after the handover. For example it could be done 60 seconds after the handover. The exchange of BU/BAck would update the binding right away. This would be equivalent to not supporting the 'K' bit in RFC 3775. In RFC 3775, if either the mobile node or the home agent is not capable of updating the IKEv2 SA based on the BU/BAck, there is always an IKEv2 exchange following the handover. > The solution proposed by Hesham seems efficient and > others have also indicates that although it requires special processing > of a limited number of messages, it looks doable....so IMO this is the > preferred option here. Depends. Using some temporary tunnel state and making IKEv2 run over that tunnel is not that straight forward. Vijay > > Thanks > George > > > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: Saturday, October 20, 2007 1:01 AM > To: Karen.Nielsen@tietoenator.com; mip6@ietf.org; nemo@ietf.org > Cc: Pasi.Eronen@nokia.com > Subject: RE: [Mip6] DSMIPv6 and IKE > > > > DSMIPv6 obviously needs to provide a NAT traversal mechanism. > > > The detection > > > of a NAT relies on the BU/BA message exchange. If a NAT were > > > detected, UDP > > > encapsulation follows. Now, the problem is, for the BU to be > > > sent, we need > > > to run IKE, which has it's own ports/traversal mechanisms. > > > So if we run IKE and send the BU over the IKE tunnel, the HA > > > will not know > > > what port number/address to send the MN's traffic to. Note > > that the MN > > > cannot include the port number > > > and address because clearly it doesn't know what those values > > > are since > > > they're allocated by the NAT. > > > > > > If we send the BU over port 4500 then we need to send another > > > message (not > > > secured) using DSMIPv6 port to the HA with every handover. I > > > think this is > > > unacceptable because we basically need to send two messages > > > for handover and > > > one of them has zero security. So the idea of using two ports > > > (4500 and > > > DSMIPv6 port) doesn't really work. > > > And we don't have a way today of sending the BU separately > > > over DSMIPv6 > > > port. I.e., what's described in the draft is not possible today. > > > > > > A lot is said about sending the BU "over the IKE tunnel" and over the > > same ports > > as IKE and IPSEC RFC 3948. > > > > Nothing is said about keeping the current design of sending > > the BU over > > a specific DSMIP port and then fixing the IKE and IPSEC port issues > > by a subsequent specific run of IKE to create the NAT port > > mappings for > > the 4500 port > > used by IKE and IPSec 3948. > > => How can we send the BU over DSMIP port? Can you provide a solution > for > this? > Hos is the SA established ? > > > > > By excluding this from the problem > > description, the solution is also excluded from the solution space. > > > > This way of looking at the problem do require multiple messages to > > complete the handover. Though still only one exchange for > > the BU to go > > through. > > => The point is, there are alternatives that would solve the problem > with > two messages every handover, but why should we do that if we can avoid > it? > > > The additional exchanges to ensure that all security SAs are up and > > running, that is: > > the IKE_SA which will ensure the continued aliveness of the ESP > > transport SA used to protect the BU > > as well as potential additional SAs for secure tunneling of payload > > > > Is there a special reason why this solution is not looked at ? > > => What is the solution? We have two classes of solutions in the three > alternatives I sent. One class covers the "two message approach", the > other > (alternative 1) does it with one message. What other solution do you > propose? Please send it to the list. I saw an email from Christian that > I > haven't read yet, may be that's what you mean. But it sounds like you're > proposing another alternative for the "two message" approach. All things > being the same, I'm personally not in favour of doing two messages every > handover because we have two NAT traversal mechanisms running in > parallel. > Seems very inefficient. > > > > > The solution does not fall into the category described above where > > it is said that one of the additional exchanges has zero security. > > > > > Solution space: > > > --------------- > > > > > > There are basically three ideas that were discussed in a > > small group: > > > > > > 1. Allow DSMIPv6 to look like a virtual link for IKE. Hence, > > > IKE will simply > > > run over IPv6 and will not be aware of IPv4 at all. > > > > > > 2. Run IKE over port 4500, but add > > > "DSMIPV6_UDP_ENCAPSULATION" notification > > > when negotiating ESP SAs > > > > > > 3. Add a new message in MIP6 that creates a port mapping in > > > the NAT. The BU > > > is still sent over 4500 and the new message is either > > > insecure or (a long > > > shot) secured by a crypto token exchanged in the BU/BA. > > > > > > Looking into the solutions proposed. > > > > The first have the disadvantage that > > we cannot benefit from IPSec and IKEs NAT traversal > > intelligence (e.g. > > RFC 3948), > > IPSEC SAs as IPSEC and IKE are now kept in the dark about > > the outer IP > > layers and NAT. > > => What is IKEs NAT traversal intelligence? We don't use 3948 but I > don't > understand what features we're missing. > > > Further it seems to make it even more complicated to handle > > IKE during > > movements, now IKE should > > be run on the CoA when in an Ipv6 foreign network (or Ipv6 > > homenetwork) > > but on the HoA when on an Ipv4 foreign network. > > => No, you don't actually have to do that, but you can do what you > suggest > above. But at worste this is only an issue when changing admin domains. > I > still think it's much better to live with this corner case than having > the > norm be two messages per handover. I think we should optimise the more > common case. > > Hesham > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > From SharronrunnethNeff@spearsmfg.com Mon Oct 22 18:41:51 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik5y3-0004ni-Bd for nemo-archive@lists.ietf.org; Mon, 22 Oct 2007 18:41:51 -0400 Received: from c-71-61-249-130.hsd1.pa.comcast.net ([71.61.249.130] helo=pc.hsd1.pa.comcast.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ik5xn-0001AR-Te for nemo-archive@lists.ietf.org; Mon, 22 Oct 2007 18:41:36 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host13584287.spearsmfg.com (8.13.1/8.13.1) with SMTP id HAk3aGEc56.072241.2Q8.k8I.4782417824320 for ; Mon, 22 Oct 2007 16:38:14 +0600 Message-ID: <2d8c0001c814fc$92058ad0$82f93d47@PC> From: "Sharron Dow" To: Subject: Your family Date: Mon, 22 Oct 2007 16:38:14 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_2D8BFC_01C814FC.92058AD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_2D8BFC_01C814FC.92058AD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_2D8BFC_01C814FC.92058AD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_2D8BFC_01C814FC.92058AD0-- From nemo-bounces@ietf.org Mon Oct 22 23:26:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkAOK-0008Gp-KL; Mon, 22 Oct 2007 23:25:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkAOI-00082Y-CM; Mon, 22 Oct 2007 23:25:14 -0400 Received: from mx06.syd.iprimus.net.au ([210.50.76.235]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkANw-0002ML-Hf; Mon, 22 Oct 2007 23:24:53 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CALcFHUfTG2yO/2dsb2JhbAA X-IronPort-AV: E=Sophos;i="4.21,315,1188741600"; d="scan'208";a="73462588" Received: from 142.001.vod.mel.iprimus.net.au (HELO PC20005) ([211.27.108.142]) by smtp06.syd.iprimus.net.au with ESMTP; 23 Oct 2007 13:24:45 +1000 From: "Hesham Soliman" To: Date: Tue, 23 Oct 2007 13:24:32 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: Thread-Index: AcgQxeIU3weagNHDSpi4Htm5SEk99ABeeK7AABrNX5AAdSpmEAAG8pfgABFwDSAAEF7c8A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] RE: [Mip6] DSMIPv6 and IKE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > => Forgetting about 3948 tunnels because it's not an accident > > that we don't > > use it, why can't IKE negotiate those tunnels? > > > > Why don't you want 3948 tunnels ? => Because I want to avoid running two traversal mechanisms simultaneously and ending up with two messages. > > => Ok but I want to make it clear that this falls under the > > "two message" > > class of solutions. You seemed to indicate in your last email > > that there was > > a class of solutions missing. > > I am sorry if I mislead you. I was only trying to say that this 2 > message exchange > solution wasn't one in which one of the messages had zero > security, so I > felt that it was missing > from the general descriptions about 2 message exchange > solutions given > in your mail. => OK, agreed. > So we still have to consider > > the same tradeoff > > that we're talking about now. > > I think that it is worthwhile to notice that the handover for all > traffic which is not > IPSec tunnel encapsulated on the MN=HA path is achieved in 1 RTT. => So you're saying that all IPsec tunnel encapsulated traffic is going over port 4500, right? IMO, from a performance point of view it's not good enough to tell a customer part of your traffic will take 1 RTT for handovers and the secure part will take 2 RTT. > I am not sure what you mean here. > But standard IKEv2 can negotiate > * the Ipv6 transport ESP SA from the MN to the HA required for Ipv6 > level protection of the BU > * standard IPSec tunnel (Ipv6 in Ipv4 or Ipv4 in Ipv4), the local > end-point in the outer Ipv4 header of the tunnel SA being > the HA's Ipv4 > address, when there is no NAT > * and, when there's a NAT in between the MN and the HA, ESP UDP > encapsulated tunnel IPSec Sas (RFC 3948), the local > end-point in the outer Ipv4 header of the tunnel SA being > the HA's Ipv4 > address and with an UDP header inserted. => Yes I understand that, but I'm talking about this: MN has address 10.0.0.1 A. MN's NATTED address for IKE: 61.0.0.1 outer port 30000 B. MN's NATTED address for DSMIP 61.0.0.100 outer port 40000 Given that IKE doesn't know anything about B, can it still negotiate an SA for DSMIP to send a BU? This is what I'm trying to understand. As much detail on the IKE messages as possible please. > > I am not entirely sure what you mean. If you mean whether IKE can > negotiate > an IPSEC ESP SA that takes an Ipv6 (or an Ipv4 packet) > packet, encrypts > it and append and Ipv4 header, UDP header to DSMIP port and ESP > header (in reverse order), then I don't think that standard > IKE can do > that over port 4500. > > If that it what you mean, then I may suddenly understand why > we fail to > understand one another. > If you want the IPSec tunneled packets to look as if they > were destined > for the DSMIP port, then forget about everything I have > said. => I'm not sure if we're on the same page here. You're saying that you can send a BU secured with ESP, using DSMIP ports, correct? I.e. using the same numbers above: src = 10.0.0.1 dst = HAv4 UDP src port = 15000 dst port = DSMIPv6port src6 = HoA dst6 = HA6 ESP BU Is this correct? My question above is how did you setup this SA? Hesham From TreyirritateBright@allafrica.com Tue Oct 23 00:26:59 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkBM3-0006lh-7C for nemo-archive@lists.ietf.org; Tue, 23 Oct 2007 00:26:59 -0400 Received: from [190.128.15.119] (helo=emilio.belkin) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IkBM2-0006xL-Lh for nemo-archive@lists.ietf.org; Tue, 23 Oct 2007 00:26:59 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host59917997.allafrica.com (8.13.1/8.13.1) with SMTP id sMxIZRT240.467996.V2X.sRo.4415102645963 for ; Mon, 22 Oct 2007 23:25:58 +0500 Message-ID: <103ae01c8152c$ecd44de0$0302a8c0@emilio> From: "Deon Baird" To: Subject: Your family Date: Mon, 22 Oct 2007 23:25:58 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_103AA_01C8152C.ECD44DE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_103AA_01C8152C.ECD44DE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_103AA_01C8152C.ECD44DE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_103AA_01C8152C.ECD44DE0-- From Vartan-kaderac@dagenskonkurrencer.dk Tue Oct 23 02:05:24 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkCtI-0001rK-LA for nemo-archive@lists.ietf.org; Tue, 23 Oct 2007 02:05:24 -0400 Received: from cc734021-b.groni1.gr.home.nl ([82.73.195.146] helo=cc410503-b.groni1.gr.home.nl) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkCtG-0004cn-I9 for nemo-archive@lists.ietf.org; Tue, 23 Oct 2007 02:05:22 -0400 Received: from cc734021-b by dagenskonkurrencer.dk with ASMTP id B8AD8AFD for ; Tue, 23 Oct 2007 08:05:39 +0200 Received: from cc734021-b ([185.151.114.174]) by dagenskonkurrencer.dk with ESMTP id 3C6D3243E8EB for ; Tue, 23 Oct 2007 08:05:39 +0200 Message-ID: <000a01c8153a$b3e5d6d0$92c34952@cc734021b> From: "Vartan kaderac" To: Subject: zinserho Date: Tue, 23 Oct 2007 08:05:25 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C8154B.776EA6D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.6 (+++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0005_01C8154B.776EA6D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hay dude nemo-archive dont make hitting on the girls so hard, just show them your cock http://odyesey.com/ Vartan kaderac ------=_NextPart_000_0005_01C8154B.776EA6D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hay dude nemo-archive
dont make hitting on the girls so hard, just = show them=20 your cock
http://odyesey.com/
Vartan kaderac
------=_NextPart_000_0005_01C8154B.776EA6D0-- From CarabloodHaywood@affectedband.com Tue Oct 23 05:46:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkGLS-0007pv-Hc for nemo-archive@lists.ietf.org; Tue, 23 Oct 2007 05:46:42 -0400 Received: from 212.21.226.241.static.user.ono.com ([212.21.226.241] helo=sergio) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IkGLK-00076O-02 for nemo-archive@lists.ietf.org; Tue, 23 Oct 2007 05:46:34 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host58717671.affectedband.com (8.13.1/8.13.1) with SMTP id NREWWPGf13.433437.l95.fGZ.1920306965529 for ; Tue, 23 Oct 2007 11:45:45 -0100 Message-ID: <3687b01c81559$9866dd90$f1e215d4@sergio> From: "Rebekah Yeager" To: Subject: Your order approved Date: Tue, 23 Oct 2007 11:45:45 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_36877_01C81559.9866DD90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_36877_01C81559.9866DD90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_36877_01C81559.9866DD90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_36877_01C81559.9866DD90-- From Geary@praetersoftware.com Tue Oct 23 07:34:04 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkI1M-0003TW-7e for nemo-archive@lists.ietf.org; Tue, 23 Oct 2007 07:34:04 -0400 Received: from adsl-ull-59-84.42-151.net24.it ([151.42.84.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkI1L-0002Qq-K1 for nemo-archive@lists.ietf.org; Tue, 23 Oct 2007 07:34:04 -0400 Received: from orni ([101.125.2.113] helo=orni) by adsl-ull-59-84.42-151.net24.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1FcTKc-000JTI-sP for nemo-archive@lists.ietf.org; Tue, 23 Oct 2007 13:34:37 +0200 Message-ID: Date: Tue, 23 Oct 2007 13:34:07 +0200 From: "Ida Geary" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: arbejd Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.6 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea hay dude nemo-archive create your own sexual destiny and enlarge your cock http://perchin.com/ Ida Geary From RaulammanJohnston@aahoa.com Tue Oct 23 15:12:32 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkPB2-0004eW-SE for nemo-archive@lists.ietf.org; Tue, 23 Oct 2007 15:12:32 -0400 Received: from [190.129.120.164] (helo=talmaraz) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IkPB1-0000E4-GD for nemo-archive@lists.ietf.org; Tue, 23 Oct 2007 15:12:32 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host67048893.aahoa.com (8.13.1/8.13.1) with SMTP id HAmSZO9k27.120810.OSo.Xt5.9812507863602 for ; Tue, 23 Oct 2007 15:12:19 +0400 Message-ID: <5ee9601c815a8$d925a0b0$6404a8c0@talmaraz> From: "Rafael Carr" To: Subject: Your life Date: Tue, 23 Oct 2007 15:12:19 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_5EE92_01C815A8.D925A0B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------=_NextPart_000_5EE92_01C815A8.D925A0B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_5EE92_01C815A8.D925A0B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_5EE92_01C815A8.D925A0B0-- From MariamenuBoggs@askmen.com Tue Oct 23 21:52:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkVQY-0004fL-LX for nemo-archive@lists.ietf.org; Tue, 23 Oct 2007 21:52:59 -0400 Received: from [190.42.16.13] (helo=theartis106aa1) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IkVQX-0007vq-BR for nemo-archive@lists.ietf.org; Tue, 23 Oct 2007 21:52:58 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host01268789.askmen.com (8.13.1/8.13.1) with SMTP id TGFNOZ6r60.433400.GSs.Yev.7687069704087 for ; Tue, 23 Oct 2007 20:47:46 +0500 Message-ID: <12766b01c815e0$00801230$2101a8c0@theartis106aa1> From: "Ruth Hanna" To: Subject: Confirmation link Date: Tue, 23 Oct 2007 20:47:46 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_127667_01C815E0.00801230" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.6 (+++) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_127667_01C815E0.00801230 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_127667_01C815E0.00801230 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_127667_01C815E0.00801230-- From kienhcg@fuse.Net Tue Oct 23 22:25:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkVwO-0005G7-Cg for nemo-archive@lists.ietf.org; Tue, 23 Oct 2007 22:25:52 -0400 Received: from 20150062245.user.veloxzone.com.br ([201.50.62.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkVty-0000cX-5Y for nemo-archive@lists.ietf.org; Tue, 23 Oct 2007 22:25:52 -0400 Received: from compuser-1ec7ad ([178.114.103.21]:28576 "EHLO compuser-1ec7ad" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 20150062245.user.veloxzone.com.br with ESMTP id S22ZBKGORWDDMWTD (ORCPT ); Tue, 23 Oct 2007 23:23:58 -0300 Message-ID: <000c01c815e4$d81c01a0$f53e32c9@compuser1ec7ad> From: "lafonzo kien" To: Subject: fuaheurf Date: Tue, 23 Oct 2007 23:23:20 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C815CB.B2CEC9A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0004_01C815CB.B2CEC9A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello world nemo-archive forget trying to make your dick big, virility pills really do it! http://www.patrinha.com/ lafonzo kien ------=_NextPart_000_0004_01C815CB.B2CEC9A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hello world nemo-archive
forget trying to make your dick big, virility = pills=20 really do it!
http://www.patrinha.com/
lafonzo kien
------=_NextPart_000_0004_01C815CB.B2CEC9A0-- From GoldenBiggerton@americanlawnspecialists.com Wed Oct 24 10:12:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkgyA-00010Q-79 for nemo-archive@lists.ietf.org; Wed, 24 Oct 2007 10:12:26 -0400 Received: from host148-167-static.30-87-b.business.telecomitalia.it ([87.30.167.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikgxa-00068b-Al for nemo-archive@lists.ietf.org; Wed, 24 Oct 2007 10:11:51 -0400 Received: from Direzione ([147.180.56.29]:7484 "EHLO Direzione" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host148-167-static.30-87-b.business.telecomitalia.it with ESMTP id S22XKSGLXLPFVZKU (ORCPT ); Wed, 24 Oct 2007 16:12:02 +0200 Message-ID: <000e01c81647$d2719f90$94a71e57@Direzione> From: "Golden Biggerton" To: Subject: scutulum Date: Wed, 24 Oct 2007 16:11:50 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C81658.95FA6F90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Antivirus: avast! (VPS 000783-1, 22/10/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0008_01C81658.95FA6F90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hey you nemo-archive make your cock the main event at every sex session http://rgpamer.com/ Golden Biggerton ------=_NextPart_000_0008_01C81658.95FA6F90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hey you nemo-archive
make your cock the main event at every sex=20 session
http://rgpamer.com/
Golden Biggerton
------=_NextPart_000_0008_01C81658.95FA6F90-- From nemo-bounces@ietf.org Thu Oct 25 10:02:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il3Hm-0006OR-AU; Thu, 25 Oct 2007 10:02:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il3Hk-0006K5-Qx; Thu, 25 Oct 2007 10:02:08 -0400 Received: from omta01ps.mx.bigpond.com ([144.140.82.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il3HY-0004V2-N6; Thu, 25 Oct 2007 10:02:02 -0400 Received: from oaamta07ps.mx.bigpond.com ([124.190.106.219]) by omta01ps.mx.bigpond.com with ESMTP id <20071025140118.MAWQ13408.omta01ps.mx.bigpond.com@oaamta07ps.mx.bigpond.com>; Thu, 25 Oct 2007 14:01:18 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta07ps.mx.bigpond.com with ESMTP id <20071025140118.PRQB17155.oaamta07ps.mx.bigpond.com@PC20005>; Thu, 25 Oct 2007 14:01:18 +0000 From: "Hesham Soliman" To: , Date: Fri, 26 Oct 2007 00:01:06 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgXD2Nk409BdK32Rr+w24XNw+KidQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Subject: [nemo] DSMIPv6 and IKE - Summary and call for concensus X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Folks, This discussion has been going on for a while and I'm sure it wasn't for easy to follow. This email contains a summary of the discussion so far and a call for comment/concensus. Please respond promptly because there is some pressure from 3GPP to get this draft out very soon. The issue is how to run IKE in combination with DSMIPv6 in a private IPv4-only network. If you want more detail about why this is a problem please look at the thread "DSMIPv6 and IKE". There are three types of solutions that we discussed. A quick summary of each below: 1. The Virtual link approach. In this case IKE runs over v6 only and is completely unaware of the IPv4 network. As a result IKE's NAT traversal is never invoked. Only DSMIPv6's NAT traversal is used. In this approach, the DSMIPv6 implementation in the HA is required to cache the outer IPv4 address and source port of the IPv4 message that contains IKE, then append them to the response from its own IKE daemon. This is basically done to hide the IPv4 network from IKE and effectively disable its NAT traversal, which solves our problem. Three people agreed with this approach but two people (I'm including Christian) are against it. So there doesn't seem to be concensus on this. I believe the concern here was that the HA's caching of the outer address and port was complex for the implementation. 2. Karen suggested a way of running IKE without any changes (again see the thread for details). In this approach DSMIPv6 BUs are secured with ESP as usual. Normal traffic is sent over the DSMIPv6 port. However, secure traffic is sent over the IKE port (4500). The result of this approach is that it takes two messages to complete a handover, one from DSMIPv6 (BU) and an update from IKE (for the secure traffic). The concern that I had here in the discussion with Karen was the number of messages and the delays associated for that. Of course IKE doesn't do movement detection ...etc. So my concern is the discriminatory experience of the handover for different parts of the traffic. 3. The third class of solutions involves either modifying MIPv6 (adding new messages) or IKE or both. I'm only including this for completeness, no one really wants this. Please send your comments on the above. Basically the options are 1 or 2. In theory we could do both but I think it's best to pick one method for this to avoid interoperability issues and additional complexity. Hesham From helibar@novalineadue.com Thu Oct 25 19:31:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlCB2-0001NC-Gc for nemo-archive@lists.ietf.org; Thu, 25 Oct 2007 19:31:48 -0400 Received: from [89.156.169.174] (helo=089156169174.chello.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlCAz-0001nZ-2E for nemo-archive@lists.ietf.org; Thu, 25 Oct 2007 19:31:46 -0400 Received: from isis by novalineadue.com with ASMTP id 976E9EAA for ; Fri, 26 Oct 2007 01:31:55 +0200 Received: from isis ([129.169.148.11]) by novalineadue.com with ESMTP id 1293D0C6911B for ; Fri, 26 Oct 2007 01:31:55 +0200 Message-ID: <000801c8175f$2f757d20$aea99c59@isis> From: "pei helibar" To: Subject: lasnuluo Date: Fri, 26 Oct 2007 01:31:36 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C8176F.F2FE4D20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0005_01C8176F.F2FE4D20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Big Hello nemo-archive trust your own instinct, you know your dick needs to be big http://www.salyclub.com/ pei helibar ------=_NextPart_000_0005_01C8176F.F2FE4D20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Big Hello nemo-archive
trust your own instinct, you know your dick = needs to be=20 big
http://www.salyclub.com/
pei helibar
------=_NextPart_000_0005_01C8176F.F2FE4D20-- From nemo-bounces@ietf.org Fri Oct 26 01:43:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlHxb-0007HS-JQ; Fri, 26 Oct 2007 01:42:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlHxZ-0007HA-TT; Fri, 26 Oct 2007 01:42:17 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlHxZ-0003xy-Aa; Fri, 26 Oct 2007 01:42:17 -0400 Received: from [127.0.0.1] ([67.180.82.252]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 22:42:16 -0700 Message-ID: <47217E35.7010705@azairenet.com> Date: Thu, 25 Oct 2007 22:42:13 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2007 05:42:16.0387 (UTC) FILETIME=[F76D7930:01C81792] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Hesham, IMO, we should go with solution 2) below. I prefer that we let IKEv2 use its own NAT traversal mechanism. Regarding two round trips during a handover, note that the IKEv2 exchange to re-establish the IKEv2 SA and the IPsec SAs is not in the critical path of handover. The BU/BAck messages can be exchanged with the existing IPsec SAs. The IKEv2 exchange can be happen a few seconds (or minutes) after the handover. So there is *no* impact on the handover. This would be the same as the lack of support for the "K" flag in RFC 3775. In RFC 3775, if either the mobile node or the home agent are not capable of updating the IKE SA based on the exchange of BU/BAck, there is always an IKE exchange after the handover (or whenever the CoA changes). Please let me know if I am missing something related to the impact of the IKEv2 exchange on the handover. I am not comfortable with the temporary tunnel created in solution 1). Vijay Hesham Soliman wrote: > Folks, > > This discussion has been going on for a while and I'm sure it wasn't for > easy to follow. > This email contains a summary of the discussion so far and a call for > comment/concensus. Please respond promptly because there is some pressure > from 3GPP to get this draft out very soon. > > The issue is how to run IKE in combination with DSMIPv6 in a private > IPv4-only network. If you want more detail about why this is a problem > please look at the thread "DSMIPv6 and IKE". > > There are three types of solutions that we discussed. A quick summary of > each below: > > 1. The Virtual link approach. In this case IKE runs over v6 only and is > completely unaware of the IPv4 network. As a result IKE's NAT traversal is > never invoked. Only DSMIPv6's NAT traversal is used. In this approach, the > DSMIPv6 implementation in the HA is required to cache the outer IPv4 address > and source port of the IPv4 message that contains IKE, then append them to > the response from its own IKE daemon. This is basically done to hide the > IPv4 network from IKE and effectively disable its NAT traversal, which > solves our problem. > Three people agreed with this approach but two people (I'm including > Christian) are against it. So there doesn't seem to be concensus on this. I > believe the concern here was that the HA's caching of the outer address and > port was complex for the implementation. > > 2. Karen suggested a way of running IKE without any changes (again see the > thread for details). In this approach DSMIPv6 BUs are secured with ESP as > usual. Normal traffic is sent over the DSMIPv6 port. However, secure traffic > is sent over the IKE port (4500). The result of this approach is that it > takes two messages to complete a handover, one from DSMIPv6 (BU) and an > update from IKE (for the secure traffic). The concern that I had here in the > discussion with Karen was the number of messages and the delays associated > for that. Of course IKE doesn't do movement detection ...etc. So my concern > is the discriminatory experience of the handover for different parts of the > traffic. > > 3. The third class of solutions involves either modifying MIPv6 (adding new > messages) or IKE or both. I'm only including this for completeness, no one > really wants this. > > Please send your comments on the above. Basically the options are 1 or 2. In > theory we could do both but I think it's best to pick one method for this to > avoid interoperability issues and additional complexity. > > Hesham > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > From nemo-bounces@ietf.org Fri Oct 26 02:20:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlIY0-0006OL-76; Fri, 26 Oct 2007 02:19:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlIXy-0005Io-SZ; Fri, 26 Oct 2007 02:19:55 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlIXi-0005CU-51; Fri, 26 Oct 2007 02:19:38 -0400 Received: from oaamta07sl.mx.bigpond.com ([124.190.106.219]) by omta05sl.mx.bigpond.com with ESMTP id <20071026061934.LOBO14987.omta05sl.mx.bigpond.com@oaamta07sl.mx.bigpond.com>; Fri, 26 Oct 2007 06:19:34 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta07sl.mx.bigpond.com with ESMTP id <20071026061932.YABK5930.oaamta07sl.mx.bigpond.com@PC20005>; Fri, 26 Oct 2007 06:19:32 +0000 From: "Hesham Soliman" To: "'Vijay Devarapalli'" Date: Fri, 26 Oct 2007 16:19:23 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47217E35.7010705@azairenet.com> Thread-index: AcgXkvj8EUmQIo/vRg2DCVsK6a6TmwABPztA X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > IMO, we should go with solution 2) below. I prefer that we let > IKEv2 use its own NAT traversal mechanism. Regarding two round > trips during a handover, note that the IKEv2 exchange to > re-establish the IKEv2 SA and the IPsec SAs is not in the > critical path of handover. => It is in the critical path for the secure packets. That's what the discussion was about. The BU/BAck messages can be exchanged > with the existing IPsec SAs. The IKEv2 exchange can be happen a > few seconds (or minutes) after the handover. So there is *no* > impact on the handover. => No, see above. This is only good for insecure traffic. At least this is not solution 2 below. Hesham > > This would be the same as the lack of support for the "K" flag > in RFC 3775. In RFC 3775, if either the mobile node or the home > agent are not capable of updating the IKE SA based on the > exchange of BU/BAck, there is always an IKE exchange after the > handover (or whenever the CoA changes). > > Please let me know if I am missing something related to the > impact of the IKEv2 exchange on the handover. > > I am not comfortable with the temporary tunnel created in > solution 1). > > Vijay > > Hesham Soliman wrote: > > Folks, > > > > This discussion has been going on for a while and I'm sure > it wasn't for > > easy to follow. > > This email contains a summary of the discussion so far and > a call for > > comment/concensus. Please respond promptly because there > is some pressure > > from 3GPP to get this draft out very soon. > > > > The issue is how to run IKE in combination with DSMIPv6 in > a private > > IPv4-only network. If you want more detail about why this > is a problem > > please look at the thread "DSMIPv6 and IKE". > > > > There are three types of solutions that we discussed. A > quick summary of > > each below: > > > > 1. The Virtual link approach. In this case IKE runs over > v6 only and is > > completely unaware of the IPv4 network. As a result IKE's > NAT traversal is > > never invoked. Only DSMIPv6's NAT traversal is used. In > this approach, the > > DSMIPv6 implementation in the HA is required to cache the > outer IPv4 address > > and source port of the IPv4 message that contains IKE, > then append them to > > the response from its own IKE daemon. This is basically > done to hide the > > IPv4 network from IKE and effectively disable its NAT > traversal, which > > solves our problem. > > Three people agreed with this approach but two people (I'm > including > > Christian) are against it. So there doesn't seem to be > concensus on this. I > > believe the concern here was that the HA's caching of the > outer address and > > port was complex for the implementation. > > > > 2. Karen suggested a way of running IKE without any > changes (again see the > > thread for details). In this approach DSMIPv6 BUs are > secured with ESP as > > usual. Normal traffic is sent over the DSMIPv6 port. > However, secure traffic > > is sent over the IKE port (4500). The result of this > approach is that it > > takes two messages to complete a handover, one from > DSMIPv6 (BU) and an > > update from IKE (for the secure traffic). The concern that > I had here in the > > discussion with Karen was the number of messages and the > delays associated > > for that. Of course IKE doesn't do movement detection > ...etc. So my concern > > is the discriminatory experience of the handover for > different parts of the > > traffic. > > > > 3. The third class of solutions involves either modifying > MIPv6 (adding new > > messages) or IKE or both. I'm only including this for > completeness, no one > > really wants this. > > > > Please send your comments on the above. Basically the > options are 1 or 2. In > > theory we could do both but I think it's best to pick one > method for this to > > avoid interoperability issues and additional complexity. > > > > Hesham > > > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > From nemo-bounces@ietf.org Fri Oct 26 02:40:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlIqp-00055P-PJ; Fri, 26 Oct 2007 02:39:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlIqo-00055A-LV; Fri, 26 Oct 2007 02:39:22 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlIqi-0007HX-Ci; Fri, 26 Oct 2007 02:39:22 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9Q6cwad020001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 25 Oct 2007 23:38:59 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9Q6cv2v028024; Thu, 25 Oct 2007 23:38:58 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Oct 2007 23:38:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Oct 2007 23:38:57 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Thread-Index: AcgXD2Nk409BdK32Rr+w24XNw+KidQAii1/g References: From: "Narayanan, Vidya" To: "Hesham Soliman" , , X-OriginalArrivalTime: 26 Oct 2007 06:38:57.0228 (UTC) FILETIME=[E27CA0C0:01C8179A] X-Spam-Score: -4.0 (----) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Subject: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Hesham, A few comments inline. =20 > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Thursday, October 25, 2007 7:01 AM > To: mip6@ietf.org; nemo@ietf.org > Subject: [Mip6] DSMIPv6 and IKE - Summary and call for concensus >=20 > Folks, >=20 > This discussion has been going on for a while and I'm sure it=20 > wasn't for easy to follow.=20 > This email contains a summary of the discussion so far and a=20 > call for comment/concensus. Please respond promptly because=20 > there is some pressure from 3GPP to get this draft out very soon.=20 >=20 > The issue is how to run IKE in combination with DSMIPv6 in a=20 > private IPv4-only network. If you want more detail about why=20 > this is a problem please look at the thread "DSMIPv6 and IKE".=20 >=20 > There are three types of solutions that we discussed. A quick=20 > summary of each below: >=20 > 1. The Virtual link approach. In this case IKE runs over v6=20 > only and is completely unaware of the IPv4 network. As a=20 > result IKE's NAT traversal is never invoked. Only DSMIPv6's=20 > NAT traversal is used. In this approach, the > DSMIPv6 implementation in the HA is required to cache the=20 > outer IPv4 address and source port of the IPv4 message that=20 > contains IKE, then append them to the response from its own=20 > IKE daemon. This is basically done to hide the > IPv4 network from IKE and effectively disable its NAT=20 > traversal, which solves our problem.=20 > Three people agreed with this approach but two people (I'm including > Christian) are against it. So there doesn't seem to be=20 > concensus on this. I believe the concern here was that the=20 > HA's caching of the outer address and port was complex for=20 > the implementation. >=20 I'm not as concerned about the complexity aspect, but, I'm more concerned about the changes to the IPsec architecture this brings. I think this solution requires an SPD bypass rule to be setup for the DSMIP6 port that will first allow MIP6 to process the packets before IPsec has a chance to apply the SPD rule for BU. It is strange in that the IPsec protection is somehow sought for packets from the trusted boundary (i.e., MIP6 to IPsec in the same box) rather than the untrusted boundary (the packet coming in from the untrusted portion is the one to the DSMIP6 port and that is bypassed). One could argue that this isn't a big deal, but, given IPsec's design of inspecting all packets coming from the untrusted boundary first, it does make me uncomfortable to skew that.=20 > 2. Karen suggested a way of running IKE without any changes=20 > (again see the thread for details). In this approach DSMIPv6=20 > BUs are secured with ESP as usual. Normal traffic is sent=20 > over the DSMIPv6 port. However, secure traffic is sent over=20 > the IKE port (4500). The result of this approach is that it=20 > takes two messages to complete a handover, one from DSMIPv6=20 > (BU) and an update from IKE (for the secure traffic). The=20 > concern that I had here in the discussion with Karen was the=20 > number of messages and the delays associated for that. Of=20 > course IKE doesn't do movement detection ...etc. So my=20 > concern is the discriminatory experience of the handover for=20 > different parts of the traffic.=20 >=20 Sorry to say that I have not yet caught up on this solution fully and so, am unable to comment on it yet. From your recent email, it sounds like we have two roundtrips in the critical path, if the data is to be secured with IPsec as well. Can these roundtrips be in parallel or are they sequential? If they need to be sequential, I think that is a big enough negative impact on handoff times. If they can be parallel and can be processed out of order at the HA, I'd be less concerned with it.=20 > 3. The third class of solutions involves either modifying=20 > MIPv6 (adding new > messages) or IKE or both. I'm only including this for=20 > completeness, no one really wants this.=20 >=20 I'm not sure I understand this part. We are adding new functionality to MIP6 to support DSMIP6. And, we are adding NAT-T to MIP6 specifically for that. Given that, why is it a big deal to support a new message in MIP6 for this sake? This also makes the udpates need two messages, but, in this case, it definitely can be parallel and processed out of order and hence, there is no impact on handoff times. =20 Vidya > Please send your comments on the above. Basically the options=20 > are 1 or 2. In theory we could do both but I think it's best=20 > to pick one method for this to avoid interoperability issues=20 > and additional complexity.=20 >=20 > Hesham >=20 >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 From nemo-bounces@ietf.org Fri Oct 26 03:04:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlJE6-0004xM-Au; Fri, 26 Oct 2007 03:03:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlJE5-0004ws-5T; Fri, 26 Oct 2007 03:03:25 -0400 Received: from ws000774.tietoenator.com ([193.12.181.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlJDy-00083T-Uh; Fri, 26 Oct 2007 03:03:25 -0400 X-AuditID: c10cb581-00001af80000165c-79-472191205ff6 Received: from camaro.eu.tieto.com ([192.176.143.43]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 09:02:56 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 09:03:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Oct 2007 09:03:00 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Thread-Index: AcgXkvj8EUmQIo/vRg2DCVsK6a6TmwABPztAAAFi6NA= References: <47217E35.7010705@azairenet.com> From: To: , X-OriginalArrivalTime: 26 Oct 2007 07:03:00.0287 (UTC) FILETIME=[3E9DF4F0:01C8179E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, > > IMO, we should go with solution 2) below. I prefer that we let > > IKEv2 use its own NAT traversal mechanism. Regarding two round > > trips during a handover, note that the IKEv2 exchange to > > re-establish the IKEv2 SA and the IPsec SAs is not in the > > critical path of handover.=20 >=20 > =3D> It is in the critical path for the secure packets. That's what = the > discussion was about. >=20 > The BU/BAck messages can be exchanged > > with the existing IPsec SAs. The IKEv2 exchange can be happen a > > few seconds (or minutes) after the handover. So there is *no* > > impact on the handover. >=20 > =3D> No, see above. This is only good for insecure traffic. At=20 > least this is > not solution 2 below. >=20 Actually secure traffic from the MN towards the HA is not impacted by the delay, but it is true that secure traffic in the HA to MN direction is impacted. It will not function until the HA IPSEC SA has been upated with the correct ports and addresses and this will not happen until one of the following two things has happened: * the MN has send secure traffic towarsd the HA * the MN has initiated an IKE_SA update exchange=20 Karen > Hesham >=20 From nemo-bounces@ietf.org Fri Oct 26 03:06:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlJGz-0008Ro-SY; Fri, 26 Oct 2007 03:06:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlJGw-0007rk-2a; Fri, 26 Oct 2007 03:06:22 -0400 Received: from omta02sl.mx.bigpond.com ([144.140.93.154]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlJGY-0006an-Re; Fri, 26 Oct 2007 03:05:59 -0400 Received: from oaamta06sl.mx.bigpond.com ([124.190.106.219]) by omta02sl.mx.bigpond.com with ESMTP id <20071026070554.SBFF22254.omta02sl.mx.bigpond.com@oaamta06sl.mx.bigpond.com>; Fri, 26 Oct 2007 07:05:54 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta06sl.mx.bigpond.com with ESMTP id <20071026070554.ZEYY15362.oaamta06sl.mx.bigpond.com@PC20005>; Fri, 26 Oct 2007 07:05:54 +0000 From: "Hesham Soliman" To: "'Narayanan, Vidya'" , , Date: Fri, 26 Oct 2007 17:05:44 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-index: AcgXD2Nk409BdK32Rr+w24XNw+KidQAii1/gAAEXFRA= X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: Subject: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > 1. The Virtual link approach. In this case IKE runs over v6 > > only and is completely unaware of the IPv4 network. As a > > result IKE's NAT traversal is never invoked. Only DSMIPv6's > > NAT traversal is used. In this approach, the > > DSMIPv6 implementation in the HA is required to cache the > > outer IPv4 address and source port of the IPv4 message that > > contains IKE, then append them to the response from its own > > IKE daemon. This is basically done to hide the > > IPv4 network from IKE and effectively disable its NAT > > traversal, which solves our problem. > > Three people agreed with this approach but two people (I'm > including > > Christian) are against it. So there doesn't seem to be > > concensus on this. I believe the concern here was that the > > HA's caching of the outer address and port was complex for > > the implementation. > > > > I'm not as concerned about the complexity aspect, but, I'm more > concerned about the changes to the IPsec architecture this brings. I > think this solution requires an SPD bypass rule to be setup for the > DSMIP6 port that will first allow MIP6 to process the packets before > IPsec has a chance to apply the SPD rule for BU. It is > strange in that > the IPsec protection is somehow sought for packets from the trusted > boundary (i.e., MIP6 to IPsec in the same box) rather than > the untrusted > boundary (the packet coming in from the untrusted portion is > the one to > the DSMIP6 port and that is bypassed). One could argue that > this isn't > a big deal, but, given IPsec's design of inspecting all > packets coming > from the untrusted boundary first, it does make me > uncomfortable to skew > that. => I really don't get two things about your comment: A. The packet format is the same for both alternatives so I'm not sure if this is a general comment or specific to this alternative. It shouldn't be the latter. B. How are we bypassing anything in IPsec? I mean, there is no more bypassing here than the processing of the routing header in MIP6. Simply removing the outer IPv4 header, which can never be protected by IPsec, is not bypassing it. I don't get that. > > > 2. Karen suggested a way of running IKE without any changes > > (again see the thread for details). In this approach DSMIPv6 > > BUs are secured with ESP as usual. Normal traffic is sent > > over the DSMIPv6 port. However, secure traffic is sent over > > the IKE port (4500). The result of this approach is that it > > takes two messages to complete a handover, one from DSMIPv6 > > (BU) and an update from IKE (for the secure traffic). The > > concern that I had here in the discussion with Karen was the > > number of messages and the delays associated for that. Of > > course IKE doesn't do movement detection ...etc. So my > > concern is the discriminatory experience of the handover for > > different parts of the traffic. > > > > Sorry to say that I have not yet caught up on this solution fully and > so, am unable to comment on it yet. From your recent email, > it sounds > like we have two roundtrips in the critical path, if the > data is to be > secured with IPsec as well. Can these roundtrips be in > parallel or are > they sequential? If they need to be sequential, I think > that is a big > enough negative impact on handoff times. If they can be parallel and => They can definitely be in parallel, but I don't think IKE knows enough about movement to do this in any timely manner. So, it makes the handover of the secure traffic non-deterministic. Sorry if I gave that impression (that they have to be sent sequentially). > > 3. The third class of solutions involves either modifying > > MIPv6 (adding new > > messages) or IKE or both. I'm only including this for > > completeness, no one really wants this. > > > > I'm not sure I understand this part. We are adding new > functionality to > MIP6 to support DSMIP6. And, we are adding NAT-T to MIP6 > specifically > for that. Given that, why is it a big deal to support a new > message in > MIP6 for this sake? This also makes the udpates need two > messages, but, > in this case, it definitely can be parallel and processed > out of order > and hence, there is no impact on handoff times. => Well, we already have the two message solution, so why invent another two message case that need to be secured ...etc? Hesham > > Vidya > > > Please send your comments on the above. Basically the options > > are 1 or 2. In theory we could do both but I think it's best > > to pick one method for this to avoid interoperability issues > > and additional complexity. > > > > Hesham > > > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > From nemo-bounces@ietf.org Fri Oct 26 03:07:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlJHx-0001td-5Q; Fri, 26 Oct 2007 03:07:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlJHu-0001a7-SJ; Fri, 26 Oct 2007 03:07:22 -0400 Received: from omta02sl.mx.bigpond.com ([144.140.93.154]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlJHp-0006c4-SY; Fri, 26 Oct 2007 03:07:18 -0400 Received: from oaamta01sl.mx.bigpond.com ([124.190.106.219]) by omta02sl.mx.bigpond.com with ESMTP id <20071026070715.SCCY22254.omta02sl.mx.bigpond.com@oaamta01sl.mx.bigpond.com>; Fri, 26 Oct 2007 07:07:15 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta01sl.mx.bigpond.com with ESMTP id <20071026070715.YGBS23516.oaamta01sl.mx.bigpond.com@PC20005>; Fri, 26 Oct 2007 07:07:15 +0000 From: "Hesham Soliman" To: , Date: Fri, 26 Oct 2007 17:07:04 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-index: AcgXkvj8EUmQIo/vRg2DCVsK6a6TmwABPztAAAFi6NAAAEt3IA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > => No, see above. This is only good for insecure traffic. At > > least this is > > not solution 2 below. > > > > Actually secure traffic from the MN towards the HA is not impacted by > the delay, => Yes of course, but we normally measure the handover delay ignoring the direction of traffic. Hesham > but it is true that secure traffic in the HA to MN direction is > impacted. It will > not function until the HA IPSEC SA has been upated with the correct > ports and addresses and this will not happen until one of > the following > two things has happened: > > * the MN has send secure traffic towarsd the HA > * the MN has initiated an IKE_SA update exchange > > Karen > > > Hesham > > > From nemo-bounces@ietf.org Fri Oct 26 03:52:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlJyv-0000e1-36; Fri, 26 Oct 2007 03:51:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlJyt-0000aD-Bk; Fri, 26 Oct 2007 03:51:47 -0400 Received: from mail1.tieto.com ([194.110.47.24] helo=tietoe03.tietoenator.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlJyl-0001F9-1a; Fri, 26 Oct 2007 03:51:47 -0400 X-AuditID: c26e2f18-00001748000012a0-83-47219c5c335c Received: from camaro.eu.tieto.com ([192.176.143.43]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 10:50:52 +0300 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 09:51:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Oct 2007 09:51:10 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Thread-Index: AcgXD2Nk409BdK32Rr+w24XNw+KidQAjuLsA References: From: To: , , X-OriginalArrivalTime: 26 Oct 2007 07:51:11.0693 (UTC) FILETIME=[FA077FD0:01C817A4] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: Subject: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, With respect to the latter then I believe that we should choose one solution=20 and one solution only for interoperability reasons. I am in favor of solution 2.=20 Solution 1. breaks with the paradigm of standard MIPv6 that IKE is run on the CoA level and I think that we should keep this basic paradigm. This allow us to build the DSMIP NAT traversal mechanism with the standard NAT traversal mechanism of the protocols we are using (IPSEC and IKE) and giving NATs and the complexity of things, I think that it is very wise to build as much as possible with standard building blocks. (This also allows for future interworking with MOBIKE if ever desired) I would like to spend a few words giving some additional details of=20 the characteristics of the solutions which perhaps is not clear form the summary. Solution 1: Secure Tunneling of payload: Secure Traffic will is in this situation be send with two IP tunneling headers, the DSMIP one (which IKE and IPSec is oblivious to) and the IPSec tunnel header, that is: IPv4 header=20 UDP header=20 IPv6 header (src=3DV6HOA, dst=3DHAADDR) ESP IPv6 (src=3Dv6Hoa, dst=3DCNADDR) Payload Data the IPSEc protocol being a standard 4301 ESP tunnel. Solution 2: Secure Tunneling of payload: Secure Traffic will=20 is in this situation be=20 send with RFC 3948 IPSec tunneling, that is IPv4 header=20 UDP header=20 ESP IPv6 (src=3Dv6Hoa, dst=3DCNADDR) Payload Data Update of IKE_SA and IPSec Sas: The IPSEc transport ESP used to protect the BU/BACK exchange=20 is the same as in solution 1 and seen in isolation it survives movements.=20 But in order for it to be refreshed (and simply for it not to be torn down at some point) the IKE_SA must be updated after the movement. The IPSec RFC 3948 has the same dependency towards the IKE_SA but in addition the IPSec RFC 3948 only=20 functions when a NAT mapping has been created for UDP 4500 communication in between HA and MN, and the IPSec SA (HA side) has been updated with this information. The basic principle of solution 2 is to perform the updating on the IKE_SA and the IPSec RFC 3948 SA AFTER the BU/BACK exchange. This is a modular and robust approach, BUT it introduces delay. The IKE_SA is first updated and the IPSec tunnel will first be fully operational in both directions, when either of the followings has happened: *A secure packet from the MN has arrived and has been processed at the HA *An authenticated IKE packet from the MN carrying NAT configuration options in=20 IKE payload has arrived and has been processed at the HA. BR, Karen > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Thursday, October 25, 2007 4:01 PM > To: mip6@ietf.org; nemo@ietf.org > Subject: [Mip6] DSMIPv6 and IKE - Summary and call for concensus >=20 > Folks, >=20 > This discussion has been going on for a while and I'm sure it=20 > wasn't for > easy to follow.=20 > This email contains a summary of the discussion so far and a call for > comment/concensus. Please respond promptly because there is=20 > some pressure > from 3GPP to get this draft out very soon.=20 >=20 > The issue is how to run IKE in combination with DSMIPv6 in a private > IPv4-only network. If you want more detail about why this is a problem > please look at the thread "DSMIPv6 and IKE".=20 >=20 > There are three types of solutions that we discussed. A quick=20 > summary of > each below: >=20 > 1. The Virtual link approach. In this case IKE runs over v6=20 > only and is > completely unaware of the IPv4 network. As a result IKE's NAT=20 > traversal is > never invoked. Only DSMIPv6's NAT traversal is used. In this=20 > approach, the > DSMIPv6 implementation in the HA is required to cache the=20 > outer IPv4 address > and source port of the IPv4 message that contains IKE, then=20 > append them to > the response from its own IKE daemon. This is basically done=20 > to hide the > IPv4 network from IKE and effectively disable its NAT traversal, which > solves our problem.=20 > Three people agreed with this approach but two people (I'm including > Christian) are against it. So there doesn't seem to be=20 > concensus on this. I > believe the concern here was that the HA's caching of the=20 > outer address and > port was complex for the implementation. >=20 > 2. Karen suggested a way of running IKE without any changes=20 > (again see the > thread for details). In this approach DSMIPv6 BUs are secured=20 > with ESP as > usual. Normal traffic is sent over the DSMIPv6 port. However,=20 > secure traffic > is sent over the IKE port (4500). The result of this approach=20 > is that it > takes two messages to complete a handover, one from DSMIPv6=20 > (BU) and an > update from IKE (for the secure traffic). The concern that I=20 > had here in the > discussion with Karen was the number of messages and the=20 > delays associated > for that. Of course IKE doesn't do movement detection ...etc.=20 > So my concern > is the discriminatory experience of the handover for=20 > different parts of the > traffic.=20 >=20 > 3. The third class of solutions involves either modifying=20 > MIPv6 (adding new > messages) or IKE or both. I'm only including this for=20 > completeness, no one > really wants this.=20 >=20 > Please send your comments on the above. Basically the options=20 > are 1 or 2. In > theory we could do both but I think it's best to pick one=20 > method for this to > avoid interoperability issues and additional complexity.=20 >=20 > Hesham >=20 >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 From nemo-bounces@ietf.org Fri Oct 26 05:17:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlLJ7-0001BD-6x; Fri, 26 Oct 2007 05:16:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlLJ6-000123-4L; Fri, 26 Oct 2007 05:16:44 -0400 Received: from ws000774.tietoenator.com ([193.12.181.129]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlLJ5-00030l-Ne; Fri, 26 Oct 2007 05:16:44 -0400 X-AuditID: c10cb581-00002044000020cc-dd-4721b0754df0 Received: from stingray.eu.tieto.com ([192.176.143.13]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 11:16:37 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 11:16:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Date: Fri, 26 Oct 2007 11:16:41 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Thread-Index: AcgXD2Nk409BdK32Rr+w24XNw+KidQAii1/gAAEXFRAABHSkQA== References: From: To: , , , X-OriginalArrivalTime: 26 Oct 2007 09:16:42.0267 (UTC) FILETIME=[EC16F6B0:01C817B0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, =20 Can these roundtrips be in=20 > > parallel or are > > they sequential? If they need to be sequential, I think=20 > > that is a big > > enough negative impact on handoff times. If they can be=20 > parallel and >=20 > =3D> They can definitely be in parallel, but I don't think IKE=20 > knows enough > about movement to do this in any timely manner. So, it makes=20 > the handover of > the secure traffic non-deterministic. Sorry if I gave that=20 > impression (that > they have to be sent sequentially).=20 >=20 With the IKEv2 RFC in hand, and only the RFC - NOT individual implementations, then with minimal interpretation of section 2.23 of RFC 4306, the update cannot be done in parallel, the HA MUST process the BU and make some changes in the IKE_SA and the IPSEC tunnel SAS before a single IKE exchange can update the IKE_SAs and the RFC 3948 IPSec SAs appropriately. If we are speaking of a full new IKE_SA establishment and a new IPsec tunnel SA creation (means 2 extra RTTs) then this can be done in parallel. With MOBIKE, the update can be done in parallel and would only detail one exchange. BR, Karen From EvFekerl@kmzavod.ru Fri Oct 26 06:13:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlMCC-0003KH-B4 for nemo-archive@lists.ietf.org; Fri, 26 Oct 2007 06:13:40 -0400 Received: from [85.104.58.255] (helo=dsl85-104-15103.ttnet.net.tr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlMCA-0006UQ-PB for nemo-archive@lists.ietf.org; Fri, 26 Oct 2007 06:13:40 -0400 Received: from ali ([193.176.117.13]:29139 "EHLO ali" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by dsl85-104-15103.ttnet.net.tr with ESMTP id S22QJHVZHFJPGVPX (ORCPT ); Fri, 26 Oct 2007 13:13:45 +0300 Message-ID: <000c01c817b8$d5876260$ff3a6855@ali> From: "Ev Fekerl" To: Subject: daijinpa Date: Fri, 26 Oct 2007 13:13:20 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C817D1.FAD49A60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.6 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0006_01C817D1.FAD49A60 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable hello babe nemo-archive get her dripping wet when she sees your enlarged cock http://rushcurd.com/ Ev Fekerl ------=_NextPart_000_0006_01C817D1.FAD49A60 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable
hello babe nemo-archive
get her dripping wet when she sees your = enlarged=20 cock
http://rushcurd.com/
Ev Fekerl
------=_NextPart_000_0006_01C817D1.FAD49A60-- From nemo-bounces@ietf.org Fri Oct 26 06:52:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlMld-0000Wv-Cl; Fri, 26 Oct 2007 06:50:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlMla-0000VB-4f; Fri, 26 Oct 2007 06:50:15 -0400 Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlMlP-0007uw-Px; Fri, 26 Oct 2007 06:50:10 -0400 Received: from oaamta08sl.mx.bigpond.com ([124.190.106.219]) by omta04sl.mx.bigpond.com with ESMTP id <20071026104920.DBXY1805.omta04sl.mx.bigpond.com@oaamta08sl.mx.bigpond.com>; Fri, 26 Oct 2007 10:49:20 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta08sl.mx.bigpond.com with ESMTP id <20071026104916.XOF10966.oaamta08sl.mx.bigpond.com@PC20005>; Fri, 26 Oct 2007 10:49:16 +0000 From: "Hesham Soliman" To: , , , Subject: RE: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Date: Fri, 26 Oct 2007 20:49:06 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-index: AcgXD2Nk409BdK32Rr+w24XNw+KidQAii1/gAAEXFRAABHSkQAADfJpg X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Thanks Karen for the clarification. So, we have two cases here: 1. Standard IKEv2 = Sequential updates 2. Mobike = parallel updates. Hesham > -----Original Message----- > From: Karen.Nielsen@tietoenator.com > [mailto:Karen.Nielsen@tietoenator.com] > Sent: Friday, October 26, 2007 7:17 PM > To: Hesham@elevatemobile.com; vidyan@qualcomm.com; > mip6@ietf.org; nemo@ietf.org > Subject: RE: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and > call for concensus > > Hi, > > Can these roundtrips be in > > > parallel or are > > > they sequential? If they need to be sequential, I think > > > that is a big > > > enough negative impact on handoff times. If they can be > > parallel and > > > > => They can definitely be in parallel, but I don't think IKE > > knows enough > > about movement to do this in any timely manner. So, it makes > > the handover of > > the secure traffic non-deterministic. Sorry if I gave that > > impression (that > > they have to be sent sequentially). > > > > With the IKEv2 RFC in hand, and only the RFC - NOT individual > implementations, > then with minimal interpretation of section 2.23 of RFC > 4306, the update > cannot be done in parallel, the HA MUST process the BU and make some > changes in the IKE_SA and the IPSEC tunnel SAS before a single IKE > exchange can update the IKE_SAs and the RFC 3948 IPSec SAs > appropriately. > > If we are speaking of a full new IKE_SA establishment and a new IPsec > tunnel SA > creation (means 2 extra RTTs) then this can be done in parallel. > > With MOBIKE, the update can be done in parallel and would only detail > one > exchange. > > BR, Karen > From desarrollo@lsh-ag.de Fri Oct 26 18:36:08 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlXmi-0003kC-Pk for nemo-archive@lists.ietf.org; Fri, 26 Oct 2007 18:36:08 -0400 Received: from [190.40.49.144] (helo=client-190.40.49.144.speedy.net.pe) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IlXma-0007VR-CX for nemo-archive@lists.ietf.org; Fri, 26 Oct 2007 18:36:06 -0400 Received: (qmail 11439 invoked from network); Sat, 27 Oct 2007 05:51:58 +0200 Received: from unknown (HELO avka) (141.203.33.92) by client-190.40.49.144.speedy.net.pe with SMTP; Sat, 27 Oct 2007 05:51:58 +0200 Message-ID: <4722B5DE.4020006@lsh-ag.de> Date: Sat, 27 Oct 2007 05:51:58 +0200 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: This is hilarious! Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.0 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 This Psycho Cat Card has been sent to you. http://66.69.209.116/ From Zuo.Schulmeister@matrics.com Sat Oct 27 10:30:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlmgD-0003KF-F8 for nemo-archive@lists.ietf.org; Sat, 27 Oct 2007 10:30:25 -0400 Received: from [189.24.100.50] (helo=18924100050.user.veloxzone.com.br) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlmgB-0006kL-GR for nemo-archive@lists.ietf.org; Sat, 27 Oct 2007 10:30:25 -0400 Received: from comp1 ([163.146.46.39] helo=comp1) by 18924100050.user.veloxzone.com.br ( sendmail 8.13.3/8.13.1) with esmtpa id 1lgYxU-000DZX-px for nemo-archive@lists.ietf.org; Sat, 27 Oct 2007 12:30:44 -0200 Message-ID: <000301c818a5$ebc3d750$326418bd@comp1> From: "Zuo Schulmeister" To: Subject: RE: Date: Sat, 27 Oct 2007 12:30:28 -0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea In cold severe winters when it’s so nice to stay inside, order Viagra online at Canadian Health&Care Mall. http://amopriatem.info/ From presten_Rosenberg@capristore.com Mon Oct 29 15:13:16 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ima32-0001LY-FV for nemo-archive@lists.ietf.org; Mon, 29 Oct 2007 15:13:16 -0400 Received: from [88.233.135.62] (helo=dsl88-233-34622.ttnet.net.tr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ima0H-0000ZK-4L for nemo-archive@lists.ietf.org; Mon, 29 Oct 2007 15:13:08 -0400 Received: from YUCEL ([147.119.102.124] helo=YUCEL) by dsl88-233-34622.ttnet.net.tr ( sendmail 8.13.3/8.13.1) with esmtpa id 1qdQoe-000HCD-Ud for nemo-archive@lists.ietf.org; Mon, 29 Oct 2007 21:10:54 +0200 Message-ID: <000801c81a5f$56570d20$3e87e958@YUCEL> From: "presten Rosenberg" To: Subject: esubat Date: Mon, 29 Oct 2007 21:10:15 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C81A70.19DFDD20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.6 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0004_01C81A70.19DFDD20 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable hi daddy nemo-archive it aint fun if you cant fuck her with your little dick http://www.ulsterak.com/ presten Rosenberg ------=_NextPart_000_0004_01C81A70.19DFDD20 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable
hi daddy nemo-archive
it aint fun if you cant fuck her with your = little=20 dick
http://www.ulsterak.com/
presten Rosenberg
------=_NextPart_000_0004_01C81A70.19DFDD20-- From nemo-bounces@ietf.org Mon Oct 29 20:35:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imf3A-0006dB-M8; Mon, 29 Oct 2007 20:33:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imf2t-0003rb-Bd; Mon, 29 Oct 2007 20:33:27 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imf2i-0003G7-4b; Mon, 29 Oct 2007 20:33:16 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 17:33:11 -0700 Message-ID: <47267BC6.2090302@azairenet.com> Date: Mon, 29 Oct 2007 17:33:10 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman , Karen.Nielsen@tietoenator.com, Christian.Kaas-Petersen@tietoenator.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2007 00:33:11.0281 (UTC) FILETIME=[7355DE10:01C81A8C] X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Thanks Hesham. I think I mixed up solution 2 described below in your email with solution 2 described in an email you sent on the 17th of October. http://www1.ietf.org/mail-archive/web/mip6/current/msg06856.html I do want to avoid two round trips during every handover. I also want to avoid running MOBIKE at the same time as MIPv6. Does not make sense. Having said, I would like to figure out whats wrong with running IKEv2 on port 4500, but sending the BU on DS-MIPv6 port with a transport mode SA. Lets say IKEv2 runs on UDP port 4500 always and negotiates a transport mode SA for protecting the BU. When the BU packet goes through the SPD entries, the transport mode SA is picked. After IPsec processing the packet will be as follows IPv6 hdr (src=V6HOA, dst=HAADDR) ESP Hdr BU IPv4 CoA option With DS-MIPv6 encapsulation the packet becomes IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) IPv6 hdr (src=V6HOA, dst=HAADDR) ESP Hdr BU IPv4 CoA option Now lets assume the mobile node moves and attaches to another IPv4 access network. The transport mode IPsec SA is still valid. IKEv2 does not know that the mobile node moved, its IPv4 address changed or if there is a new NAT in the path. So the mobile node can send a BU right away as follows. IPv4 hdr (src=new_V4ADDR, dst=HA_V4ADDR) UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) IPv6 hdr (src=V6HOA, dst=HAADDR) ESP Hdr BU IPv4 CoA option (new IPv4 CoA) When the HA receives the BU, the packet will appear like the following IPv4 hdr (src=NATTED_new_V4ADDR, dst=HA_V4ADDR) UDP hdr (srcport=NATTED_DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) IPv6 hdr (src=V6HOA, dst=HAADDR) ESP Hdr BU IPv4 CoA option (new IPv4 CoA) The HA would process the BU and respond to the NATTED_DS-MIPv6-PORT. Meanwhile the MIPv6 stack on the mobile node will trigger the IKEv2 daemon on the mobile node to re-run IKEv2. This is because the original IKEv2 SA is not valid anymore. When the IKEv2 SAs are re-negotiated, new IPsec SAs are also setup. This would allow the IKEv2 exchange to happen out of the critical path. There is no update to the IKEv2 SA based on the BU/BAck exchange. There are no tunnel mode SAs created for any MIPv6 signaling messages. What am I missing now? Vijay Hesham Soliman wrote: > > IMO, we should go with solution 2) below. I prefer that we let > > IKEv2 use its own NAT traversal mechanism. Regarding two round > > trips during a handover, note that the IKEv2 exchange to > > re-establish the IKEv2 SA and the IPsec SAs is not in the > > critical path of handover. > > => It is in the critical path for the secure packets. That's what the > discussion was about. > > The BU/BAck messages can be exchanged > > with the existing IPsec SAs. The IKEv2 exchange can be happen a > > few seconds (or minutes) after the handover. So there is *no* > > impact on the handover. > > => No, see above. This is only good for insecure traffic. At least this is > not solution 2 below. > > Hesham > > > > > This would be the same as the lack of support for the "K" flag > > in RFC 3775. In RFC 3775, if either the mobile node or the home > > agent are not capable of updating the IKE SA based on the > > exchange of BU/BAck, there is always an IKE exchange after the > > handover (or whenever the CoA changes). > > > > Please let me know if I am missing something related to the > > impact of the IKEv2 exchange on the handover. > > > > I am not comfortable with the temporary tunnel created in > > solution 1). > > > > Vijay > > > > Hesham Soliman wrote: > > > Folks, > > > > > > This discussion has been going on for a while and I'm sure > > it wasn't for > > > easy to follow. > > > This email contains a summary of the discussion so far and > > a call for > > > comment/concensus. Please respond promptly because there > > is some pressure > > > from 3GPP to get this draft out very soon. > > > > > > The issue is how to run IKE in combination with DSMIPv6 in > > a private > > > IPv4-only network. If you want more detail about why this > > is a problem > > > please look at the thread "DSMIPv6 and IKE". > > > > > > There are three types of solutions that we discussed. A > > quick summary of > > > each below: > > > > > > 1. The Virtual link approach. In this case IKE runs over > > v6 only and is > > > completely unaware of the IPv4 network. As a result IKE's > > NAT traversal is > > > never invoked. Only DSMIPv6's NAT traversal is used. In > > this approach, the > > > DSMIPv6 implementation in the HA is required to cache the > > outer IPv4 address > > > and source port of the IPv4 message that contains IKE, > > then append them to > > > the response from its own IKE daemon. This is basically > > done to hide the > > > IPv4 network from IKE and effectively disable its NAT > > traversal, which > > > solves our problem. > > > Three people agreed with this approach but two people (I'm > > including > > > Christian) are against it. So there doesn't seem to be > > concensus on this. I > > > believe the concern here was that the HA's caching of the > > outer address and > > > port was complex for the implementation. > > > > > > 2. Karen suggested a way of running IKE without any > > changes (again see the > > > thread for details). In this approach DSMIPv6 BUs are > > secured with ESP as > > > usual. Normal traffic is sent over the DSMIPv6 port. > > However, secure traffic > > > is sent over the IKE port (4500). The result of this > > approach is that it > > > takes two messages to complete a handover, one from > > DSMIPv6 (BU) and an > > > update from IKE (for the secure traffic). The concern that > > I had here in the > > > discussion with Karen was the number of messages and the > > delays associated > > > for that. Of course IKE doesn't do movement detection > > ...etc. So my concern > > > is the discriminatory experience of the handover for > > different parts of the > > > traffic. > > > > > > 3. The third class of solutions involves either modifying > > MIPv6 (adding new > > > messages) or IKE or both. I'm only including this for > > completeness, no one > > > really wants this. > > > > > > Please send your comments on the above. Basically the > > options are 1 or 2. In > > > theory we could do both but I think it's best to pick one > > method for this to > > > avoid interoperability issues and additional complexity. > > > > > > Hesham > > > > > > > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > From nemo-bounces@ietf.org Mon Oct 29 20:35:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imf3d-000206-C8; Mon, 29 Oct 2007 20:34:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imf3b-0001tu-Bv; Mon, 29 Oct 2007 20:34:11 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imf3a-0003KB-Vb; Mon, 29 Oct 2007 20:34:11 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 17:34:09 -0700 Message-ID: <47267C01.90809@azairenet.com> Date: Mon, 29 Oct 2007 17:34:09 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Karen.Nielsen@tietoenator.com References: <47217E35.7010705@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2007 00:34:09.0812 (UTC) FILETIME=[9638FD40:01C81A8C] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Karen.Nielsen@tietoenator.com wrote: > Hi, > >> > IMO, we should go with solution 2) below. I prefer that we let >> > IKEv2 use its own NAT traversal mechanism. Regarding two round >> > trips during a handover, note that the IKEv2 exchange to >> > re-establish the IKEv2 SA and the IPsec SAs is not in the >> > critical path of handover. >> >> => It is in the critical path for the secure packets. That's what the >> discussion was about. >> >> The BU/BAck messages can be exchanged >> > with the existing IPsec SAs. The IKEv2 exchange can be happen a >> > few seconds (or minutes) after the handover. So there is *no* >> > impact on the handover. >> >> => No, see above. This is only good for insecure traffic. At >> least this is >> not solution 2 below. >> > > Actually secure traffic from the MN towards the HA is not impacted by > the delay, > but it is true that secure traffic in the HA to MN direction is > impacted. It will > not function until the HA IPSEC SA has been upated with the correct > ports and addresses But why? I thought this was a transport mode SA keyed on the IPv6 home address of the mobile node. Vijay and this will not happen until one of the following > two things has happened: > > * the MN has send secure traffic towarsd the HA > * the MN has initiated an IKE_SA update exchange > > Karen > >> Hesham >> From nemo-bounces@ietf.org Mon Oct 29 20:38:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imf7c-0004va-02; Mon, 29 Oct 2007 20:38:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imf7a-0004vB-7j; Mon, 29 Oct 2007 20:38:18 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imf7Z-0003ZE-R9; Mon, 29 Oct 2007 20:38:18 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 17:38:01 -0700 Message-ID: <47267CE9.30306@azairenet.com> Date: Mon, 29 Oct 2007 17:38:01 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Karen.Nielsen@tietoenator.com Subject: Re: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2007 00:38:01.0187 (UTC) FILETIME=[20220330:01C81A8D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Karen, I am not sure if you are talking about a transport mode SA or tunnel mode SA to protect the BU. You have used both in your emails. Vijay Karen.Nielsen@tietoenator.com wrote: > Hi, > > Can these roundtrips be in > > > parallel or are > > > they sequential? If they need to be sequential, I think > > > that is a big > > > enough negative impact on handoff times. If they can be > > parallel and > > > > => They can definitely be in parallel, but I don't think IKE > > knows enough > > about movement to do this in any timely manner. So, it makes > > the handover of > > the secure traffic non-deterministic. Sorry if I gave that > > impression (that > > they have to be sent sequentially). > > > > With the IKEv2 RFC in hand, and only the RFC - NOT individual > implementations, > then with minimal interpretation of section 2.23 of RFC 4306, the update > cannot be done in parallel, the HA MUST process the BU and make some > changes in the IKE_SA and the IPSEC tunnel SAS before a single IKE > exchange can update the IKE_SAs and the RFC 3948 IPSec SAs > appropriately. > > If we are speaking of a full new IKE_SA establishment and a new IPsec > tunnel SA > creation (means 2 extra RTTs) then this can be done in parallel. > > With MOBIKE, the update can be done in parallel and would only detail > one > exchange. > > BR, Karen > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > From Haspect@elizabethfrench.com Mon Oct 29 21:27:45 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImftR-0001hz-MT for nemo-archive@lists.ietf.org; Mon, 29 Oct 2007 21:27:45 -0400 Received: from 20150161242.user.veloxzone.com.br ([201.50.161.242]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imft9-0005Sc-Q6 for nemo-archive@lists.ietf.org; Mon, 29 Oct 2007 21:27:37 -0400 Received: from intel ([166.107.114.109] helo=intel) by 20150167073.user.veloxzone.com.br ( sendmail 8.13.3/8.13.1) with esmtpa id 1CWLwU-000HFF-eK for nemo-archive@lists.ietf.org; Mon, 29 Oct 2007 22:27:55 -0300 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 29 Oct 2007 22:27:18 -0300 To: nemo-archive@lists.ietf.org From: "Holden Haspect" Subject: eirwolf Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.4 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Nice to meet you nemo-archive unless you have a big penis, the ladies will go elsewhere http://www.tempromx.com/ Holden Haspect From nemo-bounces@ietf.org Tue Oct 30 03:29:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImlWQ-0005ah-Bt; Tue, 30 Oct 2007 03:28:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImlWO-0005aW-Js; Tue, 30 Oct 2007 03:28:20 -0400 Received: from ws000774.tietoenator.com ([193.12.181.129]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImlWO-0007tb-06; Tue, 30 Oct 2007 03:28:20 -0400 X-AuditID: c10cb581-0000256c00001ed8-d7-4726dcf3317c Received: from stingray.eu.tieto.com ([192.176.143.13]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 08:27:47 +0100 Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 08:27:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Date: Tue, 30 Oct 2007 08:27:46 +0100 Message-ID: In-Reply-To: <47267CE9.30306@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Thread-Index: AcgajYYywFpmOUMiRbSBJ6Mhy+A6bgAOL5Mg References: <47267CE9.30306@azairenet.com> From: To: X-OriginalArrivalTime: 30 Oct 2007 07:27:47.0165 (UTC) FILETIME=[5E8488D0:01C81AC6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Vijay, I am talking transport ESP to protect BU/BACK. Tunnel mode ESP to protect payload. Karen=20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 > Sent: Tuesday, October 30, 2007 1:38 AM > To: Nielsen Karen E > Cc: nemo@ietf.org; mip6@ietf.org > Subject: Re: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and=20 > call for concensus >=20 > Karen, >=20 > I am not sure if you are talking about a transport mode SA or tunnel > mode SA to protect the BU. You have used both in your emails. >=20 > Vijay >=20 > Karen.Nielsen@tietoenator.com wrote: > > Hi, > >=20 > > Can these roundtrips be in > > > > parallel or are > > > > they sequential? If they need to be sequential, I think > > > > that is a big > > > > enough negative impact on handoff times. If they can be > > > parallel and > > > > > > =3D> They can definitely be in parallel, but I don't think IKE > > > knows enough > > > about movement to do this in any timely manner. So, it makes > > > the handover of > > > the secure traffic non-deterministic. Sorry if I gave that > > > impression (that > > > they have to be sent sequentially). > > > > >=20 > > With the IKEv2 RFC in hand, and only the RFC - NOT individual > > implementations, > > then with minimal interpretation of section 2.23 of RFC=20 > 4306, the update > > cannot be done in parallel, the HA MUST process the BU and make some > > changes in the IKE_SA and the IPSEC tunnel SAS before a single IKE > > exchange can update the IKE_SAs and the RFC 3948 IPSec SAs > > appropriately. > >=20 > > If we are speaking of a full new IKE_SA establishment and a=20 > new IPsec > > tunnel SA > > creation (means 2 extra RTTs) then this can be done in parallel. > >=20 > > With MOBIKE, the update can be done in parallel and would=20 > only detail > > one > > exchange. > >=20 > > BR, Karen > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 From nemo-bounces@ietf.org Tue Oct 30 03:41:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imlj0-0007Ss-At; Tue, 30 Oct 2007 03:41:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imliz-0007Sk-Mh; Tue, 30 Oct 2007 03:41:21 -0400 Received: from ws000774.tietoenator.com ([193.12.181.129]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imliz-0008GW-9x; Tue, 30 Oct 2007 03:41:21 -0400 X-AuditID: c10cb581-000002a000001ed8-7e-4726e0202e3d Received: from camaro.eu.tieto.com ([192.176.143.43]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 08:41:20 +0100 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 08:41:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Oct 2007 08:41:19 +0100 Message-ID: In-Reply-To: <47267C01.90809@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Thread-Index: AcgajYbLsCYvqe8ITzSfXYilKl3gkgAOgBeQ References: <47217E35.7010705@azairenet.com> <47267C01.90809@azairenet.com> From: To: X-OriginalArrivalTime: 30 Oct 2007 07:41:19.0806 (UTC) FILETIME=[42E3B5E0:01C81AC8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Vijay,=20 > >> > >=20 > > Actually secure traffic from the MN towards the HA is not=20 > impacted by > > the delay, > > but it is true that secure traffic in the HA to MN direction is > > impacted. It will > > not function until the HA IPSEC SA has been upated with the correct > > ports and addresses=20 >=20 > But why? I thought this was a transport mode SA keyed on the IPv6 home > address of the mobile node. >=20 Yes, the transport mode SA's are, but the tunnel mode SAs for payload protection are not in the scenario I am considering. The delay I am speaking about is related uniquely to the transport mode SAs (as well as of course to rekeying and such of the transport mode SAs, whenever that is needed.) I, myself, is not very concerned with delay associated with tunnel mode IPSec protection from HA to MN. Especially given that Route Optimization is not relevant for DSMIP. Read, the only case, I am aware off, where tunnel mode protection is required by the MIP standard (MUST). Yes there are multicast and other things, but is it really crucial if we have a delay there (?). Karen > Vijay >=20 >=20 >=20 From nemo-bounces@ietf.org Tue Oct 30 03:56:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imlxf-0003Nd-1O; Tue, 30 Oct 2007 03:56:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imlxd-0003MZ-KC; Tue, 30 Oct 2007 03:56:29 -0400 Received: from mail1.tieto.com ([194.110.47.24] helo=tietoe03.tietoenator.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imlxd-0000Tf-2i; Tue, 30 Oct 2007 03:56:29 -0400 X-AuditID: c26e2f18-0000227c000016e0-48-4726e398572c Received: from camaro.eu.tieto.com ([192.176.143.43]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 09:56:08 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 08:56:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Oct 2007 08:56:22 +0100 Message-ID: In-Reply-To: <47267BC6.2090302@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Thread-Index: AcgajHv/RCFXZNDlRiiS1EJ/c/oezgAPbcKQ References: <47267BC6.2090302@azairenet.com> From: To: , , X-OriginalArrivalTime: 30 Oct 2007 07:56:26.0945 (UTC) FILETIME=[5F962310:01C81ACA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org =20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 > Sent: Tuesday, October 30, 2007 1:33 AM > To: Hesham Soliman; Nielsen Karen E; Kaas-Petersen Christian > Cc: mip6@ietf.org; nemo@ietf.org > Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus >=20 > Thanks Hesham. >=20 > I think I mixed up solution 2 described below in your email with > solution 2 described in an email you sent on the 17th of October. > http://www1.ietf.org/mail-archive/web/mip6/current/msg06856.html >=20 > I do want to avoid two round trips during every handover. I also want > to avoid running MOBIKE at the same time as MIPv6. Does not=20 > make sense. >=20 > Having said, I would like to figure out whats wrong with running IKEv2 > on port 4500, but sending the BU on DS-MIPv6 port with a=20 > transport mode > SA. >=20 > Lets say IKEv2 runs on UDP port 4500 always and negotiates a transport > mode SA for protecting the BU. >=20 > When the BU packet goes through the SPD entries, the transport mode SA > is picked. After IPsec processing the packet will be as follows >=20 > IPv6 hdr (src=3DV6HOA, dst=3DHAADDR) > ESP Hdr > BU > IPv4 CoA option >=20 > With DS-MIPv6 encapsulation the packet becomes >=20 > IPv4 hdr (src=3DV4ADDR, dst=3DHA_V4ADDR) > UDP hdr (srcport=3DDS-MIPv6-PORT, dstport=3DDS-MIPv6-PORT) > IPv6 hdr (src=3DV6HOA, dst=3DHAADDR) > ESP Hdr > BU > IPv4 CoA option >=20 > Now lets assume the mobile node moves and attaches to another IPv4 > access network. The transport mode IPsec SA is still valid. IKEv2 > does not know that the mobile node moved, its IPv4 address changed > or if there is a new NAT in the path. So the mobile node can send > a BU right away as follows. >=20 > IPv4 hdr (src=3Dnew_V4ADDR, dst=3DHA_V4ADDR) > UDP hdr (srcport=3DDS-MIPv6-PORT, dstport=3DDS-MIPv6-PORT) > IPv6 hdr (src=3DV6HOA, dst=3DHAADDR) > ESP Hdr > BU > IPv4 CoA option (new IPv4 CoA) >=20 > When the HA receives the BU, the packet will appear like the following >=20 > IPv4 hdr (src=3DNATTED_new_V4ADDR, dst=3DHA_V4ADDR) > UDP hdr (srcport=3DNATTED_DS-MIPv6-PORT, dstport=3DDS-MIPv6-PORT) > IPv6 hdr (src=3DV6HOA, dst=3DHAADDR) > ESP Hdr > BU > IPv4 CoA option (new IPv4 CoA) >=20 > The HA would process the BU and respond to the NATTED_DS-MIPv6-PORT. >=20 > Meanwhile the MIPv6 stack on the mobile node will trigger the IKEv2 > daemon on the mobile node to re-run IKEv2. This is because=20 > the original > IKEv2 SA is not valid anymore. When the IKEv2 SAs are=20 > re-negotiated, new > IPsec SAs are also setup. >=20 > This would allow the IKEv2 exchange to happen out of the=20 > critical path. > There is no update to the IKEv2 SA based on the BU/BAck=20 > exchange. There > are no tunnel mode SAs created for any MIPv6 signaling messages. What > am I missing now? >=20 Delay associated with tunnel SAs for payload protection. Karen > Vijay >=20 From mext-bounces@ietf.org Tue Oct 30 06:04:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imnsq-0003Eu-MM; Tue, 30 Oct 2007 05:59:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imnso-0003Ek-PZ for mext@ietf.org; Tue, 30 Oct 2007 05:59:38 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imnso-0004sW-8o for mext@ietf.org; Tue, 30 Oct 2007 05:59:38 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 10:59:36 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] AD review of draft-korhonen-mip6-service-03.txt Date: Tue, 30 Oct 2007 10:59:35 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9261@SEHAN021MB.tcad.telia.se> In-Reply-To: <471C3B28.7020107@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] AD review of draft-korhonen-mip6-service-03.txt Thread-Index: AcgUkdGD2EnIIVvDQumEffqsWfuUYAGSKLlg References: <4700A05C.3070905@piuha.net> <471C3B28.7020107@piuha.net> From: To: X-OriginalArrivalTime: 30 Oct 2007 09:59:36.0504 (UTC) FILETIME=[941B5B80:01C81ADB] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: draft-korhonen-mip6-service@tools.ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org There was comment I received offline pointing out that description of the service selection option identifier in -04 does not mention DNS anymore. In -03 it read "The Identifier MAY be resolveable by DNS." I think it could be put back. The new text could be: " o Type: 8-bit identifier set to TBD (to be defined by IANA) of the type of the skipable mobility option. Depending on the system deployment the Identifier MAY be resolveable by DNS." Any thoughts?=20 Cheers, Jouni > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Monday, October 22, 2007 8:55 AM > To: Korhonen, Jouni /TeliaSonera Finland Oyj > Cc: draft-korhonen-mip6-service@tools.ietf.org; mext@ietf.org > Subject: Re: [MEXT] AD review of draft-korhonen-mip6-service-03.txt >=20 >=20 > The new version addresses the concerns I had. Thanks. The=20 > document will now be moved forward. >=20 > Jari >=20 >=20 >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Oct 30 10:32:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ims4w-0002xV-NY; Tue, 30 Oct 2007 10:28:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ims4v-0002xC-0R for mext@ietf.org; Tue, 30 Oct 2007 10:28:25 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ims4u-0005Gi-Fn for mext@ietf.org; Tue, 30 Oct 2007 10:28:24 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5C390198677; Tue, 30 Oct 2007 16:28:23 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D1652198670; Tue, 30 Oct 2007 16:28:22 +0200 (EET) Message-ID: <47273F85.9000505@piuha.net> Date: Tue, 30 Oct 2007 16:28:21 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com Subject: Re: [MEXT] AD review of draft-korhonen-mip6-service-03.txt References: <4700A05C.3070905@piuha.net> <471C3B28.7020107@piuha.net> <59D7431DE2527D4CB0F1EFEDA5683ED3024F9261@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9261@SEHAN021MB.tcad.telia.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org I'm wary of specifying something might be found in DNS or might not. Also, do we have any evidence that we actually need the identifiers to be resolved by DNS? In any case, no one would turn on service for a particular domain without an agreement in place with that domain. So the box initiating a VPN tunnel simply has to have configuration for that domain, its not enough for the DNS query to succeed. Jari jouni.korhonen@teliasonera.com kirjoitti: > There was comment I received offline pointing out that description > of the service selection option identifier in -04 does not mention > DNS anymore. In -03 it read > "The Identifier MAY be resolveable by DNS." > I think it could be put back. The new text could be: > > " o Type: 8-bit identifier set to TBD (to be defined by IANA) of the > type of the skipable mobility option. Depending on the system > deployment the Identifier MAY be resolveable by DNS." > > Any thoughts? > > > > Cheers, > Jouni > > >> -----Original Message----- >> From: Jari Arkko [mailto:jari.arkko@piuha.net] >> Sent: Monday, October 22, 2007 8:55 AM >> To: Korhonen, Jouni /TeliaSonera Finland Oyj >> Cc: draft-korhonen-mip6-service@tools.ietf.org; mext@ietf.org >> Subject: Re: [MEXT] AD review of draft-korhonen-mip6-service-03.txt >> >> >> The new version addresses the concerns I had. Thanks. The >> document will now be moved forward. >> >> Jari >> >> >> >> > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From nemo-bounces@ietf.org Tue Oct 30 11:16:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imso3-0000rI-W4; Tue, 30 Oct 2007 11:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imso2-0000q2-9y; Tue, 30 Oct 2007 11:15:02 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imsnw-0007vX-3b; Tue, 30 Oct 2007 11:15:02 -0400 Received: from [127.0.0.1] ([67.180.82.252]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 08:14:46 -0700 Message-ID: <47274A5D.8010505@azairenet.com> Date: Tue, 30 Oct 2007 08:14:37 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Karen.Nielsen@tietoenator.com References: <47267BC6.2090302@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2007 15:14:47.0067 (UTC) FILETIME=[9BAE46B0:01C81B07] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, nemo@ietf.org Subject: [nemo] Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Karen.Nielsen@tietoenator.com wrote: > > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >> Sent: Tuesday, October 30, 2007 1:33 AM >> To: Hesham Soliman; Nielsen Karen E; Kaas-Petersen Christian >> Cc: mip6@ietf.org; nemo@ietf.org >> Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus >> >> Thanks Hesham. >> >> I think I mixed up solution 2 described below in your email with >> solution 2 described in an email you sent on the 17th of October. >> http://www1.ietf.org/mail-archive/web/mip6/current/msg06856.html >> >> I do want to avoid two round trips during every handover. I also want >> to avoid running MOBIKE at the same time as MIPv6. Does not >> make sense. >> >> Having said, I would like to figure out whats wrong with running IKEv2 >> on port 4500, but sending the BU on DS-MIPv6 port with a >> transport mode >> SA. >> >> Lets say IKEv2 runs on UDP port 4500 always and negotiates a transport >> mode SA for protecting the BU. >> >> When the BU packet goes through the SPD entries, the transport mode SA >> is picked. After IPsec processing the packet will be as follows >> >> IPv6 hdr (src=V6HOA, dst=HAADDR) >> ESP Hdr >> BU >> IPv4 CoA option >> >> With DS-MIPv6 encapsulation the packet becomes >> >> IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) >> UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) >> IPv6 hdr (src=V6HOA, dst=HAADDR) >> ESP Hdr >> BU >> IPv4 CoA option >> >> Now lets assume the mobile node moves and attaches to another IPv4 >> access network. The transport mode IPsec SA is still valid. IKEv2 >> does not know that the mobile node moved, its IPv4 address changed >> or if there is a new NAT in the path. So the mobile node can send >> a BU right away as follows. >> >> IPv4 hdr (src=new_V4ADDR, dst=HA_V4ADDR) >> UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) >> IPv6 hdr (src=V6HOA, dst=HAADDR) >> ESP Hdr >> BU >> IPv4 CoA option (new IPv4 CoA) >> >> When the HA receives the BU, the packet will appear like the following >> >> IPv4 hdr (src=NATTED_new_V4ADDR, dst=HA_V4ADDR) >> UDP hdr (srcport=NATTED_DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) >> IPv6 hdr (src=V6HOA, dst=HAADDR) >> ESP Hdr >> BU >> IPv4 CoA option (new IPv4 CoA) >> >> The HA would process the BU and respond to the NATTED_DS-MIPv6-PORT. >> >> Meanwhile the MIPv6 stack on the mobile node will trigger the IKEv2 >> daemon on the mobile node to re-run IKEv2. This is because >> the original >> IKEv2 SA is not valid anymore. When the IKEv2 SAs are >> re-negotiated, new >> IPsec SAs are also setup. >> >> This would allow the IKEv2 exchange to happen out of the >> critical path. >> There is no update to the IKEv2 SA based on the BU/BAck >> exchange. There >> are no tunnel mode SAs created for any MIPv6 signaling messages. What >> am I missing now? >> > > Delay associated with tunnel SAs for payload protection. Can we then first conclude that we don't have an issue for completing the BU/BAck exchange? IPsec ESP protection in tunnel mode for payload packets is optional after all. Vijay From Jessy700@artindustria.net Tue Oct 30 11:19:01 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imsrt-0006TN-9d for nemo-archive@lists.ietf.org; Tue, 30 Oct 2007 11:19:01 -0400 Received: from [151.53.139.139] (helo=[151.53.139.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imsrq-00083k-Ot for nemo-archive@lists.ietf.org; Tue, 30 Oct 2007 11:19:01 -0400 Received: by 10.170.49.35 with SMTP id MdNeKctRjUSYk; Tue, 30 Oct 2007 16:18:55 +0100 (GMT) Received: by 192.168.129.128 with SMTP id UepARoMPqdgBzG.9980986879030; Tue, 30 Oct 2007 16:18:53 +0100 (GMT) Message-ID: <000c01c81b08$2ce877e0$8b8b3597@utente8946517c> From: "Jessy Kaiser" To: Subject: ereitnok Date: Tue, 30 Oct 2007 16:18:50 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C81B10.8EACDFE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.6 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0003_01C81B10.8EACDFE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello pal nemo-archive dont let your tiny cock rule your like, make it bigger! http://bbrerto.com/ Jessy Kaiser ------=_NextPart_000_0003_01C81B10.8EACDFE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hello pal nemo-archive
dont let your tiny cock rule your like, make = it=20 bigger!
http://bbrerto.com/
Jessy Kaiser
------=_NextPart_000_0003_01C81B10.8EACDFE0-- From rajendra5ettore86@clixtrix.com Tue Oct 30 15:59:18 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImxF7-0002t4-Vx for nemo-archive@lists.ietf.org; Tue, 30 Oct 2007 15:59:18 -0400 Received: from dcj21.neoplus.adsl.tpnet.pl ([83.23.61.21] helo=dcc193.neoplus.adsl.tpnet.pl) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImxEz-0000Gi-WC for nemo-archive@lists.ietf.org; Tue, 30 Oct 2007 15:59:11 -0400 Received: from [83.23.54.193] by nnpayn.clixtrix.com; Tue, 30 Oct 2007 19:58:45 +0000 Message-ID: <000501c81b2f$011d9d7d$593ec58c@rgplma> From: "ajai alun" To: "Hal Huerta" Subject: Cocktail party wearing Date: Tue, 30 Oct 2007 18:11:23 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C81B2F.01197DC7" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 2.0 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C81B2F.01197DC7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Life Should be Full of Luxuries, yet, only a handful of people can = afford the finest products, the luxuries of the elite. We are committed to bringing you the finest products, at prices = incomparably lower. Perfectly crafted luxury timepieces, all at = affordable prices. Thousands of different models to choose from! http://my07fg.net/ ------=_NextPart_000_0002_01C81B2F.01197DC7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Life Should be Full of Luxuries, yet, only a handful of people can = afford the finest products,=20 the luxuries of the elite.
We are committed to bringing you the = finest products, at prices=20 incomparably lower. Perfectly crafted luxury timepieces, all at = affordable prices. Thousands=20 of different models to choose from!

http://my07fg.net/ ------=_NextPart_000_0002_01C81B2F.01197DC7-- From nemo-bounces@ietf.org Tue Oct 30 16:13:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImxRh-0001VE-Ru; Tue, 30 Oct 2007 16:12:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImxRb-0001Rb-OE; Tue, 30 Oct 2007 16:12:11 -0400 Received: from ws000774.tietoenator.com ([193.12.181.129]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImxRb-0000lY-Dl; Tue, 30 Oct 2007 16:12:11 -0400 X-AuditID: c10cb581-0000140c00002520-69-47279018476e Received: from camaro.eu.tieto.com ([192.176.143.43]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 21:12:08 +0100 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 21:12:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Oct 2007 21:12:07 +0100 Message-ID: In-Reply-To: <47274A5D.8010505@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Thread-Index: AcgbB59Ys9QNSqAGSkmXcvMuuv+OKAAKU6aA References: <47267BC6.2090302@azairenet.com> <47274A5D.8010505@azairenet.com> From: To: X-OriginalArrivalTime: 30 Oct 2007 20:12:09.0189 (UTC) FILETIME=[266A0950:01C81B31] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, nemo@ietf.org Subject: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Vijay,=20 >=20 > Can we then first conclude that we don't have an issue for > completing the BU/BAck exchange? >=20 > IPsec ESP protection in tunnel mode for payload packets is > optional after all. >=20 Couldn't agree more ! Karen > Vijay >=20 From nemo-bounces@ietf.org Tue Oct 30 16:33:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imxli-000649-Vx; Tue, 30 Oct 2007 16:32:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imxli-00063w-9a; Tue, 30 Oct 2007 16:32:58 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imxlh-0001Qr-Sa; Tue, 30 Oct 2007 16:32:58 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 13:32:56 -0700 Message-ID: <472794F8.6000208@azairenet.com> Date: Tue, 30 Oct 2007 13:32:56 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Karen.Nielsen@tietoenator.com, Hesham@elevatemobile.com, Christian.Kaas-Petersen@tietoenator.com References: <47267BC6.2090302@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2007 20:32:56.0750 (UTC) FILETIME=[0E04BCE0:01C81B34] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: nemo@ietf.org, mip6@ietf.org, Pasi.Eronen@nokia.com Subject: [nemo] Payload protection and NAT traversal X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org It appears to me that we don't really need to change anything for sending BU/BAck as long as we run IKEv2 on port 4500 and negotiate a transport mode SA keyed on the IPv6 home address for protecting the BU/BAck. Now coming to payload protection using ESP in tunnel mode, there is an issue. Payload packets are always sent as follows IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) UDP hdr (dstport=4500) ESP hdr IPv6 hdr (src=V6HOA, dst=CN_V6) Payload If IPv4 packets are being sent, the packet format would be as follows. IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) UDP hdr (dstport=4500) ESP hdr IPv4 hdr (src=V4HOA, dst=CN_V4) Payload So in this case, we are using IPsec NAT traversal. We need IKEv2 to run after every handover before packets can sent/received. Note that the BU/BAck exchange happens immediately without any impact. Note that if tunnel mode ESP protection is not being used for the payload traffic, the packet format would be as follows. IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) UDP hdr (dstport=DS-MIPv6-PORT) ESP hdr IPv6 hdr (src=V6HOA, dst=CN_V6) Payload One option would be to live with this. Payload protection is optional anyway. If you have a secure access link, then you don't really need to encrypt payload traffic. But if you still want to use ESP tunnel mode encryption for the payload, we need a solution. One solution is for the home agent to treat the handover as if the NAT box on the path rebooted (or lost state) and came up with a new NATted IPv4 address and source port for the payload packets sent by the mobile node. The home agent just accepts the packets and responds to the new NATTED port. The home agent can do this for a configurable amount of time while waiting for a fresh IKEv2 exchange to update the NAT traversal information. Vijay From nemo-bounces@ietf.org Tue Oct 30 16:36:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imxoo-0000fw-Ts; Tue, 30 Oct 2007 16:36:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imxon-0000eS-26; Tue, 30 Oct 2007 16:36:09 -0400 Received: from ws000774.tietoenator.com ([193.12.181.129]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imxom-0001XY-IY; Tue, 30 Oct 2007 16:36:08 -0400 X-AuditID: c10cb581-0000248000000558-73-472795b50dce Received: from camaro.eu.tieto.com ([192.176.143.43]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 21:36:05 +0100 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 21:36:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Oct 2007 21:36:05 +0100 Message-ID: In-Reply-To: <472794F8.6000208@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Payload protection and NAT traversal Thread-Index: AcgbNBZxrKlaGsIxTDKu6tywammWyAAAEAnA References: <47267BC6.2090302@azairenet.com> <472794F8.6000208@azairenet.com> From: To: , , X-OriginalArrivalTime: 30 Oct 2007 20:36:06.0990 (UTC) FILETIME=[7F690EE0:01C81B34] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: nemo@ietf.org, mip6@ietf.org, Pasi.Eronen@nokia.com Subject: [nemo] RE: Payload protection and NAT traversal X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Vijay,=20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 > Sent: Tuesday, October 30, 2007 9:33 PM > To: Nielsen Karen E; Hesham@elevatemobile.com; Kaas-Petersen Christian > Cc: mip6@ietf.org; nemo@ietf.org; Pasi.Eronen@nokia.com > Subject: Payload protection and NAT traversal >=20 > It appears to me that we don't really need to change anything for > sending BU/BAck as long as we run IKEv2 on port 4500 and negotiate > a transport mode SA keyed on the IPv6 home address for protecting > the BU/BAck. >=20 > Now coming to payload protection using ESP in tunnel mode, there > is an issue. Payload packets are always sent as follows >=20 > IPv4 hdr (src=3DV4ADDR, dst=3DHA_V4ADDR) > UDP hdr (dstport=3D4500) > ESP hdr > IPv6 hdr (src=3DV6HOA, dst=3DCN_V6) > Payload >=20 > If IPv4 packets are being sent, the packet format would be as > follows. >=20 > IPv4 hdr (src=3DV4ADDR, dst=3DHA_V4ADDR) > UDP hdr (dstport=3D4500) > ESP hdr > IPv4 hdr (src=3DV4HOA, dst=3DCN_V4) > Payload >=20 > So in this case, we are using IPsec NAT traversal. We need IKEv2 > to run after every handover before packets can sent/received. Note > that the BU/BAck exchange happens immediately without any impact. >=20 > Note that if tunnel mode ESP protection is not being used for the > payload traffic, the packet format would be as follows. >=20 > IPv4 hdr (src=3DV4ADDR, dst=3DHA_V4ADDR) > UDP hdr (dstport=3DDS-MIPv6-PORT) > ESP hdr > IPv6 hdr (src=3DV6HOA, dst=3DCN_V6) > Payload >=20 > One option would be to live with this. Payload protection is > optional anyway. If you have a secure access link, then you don't > really need to encrypt payload traffic. >=20 > But if you still want to use ESP tunnel mode encryption for the > payload, we need a solution. One solution is for the home agent to > treat the handover as if the NAT box on the path rebooted (or lost > state) and came up with a new NATted IPv4 address and source port > for the payload packets sent by the mobile node. The home agent > just accepts the packets and responds to the new NATTED port. The > home agent can do this for a configurable amount of time while > waiting for a fresh IKEv2 exchange to update the NAT traversal > information. >=20 Yes, I agree, this is exactly and indeed what I have said. Karen > Vijay >=20 From HeribertosupremacyAyers@howstuffworks.com Tue Oct 30 17:37:31 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImymB-0003mK-QZ; Tue, 30 Oct 2007 17:37:31 -0400 Received: from cpe-24-161-97-107.hvc.res.rr.com ([24.161.97.107] helo=stoner5fylvbwn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ImymB-0003oO-Hh; Tue, 30 Oct 2007 17:37:31 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host77185583.howstuffworks.com (8.13.1/8.13.1) with SMTP id eIk0zfaq54.855918.8fS.KbN.4014975253103 for ; Tue, 30 Oct 2007 17:37:04 +0500 Message-ID: <11e8801c81b3d$13401160$0301a8c0@stoner5fylvbwn> From: "Hiram Trujillo" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_11E84_01C81B3D.13401160-- From HungmarjorieCardenas@rulers.org Tue Oct 30 18:36:34 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImzhJ-000764-U9; Tue, 30 Oct 2007 18:36:33 -0400 Received: from 24-177-13-199.dhcp.nwtn.ct.charter.com ([24.177.13.199] helo=rampcospare) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ImzhJ-0005sp-HI; Tue, 30 Oct 2007 18:36:33 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host26878421.rulers.org (8.13.1/8.13.1) with SMTP id cao1Mtz988.281487.rYx.dN6.0802958574948 for ; Tue, 30 Oct 2007 18:36:07 +0500 Message-ID: <10d4001c81b45$52e03d60$6600a8c0@rampcospare> From: "Giovanni Peck" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_10D3C_01C81B45.52E03D60-- From nemo-bounces@ietf.org Tue Oct 30 19:33:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In0Z1-00006D-L0; Tue, 30 Oct 2007 19:32:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In0Z0-0008Jl-0L; Tue, 30 Oct 2007 19:32:02 -0400 Received: from omta01sl.mx.bigpond.com ([144.140.92.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In0Yo-0003zv-VB; Tue, 30 Oct 2007 19:31:57 -0400 Received: from oaamta02sl.mx.bigpond.com ([124.190.106.219]) by omta01sl.mx.bigpond.com with ESMTP id <20071030233118.ZGFW26650.omta01sl.mx.bigpond.com@oaamta02sl.mx.bigpond.com>; Tue, 30 Oct 2007 23:31:18 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta02sl.mx.bigpond.com with ESMTP id <20071030233117.SOZK10066.oaamta02sl.mx.bigpond.com@PC20005>; Tue, 30 Oct 2007 23:31:17 +0000 From: "Hesham Soliman" To: "'Vijay Devarapalli'" , , Date: Wed, 31 Oct 2007 10:30:43 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcgajHdXweg6hCAlQHqWKMbnBJLpbwAyKW7w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47267BC6.2090302@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org This is exactly what we've been discussing, except you took out the case of protection of payload packets. So the solution you list below cannot be compared with alt 1 or 2 because it only addresses part of the problem, i.e. no payload security. Hesham > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Tuesday, October 30, 2007 10:33 AM > To: Hesham Soliman; Karen.Nielsen@tietoenator.com; > Christian.Kaas-Petersen@tietoenator.com > Cc: mip6@ietf.org; nemo@ietf.org > Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus > > Thanks Hesham. > > I think I mixed up solution 2 described below in your email with > solution 2 described in an email you sent on the 17th of October. > http://www1.ietf.org/mail-archive/web/mip6/current/msg06856.html > > I do want to avoid two round trips during every handover. I also want > to avoid running MOBIKE at the same time as MIPv6. Does not > make sense. > > Having said, I would like to figure out whats wrong with > running IKEv2 > on port 4500, but sending the BU on DS-MIPv6 port with a > transport mode > SA. > > Lets say IKEv2 runs on UDP port 4500 always and negotiates a > transport > mode SA for protecting the BU. > > When the BU packet goes through the SPD entries, the > transport mode SA > is picked. After IPsec processing the packet will be as follows > > IPv6 hdr (src=V6HOA, dst=HAADDR) > ESP Hdr > BU > IPv4 CoA option > > With DS-MIPv6 encapsulation the packet becomes > > IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) > UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) > IPv6 hdr (src=V6HOA, dst=HAADDR) > ESP Hdr > BU > IPv4 CoA option > > Now lets assume the mobile node moves and attaches to another IPv4 > access network. The transport mode IPsec SA is still valid. IKEv2 > does not know that the mobile node moved, its IPv4 address changed > or if there is a new NAT in the path. So the mobile node can send > a BU right away as follows. > > IPv4 hdr (src=new_V4ADDR, dst=HA_V4ADDR) > UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) > IPv6 hdr (src=V6HOA, dst=HAADDR) > ESP Hdr > BU > IPv4 CoA option (new IPv4 CoA) > > When the HA receives the BU, the packet will appear like the > following > > IPv4 hdr (src=NATTED_new_V4ADDR, dst=HA_V4ADDR) > UDP hdr (srcport=NATTED_DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) > IPv6 hdr (src=V6HOA, dst=HAADDR) > ESP Hdr > BU > IPv4 CoA option (new IPv4 CoA) > > The HA would process the BU and respond to the NATTED_DS-MIPv6-PORT. > > Meanwhile the MIPv6 stack on the mobile node will trigger the IKEv2 > daemon on the mobile node to re-run IKEv2. This is because > the original > IKEv2 SA is not valid anymore. When the IKEv2 SAs are > re-negotiated, new > IPsec SAs are also setup. > > This would allow the IKEv2 exchange to happen out of the > critical path. > There is no update to the IKEv2 SA based on the BU/BAck > exchange. There > are no tunnel mode SAs created for any MIPv6 signaling messages. What > am I missing now? > > Vijay > > Hesham Soliman wrote: > > > IMO, we should go with solution 2) below. I prefer that we let > > > IKEv2 use its own NAT traversal mechanism. Regarding two round > > > trips during a handover, note that the IKEv2 exchange to > > > re-establish the IKEv2 SA and the IPsec SAs is not in the > > > critical path of handover. > > > > => It is in the critical path for the secure packets. > That's what the > > discussion was about. > > > > The BU/BAck messages can be exchanged > > > with the existing IPsec SAs. The IKEv2 exchange can be happen a > > > few seconds (or minutes) after the handover. So there is *no* > > > impact on the handover. > > > > => No, see above. This is only good for insecure traffic. > At least this is > > not solution 2 below. > > > > Hesham > > > > > > > > This would be the same as the lack of support for the "K" flag > > > in RFC 3775. In RFC 3775, if either the mobile node or the home > > > agent are not capable of updating the IKE SA based on the > > > exchange of BU/BAck, there is always an IKE exchange after the > > > handover (or whenever the CoA changes). > > > > > > Please let me know if I am missing something related to the > > > impact of the IKEv2 exchange on the handover. > > > > > > I am not comfortable with the temporary tunnel created in > > > solution 1). > > > > > > Vijay > > > > > > Hesham Soliman wrote: > > > > Folks, > > > > > > > > This discussion has been going on for a while and I'm sure > > > it wasn't for > > > > easy to follow. > > > > This email contains a summary of the discussion so far and > > > a call for > > > > comment/concensus. Please respond promptly because there > > > is some pressure > > > > from 3GPP to get this draft out very soon. > > > > > > > > The issue is how to run IKE in combination with DSMIPv6 in > > > a private > > > > IPv4-only network. If you want more detail about why this > > > is a problem > > > > please look at the thread "DSMIPv6 and IKE". > > > > > > > > There are three types of solutions that we discussed. A > > > quick summary of > > > > each below: > > > > > > > > 1. The Virtual link approach. In this case IKE runs over > > > v6 only and is > > > > completely unaware of the IPv4 network. As a result IKE's > > > NAT traversal is > > > > never invoked. Only DSMIPv6's NAT traversal is used. In > > > this approach, the > > > > DSMIPv6 implementation in the HA is required to cache the > > > outer IPv4 address > > > > and source port of the IPv4 message that contains IKE, > > > then append them to > > > > the response from its own IKE daemon. This is basically > > > done to hide the > > > > IPv4 network from IKE and effectively disable its NAT > > > traversal, which > > > > solves our problem. > > > > Three people agreed with this approach but two people (I'm > > > including > > > > Christian) are against it. So there doesn't seem to be > > > concensus on this. I > > > > believe the concern here was that the HA's caching of the > > > outer address and > > > > port was complex for the implementation. > > > > > > > > 2. Karen suggested a way of running IKE without any > > > changes (again see the > > > > thread for details). In this approach DSMIPv6 BUs are > > > secured with ESP as > > > > usual. Normal traffic is sent over the DSMIPv6 port. > > > However, secure traffic > > > > is sent over the IKE port (4500). The result of this > > > approach is that it > > > > takes two messages to complete a handover, one from > > > DSMIPv6 (BU) and an > > > > update from IKE (for the secure traffic). The concern that > > > I had here in the > > > > discussion with Karen was the number of messages and the > > > delays associated > > > > for that. Of course IKE doesn't do movement detection > > > ...etc. So my concern > > > > is the discriminatory experience of the handover for > > > different parts of the > > > > traffic. > > > > > > > > 3. The third class of solutions involves either modifying > > > MIPv6 (adding new > > > > messages) or IKE or both. I'm only including this for > > > completeness, no one > > > > really wants this. > > > > > > > > Please send your comments on the above. Basically the > > > options are 1 or 2. In > > > > theory we could do both but I think it's best to pick one > > > method for this to > > > > avoid interoperability issues and additional complexity. > > > > > > > > Hesham > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Mip6 mailing list > > > > Mip6@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > > > > > > From nemo-bounces@ietf.org Tue Oct 30 19:39:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In0fk-0005v8-IW; Tue, 30 Oct 2007 19:39:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In0fj-0005sb-3Y; Tue, 30 Oct 2007 19:38:59 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In0fY-0004HO-HU; Tue, 30 Oct 2007 19:38:55 -0400 Received: from oaamta05sl.mx.bigpond.com ([124.190.106.219]) by omta05sl.mx.bigpond.com with ESMTP id <20071030233814.UIYJ14987.omta05sl.mx.bigpond.com@oaamta05sl.mx.bigpond.com>; Tue, 30 Oct 2007 23:38:14 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta05sl.mx.bigpond.com with ESMTP id <20071030233814.SZWF18730.oaamta05sl.mx.bigpond.com@PC20005>; Tue, 30 Oct 2007 23:38:14 +0000 From: "Hesham Soliman" To: "'Vijay Devarapalli'" , , Date: Wed, 31 Oct 2007 10:38:02 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcgbNA/08l1Q0mhmTfCXR/cDOHEAgQAIcHmg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <472794F8.6000208@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: nemo@ietf.org, mip6@ietf.org, Pasi.Eronen@nokia.com Subject: [nemo] RE: Payload protection and NAT traversal X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > It appears to me that we don't really need to change anything for > sending BU/BAck as long as we run IKEv2 on port 4500 and negotiate > a transport mode SA keyed on the IPv6 home address for protecting > the BU/BAck. > > Now coming to payload protection using ESP in tunnel mode, there > is an issue. Payload packets are always sent as follows > > IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) > UDP hdr (dstport=4500) > ESP hdr > IPv6 hdr (src=V6HOA, dst=CN_V6) > Payload > > If IPv4 packets are being sent, the packet format would be as > follows. > > IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) > UDP hdr (dstport=4500) > ESP hdr > IPv4 hdr (src=V4HOA, dst=CN_V4) > Payload > > So in this case, we are using IPsec NAT traversal. We need IKEv2 > to run after every handover before packets can sent/received. Note > that the BU/BAck exchange happens immediately without any impact. > > Note that if tunnel mode ESP protection is not being used for the > payload traffic, the packet format would be as follows. > > IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) > UDP hdr (dstport=DS-MIPv6-PORT) > ESP hdr > IPv6 hdr (src=V6HOA, dst=CN_V6) > Payload > > One option would be to live with this. Payload protection is > optional anyway. If you have a secure access link, then you don't > really need to encrypt payload traffic. > > But if you still want to use ESP tunnel mode encryption for the > payload, we need a solution. One solution is for the home agent to > treat the handover as if the NAT box on the path rebooted (or lost > state) and came up with a new NATted IPv4 address and source port > for the payload packets sent by the mobile node. The home agent > just accepts the packets and responds to the new NATTED port. The > home agent can do this for a configurable amount of time while > waiting for a fresh IKEv2 exchange to update the NAT traversal > information. => These are all options, true. So you're saying the HA stores both sets of information for a short time? Because the change could also be a DoS, so until a timeout takes place the HA wouldn't know whether it was a genuine change or an attack. Hesham From nemo-bounces@ietf.org Tue Oct 30 19:50:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In0q7-000125-4a; Tue, 30 Oct 2007 19:49:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In0q5-00011p-ME; Tue, 30 Oct 2007 19:49:41 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In0pz-0004nn-CE; Tue, 30 Oct 2007 19:49:41 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 16:49:29 -0700 Message-ID: <4727C308.6040004@azairenet.com> Date: Tue, 30 Oct 2007 16:49:28 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2007 23:49:29.0719 (UTC) FILETIME=[832D0070:01C81B4F] X-Spam-Score: 0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, nemo@ietf.org Subject: [nemo] Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hesham Soliman wrote: > This is exactly what we've been discussing, except you took out the case of > protection of payload packets. hmm... are you sure? You said a couple of times that sending a BU would take two round trips for solution 2. > So the solution you list below cannot be > compared with alt 1 or 2 Neither solution 1 nor 2 will work for payload security when you use ESP in tunnel mode for the payload packets. > because it only addresses part of the problem, i.e. > no payload security. Note that providing payload security was never a requirement. Vijay > > Hesham > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > Sent: Tuesday, October 30, 2007 10:33 AM > > To: Hesham Soliman; Karen.Nielsen@tietoenator.com; > > Christian.Kaas-Petersen@tietoenator.com > > Cc: mip6@ietf.org; nemo@ietf.org > > Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus > > > > Thanks Hesham. > > > > I think I mixed up solution 2 described below in your email with > > solution 2 described in an email you sent on the 17th of October. > > http://www1.ietf.org/mail-archive/web/mip6/current/msg06856.html > > > > I do want to avoid two round trips during every handover. I also want > > to avoid running MOBIKE at the same time as MIPv6. Does not > > make sense. > > > > Having said, I would like to figure out whats wrong with > > running IKEv2 > > on port 4500, but sending the BU on DS-MIPv6 port with a > > transport mode > > SA. > > > > Lets say IKEv2 runs on UDP port 4500 always and negotiates a > > transport > > mode SA for protecting the BU. > > > > When the BU packet goes through the SPD entries, the > > transport mode SA > > is picked. After IPsec processing the packet will be as follows > > > > IPv6 hdr (src=V6HOA, dst=HAADDR) > > ESP Hdr > > BU > > IPv4 CoA option > > > > With DS-MIPv6 encapsulation the packet becomes > > > > IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) > > UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) > > IPv6 hdr (src=V6HOA, dst=HAADDR) > > ESP Hdr > > BU > > IPv4 CoA option > > > > Now lets assume the mobile node moves and attaches to another IPv4 > > access network. The transport mode IPsec SA is still valid. IKEv2 > > does not know that the mobile node moved, its IPv4 address changed > > or if there is a new NAT in the path. So the mobile node can send > > a BU right away as follows. > > > > IPv4 hdr (src=new_V4ADDR, dst=HA_V4ADDR) > > UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) > > IPv6 hdr (src=V6HOA, dst=HAADDR) > > ESP Hdr > > BU > > IPv4 CoA option (new IPv4 CoA) > > > > When the HA receives the BU, the packet will appear like the > > following > > > > IPv4 hdr (src=NATTED_new_V4ADDR, dst=HA_V4ADDR) > > UDP hdr (srcport=NATTED_DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) > > IPv6 hdr (src=V6HOA, dst=HAADDR) > > ESP Hdr > > BU > > IPv4 CoA option (new IPv4 CoA) > > > > The HA would process the BU and respond to the NATTED_DS-MIPv6-PORT. > > > > Meanwhile the MIPv6 stack on the mobile node will trigger the IKEv2 > > daemon on the mobile node to re-run IKEv2. This is because > > the original > > IKEv2 SA is not valid anymore. When the IKEv2 SAs are > > re-negotiated, new > > IPsec SAs are also setup. > > > > This would allow the IKEv2 exchange to happen out of the > > critical path. > > There is no update to the IKEv2 SA based on the BU/BAck > > exchange. There > > are no tunnel mode SAs created for any MIPv6 signaling messages. What > > am I missing now? > > > > Vijay > > > > Hesham Soliman wrote: > > > > IMO, we should go with solution 2) below. I prefer that we let > > > > IKEv2 use its own NAT traversal mechanism. Regarding two round > > > > trips during a handover, note that the IKEv2 exchange to > > > > re-establish the IKEv2 SA and the IPsec SAs is not in the > > > > critical path of handover. > > > > > > => It is in the critical path for the secure packets. > > That's what the > > > discussion was about. > > > > > > The BU/BAck messages can be exchanged > > > > with the existing IPsec SAs. The IKEv2 exchange can be happen a > > > > few seconds (or minutes) after the handover. So there is *no* > > > > impact on the handover. > > > > > > => No, see above. This is only good for insecure traffic. > > At least this is > > > not solution 2 below. > > > > > > Hesham > > > > > > > > > > > This would be the same as the lack of support for the "K" flag > > > > in RFC 3775. In RFC 3775, if either the mobile node or the home > > > > agent are not capable of updating the IKE SA based on the > > > > exchange of BU/BAck, there is always an IKE exchange after the > > > > handover (or whenever the CoA changes). > > > > > > > > Please let me know if I am missing something related to the > > > > impact of the IKEv2 exchange on the handover. > > > > > > > > I am not comfortable with the temporary tunnel created in > > > > solution 1). > > > > > > > > Vijay > > > > > > > > Hesham Soliman wrote: > > > > > Folks, > > > > > > > > > > This discussion has been going on for a while and I'm sure > > > > it wasn't for > > > > > easy to follow. > > > > > This email contains a summary of the discussion so far and > > > > a call for > > > > > comment/concensus. Please respond promptly because there > > > > is some pressure > > > > > from 3GPP to get this draft out very soon. > > > > > > > > > > The issue is how to run IKE in combination with DSMIPv6 in > > > > a private > > > > > IPv4-only network. If you want more detail about why this > > > > is a problem > > > > > please look at the thread "DSMIPv6 and IKE". > > > > > > > > > > There are three types of solutions that we discussed. A > > > > quick summary of > > > > > each below: > > > > > > > > > > 1. The Virtual link approach. In this case IKE runs over > > > > v6 only and is > > > > > completely unaware of the IPv4 network. As a result IKE's > > > > NAT traversal is > > > > > never invoked. Only DSMIPv6's NAT traversal is used. In > > > > this approach, the > > > > > DSMIPv6 implementation in the HA is required to cache the > > > > outer IPv4 address > > > > > and source port of the IPv4 message that contains IKE, > > > > then append them to > > > > > the response from its own IKE daemon. This is basically > > > > done to hide the > > > > > IPv4 network from IKE and effectively disable its NAT > > > > traversal, which > > > > > solves our problem. > > > > > Three people agreed with this approach but two people (I'm > > > > including > > > > > Christian) are against it. So there doesn't seem to be > > > > concensus on this. I > > > > > believe the concern here was that the HA's caching of the > > > > outer address and > > > > > port was complex for the implementation. > > > > > > > > > > 2. Karen suggested a way of running IKE without any > > > > changes (again see the > > > > > thread for details). In this approach DSMIPv6 BUs are > > > > secured with ESP as > > > > > usual. Normal traffic is sent over the DSMIPv6 port. > > > > However, secure traffic > > > > > is sent over the IKE port (4500). The result of this > > > > approach is that it > > > > > takes two messages to complete a handover, one from > > > > DSMIPv6 (BU) and an > > > > > update from IKE (for the secure traffic). The concern that > > > > I had here in the > > > > > discussion with Karen was the number of messages and the > > > > delays associated > > > > > for that. Of course IKE doesn't do movement detection > > > > ...etc. So my concern > > > > > is the discriminatory experience of the handover for > > > > different parts of the > > > > > traffic. > > > > > > > > > > 3. The third class of solutions involves either modifying > > > > MIPv6 (adding new > > > > > messages) or IKE or both. I'm only including this for > > > > completeness, no one > > > > > really wants this. > > > > > > > > > > Please send your comments on the above. Basically the > > > > options are 1 or 2. In > > > > > theory we could do both but I think it's best to pick one > > > > method for this to > > > > > avoid interoperability issues and additional complexity. > > > > > > > > > > Hesham > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Mip6 mailing list > > > > > Mip6@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > > > > > > > > > > > > > > > From yj@premier-bkk.com Tue Oct 30 19:53:45 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In0u1-00083S-LW for nemo-archive@lists.ietf.org; Tue, 30 Oct 2007 19:53:45 -0400 Received: from [62.5.180.230] (helo=srxa) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1In0ty-0004xY-9v for nemo-archive@lists.ietf.org; Tue, 30 Oct 2007 19:53:43 -0400 Received: from uylfh ([188.105.220.206]) by srxa with Microsoft SMTPSVC(5.0.2195.6713); Wed, 31 Oct 2007 02:51:17 +0300 Message-ID: <002001c81b4f$c37d8a50$cedc69bc@uylfh> From: To: Subject: Send this to your friends Date: Wed, 31 Oct 2007 02:51:17 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Score: 2.4 (++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Trick or Treat. Have some fun for 5 min. http://24.209.187.178/ From nemo-bounces@ietf.org Tue Oct 30 19:54:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In0ue-0000EH-It; Tue, 30 Oct 2007 19:54:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In0uc-0008Ds-DO; Tue, 30 Oct 2007 19:54:22 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In0uI-00007V-Iv; Tue, 30 Oct 2007 19:54:04 -0400 Received: from oaamta05sl.mx.bigpond.com ([124.190.106.219]) by omta05sl.mx.bigpond.com with ESMTP id <20071030235359.VACY14987.omta05sl.mx.bigpond.com@oaamta05sl.mx.bigpond.com>; Tue, 30 Oct 2007 23:53:59 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta05sl.mx.bigpond.com with ESMTP id <20071030235358.THKL18730.oaamta05sl.mx.bigpond.com@PC20005>; Tue, 30 Oct 2007 23:53:58 +0000 From: "Hesham Soliman" To: "'Vijay Devarapalli'" Date: Wed, 31 Oct 2007 10:53:47 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcgbT4eDdrodxwaHTL2zUGtNbkQ8mgACIHgQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4727C308.6040004@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, nemo@ietf.org Subject: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > Hesham Soliman wrote: > > This is exactly what we've been discussing, except you > took out the case of > > protection of payload packets. > > hmm... are you sure? You said a couple of times that sending a BU > would take two round trips for solution 2. => No, I said the handover would take 2 RTTs. > > > So the solution you list below cannot be > > compared with alt 1 or 2 > > Neither solution 1 nor 2 will work for payload security when you > use ESP in tunnel mode for the payload packets. => Sure they will, Karen already sent the packet formats. Solution 2 uses port 4500 for tunnel mode, hence the entire discussion about 2 RTT handovers. > > > because it only addresses part of the problem, i.e. > > no payload security. > > Note that providing payload security was never a requirement. => You mean for DSMIPv6? I think we have to be realistic. I don't think it makes sense to use MIP6 and Mobike at the same time just so we can encrypt payload traffic. I think you agreed with that in your last email. So, if you don't want that then you need to figure out how to secure payload traffic. Otherwise, the solution we have will only look good on paper. Hesham > > Vijay > > > > > Hesham > > > > > -----Original Message----- > > > From: Vijay Devarapalli > [mailto:vijay.devarapalli@azairenet.com] > > > Sent: Tuesday, October 30, 2007 10:33 AM > > > To: Hesham Soliman; Karen.Nielsen@tietoenator.com; > > > Christian.Kaas-Petersen@tietoenator.com > > > Cc: mip6@ietf.org; nemo@ietf.org > > > Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call > for concensus > > > > > > Thanks Hesham. > > > > > > I think I mixed up solution 2 described below in your email with > > > solution 2 described in an email you sent on the 17th > of October. > > > http://www1.ietf.org/mail-archive/web/mip6/current/msg06856.html > > > > > > I do want to avoid two round trips during every > handover. I also want > > > to avoid running MOBIKE at the same time as MIPv6. Does not > > > make sense. > > > > > > Having said, I would like to figure out whats wrong with > > > running IKEv2 > > > on port 4500, but sending the BU on DS-MIPv6 port with a > > > transport mode > > > SA. > > > > > > Lets say IKEv2 runs on UDP port 4500 always and negotiates a > > > transport > > > mode SA for protecting the BU. > > > > > > When the BU packet goes through the SPD entries, the > > > transport mode SA > > > is picked. After IPsec processing the packet will be as follows > > > > > > IPv6 hdr (src=V6HOA, dst=HAADDR) > > > ESP Hdr > > > BU > > > IPv4 CoA option > > > > > > With DS-MIPv6 encapsulation the packet becomes > > > > > > IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) > > > UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) > > > IPv6 hdr (src=V6HOA, dst=HAADDR) > > > ESP Hdr > > > BU > > > IPv4 CoA option > > > > > > Now lets assume the mobile node moves and attaches to > another IPv4 > > > access network. The transport mode IPsec SA is still > valid. IKEv2 > > > does not know that the mobile node moved, its IPv4 > address changed > > > or if there is a new NAT in the path. So the mobile > node can send > > > a BU right away as follows. > > > > > > IPv4 hdr (src=new_V4ADDR, dst=HA_V4ADDR) > > > UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) > > > IPv6 hdr (src=V6HOA, dst=HAADDR) > > > ESP Hdr > > > BU > > > IPv4 CoA option (new IPv4 CoA) > > > > > > When the HA receives the BU, the packet will appear like the > > > following > > > > > > IPv4 hdr (src=NATTED_new_V4ADDR, dst=HA_V4ADDR) > > > UDP hdr (srcport=NATTED_DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) > > > IPv6 hdr (src=V6HOA, dst=HAADDR) > > > ESP Hdr > > > BU > > > IPv4 CoA option (new IPv4 CoA) > > > > > > The HA would process the BU and respond to the > NATTED_DS-MIPv6-PORT. > > > > > > Meanwhile the MIPv6 stack on the mobile node will > trigger the IKEv2 > > > daemon on the mobile node to re-run IKEv2. This is because > > > the original > > > IKEv2 SA is not valid anymore. When the IKEv2 SAs are > > > re-negotiated, new > > > IPsec SAs are also setup. > > > > > > This would allow the IKEv2 exchange to happen out of the > > > critical path. > > > There is no update to the IKEv2 SA based on the BU/BAck > > > exchange. There > > > are no tunnel mode SAs created for any MIPv6 signaling > messages. What > > > am I missing now? > > > > > > Vijay > > > > > > Hesham Soliman wrote: > > > > > IMO, we should go with solution 2) below. I prefer > that we let > > > > > IKEv2 use its own NAT traversal mechanism. > Regarding two round > > > > > trips during a handover, note that the IKEv2 exchange to > > > > > re-establish the IKEv2 SA and the IPsec SAs is not in the > > > > > critical path of handover. > > > > > > > > => It is in the critical path for the secure packets. > > > That's what the > > > > discussion was about. > > > > > > > > The BU/BAck messages can be exchanged > > > > > with the existing IPsec SAs. The IKEv2 exchange > can be happen a > > > > > few seconds (or minutes) after the handover. So > there is *no* > > > > > impact on the handover. > > > > > > > > => No, see above. This is only good for insecure traffic. > > > At least this is > > > > not solution 2 below. > > > > > > > > Hesham > > > > > > > > > > > > > > This would be the same as the lack of support for > the "K" flag > > > > > in RFC 3775. In RFC 3775, if either the mobile > node or the home > > > > > agent are not capable of updating the IKE SA based on the > > > > > exchange of BU/BAck, there is always an IKE > exchange after the > > > > > handover (or whenever the CoA changes). > > > > > > > > > > Please let me know if I am missing something related to the > > > > > impact of the IKEv2 exchange on the handover. > > > > > > > > > > I am not comfortable with the temporary tunnel created in > > > > > solution 1). > > > > > > > > > > Vijay > > > > > > > > > > Hesham Soliman wrote: > > > > > > Folks, > > > > > > > > > > > > This discussion has been going on for a while > and I'm sure > > > > > it wasn't for > > > > > > easy to follow. > > > > > > This email contains a summary of the discussion > so far and > > > > > a call for > > > > > > comment/concensus. Please respond promptly because there > > > > > is some pressure > > > > > > from 3GPP to get this draft out very soon. > > > > > > > > > > > > The issue is how to run IKE in combination with > DSMIPv6 in > > > > > a private > > > > > > IPv4-only network. If you want more detail about > why this > > > > > is a problem > > > > > > please look at the thread "DSMIPv6 and IKE". > > > > > > > > > > > > There are three types of solutions that we discussed. A > > > > > quick summary of > > > > > > each below: > > > > > > > > > > > > 1. The Virtual link approach. In this case IKE runs over > > > > > v6 only and is > > > > > > completely unaware of the IPv4 network. As a > result IKE's > > > > > NAT traversal is > > > > > > never invoked. Only DSMIPv6's NAT traversal is used. In > > > > > this approach, the > > > > > > DSMIPv6 implementation in the HA is required to > cache the > > > > > outer IPv4 address > > > > > > and source port of the IPv4 message that contains IKE, > > > > > then append them to > > > > > > the response from its own IKE daemon. This is basically > > > > > done to hide the > > > > > > IPv4 network from IKE and effectively disable its NAT > > > > > traversal, which > > > > > > solves our problem. > > > > > > Three people agreed with this approach but two > people (I'm > > > > > including > > > > > > Christian) are against it. So there doesn't seem to be > > > > > concensus on this. I > > > > > > believe the concern here was that the HA's > caching of the > > > > > outer address and > > > > > > port was complex for the implementation. > > > > > > > > > > > > 2. Karen suggested a way of running IKE without any > > > > > changes (again see the > > > > > > thread for details). In this approach DSMIPv6 BUs are > > > > > secured with ESP as > > > > > > usual. Normal traffic is sent over the DSMIPv6 port. > > > > > However, secure traffic > > > > > > is sent over the IKE port (4500). The result of this > > > > > approach is that it > > > > > > takes two messages to complete a handover, one from > > > > > DSMIPv6 (BU) and an > > > > > > update from IKE (for the secure traffic). The > concern that > > > > > I had here in the > > > > > > discussion with Karen was the number of messages and the > > > > > delays associated > > > > > > for that. Of course IKE doesn't do movement detection > > > > > ...etc. So my concern > > > > > > is the discriminatory experience of the handover for > > > > > different parts of the > > > > > > traffic. > > > > > > > > > > > > 3. The third class of solutions involves either > modifying > > > > > MIPv6 (adding new > > > > > > messages) or IKE or both. I'm only including this for > > > > > completeness, no one > > > > > > really wants this. > > > > > > > > > > > > Please send your comments on the above. Basically the > > > > > options are 1 or 2. In > > > > > > theory we could do both but I think it's best to > pick one > > > > > method for this to > > > > > > avoid interoperability issues and additional complexity. > > > > > > > > > > > > Hesham > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Mip6 mailing list > > > > > > Mip6@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From nemo-bounces@ietf.org Tue Oct 30 20:04:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In13s-0001BS-3c; Tue, 30 Oct 2007 20:03:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In13q-00012G-Bx; Tue, 30 Oct 2007 20:03:54 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In13p-0000SR-VF; Tue, 30 Oct 2007 20:03:54 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 17:03:51 -0700 Message-ID: <4727C667.9020709@azairenet.com> Date: Tue, 30 Oct 2007 17:03:51 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2007 00:03:51.0886 (UTC) FILETIME=[85113EE0:01C81B51] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, nemo@ietf.org Subject: [nemo] Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hesham Soliman wrote: > > Hesham Soliman wrote: > > > This is exactly what we've been discussing, except you > > took out the case of > > > protection of payload packets. > > > > hmm... are you sure? You said a couple of times that sending a BU > > would take two round trips for solution 2. > > => No, I said the handover would take 2 RTTs. Ok never mind then. BU/BAck exchange does not require two round trips. > > > So the solution you list below cannot be > > > compared with alt 1 or 2 > > > > Neither solution 1 nor 2 will work for payload security when you > > use ESP in tunnel mode for the payload packets. > > => Sure they will, Karen already sent the packet formats. Solution 2 uses > port 4500 for tunnel mode, hence the entire discussion about 2 RTT > handovers. I repeat, none of the solutions work as long as you use ESP UDP encapsulation (port 4500) for the payload traffic to the CN. > > > because it only addresses part of the problem, i.e. > > > no payload security. > > > > Note that providing payload security was never a requirement. > > => You mean for DSMIPv6? I think we have to be realistic. I don't think it > makes sense to use MIP6 and Mobike at the same time just so we can encrypt > payload traffic. I think you agreed with that in your last email. So, if you > don't want that then you need to figure out how to secure payload traffic. > Otherwise, the solution we have will only look good on paper. RFC 3775, 3776 and 4877 say ESP protection for payload traffic is optional. If you have a secure access link or if you application layer security obviously you don't need to encrypt all traffic reverse tunneled through the home agent. Vijay From nemo-bounces@ietf.org Tue Oct 30 20:04:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In14Q-0001dH-TP; Tue, 30 Oct 2007 20:04:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In14O-0001cG-CU; Tue, 30 Oct 2007 20:04:28 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In14L-0005P9-6S; Tue, 30 Oct 2007 20:04:28 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 17:04:23 -0700 Message-ID: <4727C686.10503@azairenet.com> Date: Tue, 30 Oct 2007 17:04:22 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2007 00:04:23.0245 (UTC) FILETIME=[97C23FD0:01C81B51] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, Pasi.Eronen@nokia.com, nemo@ietf.org Subject: [nemo] Re: Payload protection and NAT traversal X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hesham Soliman wrote: > > It appears to me that we don't really need to change anything for > > sending BU/BAck as long as we run IKEv2 on port 4500 and negotiate > > a transport mode SA keyed on the IPv6 home address for protecting > > the BU/BAck. > > > > Now coming to payload protection using ESP in tunnel mode, there > > is an issue. Payload packets are always sent as follows > > > > IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) > > UDP hdr (dstport=4500) > > ESP hdr > > IPv6 hdr (src=V6HOA, dst=CN_V6) > > Payload > > > > If IPv4 packets are being sent, the packet format would be as > > follows. > > > > IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) > > UDP hdr (dstport=4500) > > ESP hdr > > IPv4 hdr (src=V4HOA, dst=CN_V4) > > Payload > > > > So in this case, we are using IPsec NAT traversal. We need IKEv2 > > to run after every handover before packets can sent/received. Note > > that the BU/BAck exchange happens immediately without any impact. > > > > Note that if tunnel mode ESP protection is not being used for the > > payload traffic, the packet format would be as follows. > > > > IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) > > UDP hdr (dstport=DS-MIPv6-PORT) > > ESP hdr > > IPv6 hdr (src=V6HOA, dst=CN_V6) > > Payload > > > > One option would be to live with this. Payload protection is > > optional anyway. If you have a secure access link, then you don't > > really need to encrypt payload traffic. > > > > But if you still want to use ESP tunnel mode encryption for the > > payload, we need a solution. One solution is for the home agent to > > treat the handover as if the NAT box on the path rebooted (or lost > > state) and came up with a new NATted IPv4 address and source port > > for the payload packets sent by the mobile node. The home agent > > just accepts the packets and responds to the new NATTED port. The > > home agent can do this for a configurable amount of time while > > waiting for a fresh IKEv2 exchange to update the NAT traversal > > information. > > => These are all options, true. So you're saying the HA stores both sets of > information for a short time? Because the change could also be a DoS, so > until a timeout takes place the HA wouldn't know whether it was a genuine > change or an attack. You are supposed to deal with intermediate NATs losing state and allocating new NATed source address and source port anyway. Nothing new. Vijay From nemo-bounces@ietf.org Tue Oct 30 20:13:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1Ca-0005Ao-R1; Tue, 30 Oct 2007 20:12:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1CY-0005AU-Qs; Tue, 30 Oct 2007 20:12:54 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In1CS-0005mj-9h; Tue, 30 Oct 2007 20:12:54 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9V0Bf6H003136; Wed, 31 Oct 2007 02:12:17 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 02:12:13 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 19:12:10 -0500 Received: from 10.241.59.168 ([10.241.59.168]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 31 Oct 2007 00:12:10 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 30 Oct 2007 19:12:51 -0500 From: Basavaraj Patil To: ext Hesham Soliman , Vijay Devarapalli , , Message-ID: Thread-Topic: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Thread-Index: AcgajHdXweg6hCAlQHqWKMbnBJLpbwAyKW7wAACVqhA= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 31 Oct 2007 00:12:10.0811 (UTC) FILETIME=[AE7328B0:01C81B52] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org But Hesham... Do we need to solve the payload security issue? I thought the MIP6 signaling security was what was being tackled. 0Raj On 10/30/07 7:30 PM, "ext Hesham Soliman" wrote: > This is exactly what we've been discussing, except you took out the case of > protection of payload packets. So the solution you list below cannot be > compared with alt 1 or 2 because it only addresses part of the problem, i.e. > no payload security. > > Hesham > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >> Sent: Tuesday, October 30, 2007 10:33 AM >> To: Hesham Soliman; Karen.Nielsen@tietoenator.com; >> Christian.Kaas-Petersen@tietoenator.com >> Cc: mip6@ietf.org; nemo@ietf.org >> Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus >> >> Thanks Hesham. >> >> I think I mixed up solution 2 described below in your email with >> solution 2 described in an email you sent on the 17th of October. >> http://www1.ietf.org/mail-archive/web/mip6/current/msg06856.html >> >> I do want to avoid two round trips during every handover. I also want >> to avoid running MOBIKE at the same time as MIPv6. Does not >> make sense. >> >> Having said, I would like to figure out whats wrong with >> running IKEv2 >> on port 4500, but sending the BU on DS-MIPv6 port with a >> transport mode >> SA. >> >> Lets say IKEv2 runs on UDP port 4500 always and negotiates a >> transport >> mode SA for protecting the BU. >> >> When the BU packet goes through the SPD entries, the >> transport mode SA >> is picked. After IPsec processing the packet will be as follows >> >> IPv6 hdr (src=V6HOA, dst=HAADDR) >> ESP Hdr >> BU >> IPv4 CoA option >> >> With DS-MIPv6 encapsulation the packet becomes >> >> IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) >> UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) >> IPv6 hdr (src=V6HOA, dst=HAADDR) >> ESP Hdr >> BU >> IPv4 CoA option >> >> Now lets assume the mobile node moves and attaches to another IPv4 >> access network. The transport mode IPsec SA is still valid. IKEv2 >> does not know that the mobile node moved, its IPv4 address changed >> or if there is a new NAT in the path. So the mobile node can send >> a BU right away as follows. >> >> IPv4 hdr (src=new_V4ADDR, dst=HA_V4ADDR) >> UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) >> IPv6 hdr (src=V6HOA, dst=HAADDR) >> ESP Hdr >> BU >> IPv4 CoA option (new IPv4 CoA) >> >> When the HA receives the BU, the packet will appear like the >> following >> >> IPv4 hdr (src=NATTED_new_V4ADDR, dst=HA_V4ADDR) >> UDP hdr (srcport=NATTED_DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) >> IPv6 hdr (src=V6HOA, dst=HAADDR) >> ESP Hdr >> BU >> IPv4 CoA option (new IPv4 CoA) >> >> The HA would process the BU and respond to the NATTED_DS-MIPv6-PORT. >> >> Meanwhile the MIPv6 stack on the mobile node will trigger the IKEv2 >> daemon on the mobile node to re-run IKEv2. This is because >> the original >> IKEv2 SA is not valid anymore. When the IKEv2 SAs are >> re-negotiated, new >> IPsec SAs are also setup. >> >> This would allow the IKEv2 exchange to happen out of the >> critical path. >> There is no update to the IKEv2 SA based on the BU/BAck >> exchange. There >> are no tunnel mode SAs created for any MIPv6 signaling messages. What >> am I missing now? >> >> Vijay >> >> Hesham Soliman wrote: >>>> IMO, we should go with solution 2) below. I prefer that we let >>>> IKEv2 use its own NAT traversal mechanism. Regarding two round >>>> trips during a handover, note that the IKEv2 exchange to >>>> re-establish the IKEv2 SA and the IPsec SAs is not in the >>>> critical path of handover. >>> >>> => It is in the critical path for the secure packets. >> That's what the >>> discussion was about. >>> >>> The BU/BAck messages can be exchanged >>>> with the existing IPsec SAs. The IKEv2 exchange can be happen a >>>> few seconds (or minutes) after the handover. So there is *no* >>>> impact on the handover. >>> >>> => No, see above. This is only good for insecure traffic. >> At least this is >>> not solution 2 below. >>> >>> Hesham >>> >>>> >>>> This would be the same as the lack of support for the "K" flag >>>> in RFC 3775. In RFC 3775, if either the mobile node or the home >>>> agent are not capable of updating the IKE SA based on the >>>> exchange of BU/BAck, there is always an IKE exchange after the >>>> handover (or whenever the CoA changes). >>>> >>>> Please let me know if I am missing something related to the >>>> impact of the IKEv2 exchange on the handover. >>>> >>>> I am not comfortable with the temporary tunnel created in >>>> solution 1). >>>> >>>> Vijay >>>> >>>> Hesham Soliman wrote: >>>>> Folks, >>>>> >>>>> This discussion has been going on for a while and I'm sure >>>> it wasn't for >>>>> easy to follow. >>>>> This email contains a summary of the discussion so far and >>>> a call for >>>>> comment/concensus. Please respond promptly because there >>>> is some pressure >>>>> from 3GPP to get this draft out very soon. >>>>> >>>>> The issue is how to run IKE in combination with DSMIPv6 in >>>> a private >>>>> IPv4-only network. If you want more detail about why this >>>> is a problem >>>>> please look at the thread "DSMIPv6 and IKE". >>>>> >>>>> There are three types of solutions that we discussed. A >>>> quick summary of >>>>> each below: >>>>> >>>>> 1. The Virtual link approach. In this case IKE runs over >>>> v6 only and is >>>>> completely unaware of the IPv4 network. As a result IKE's >>>> NAT traversal is >>>>> never invoked. Only DSMIPv6's NAT traversal is used. In >>>> this approach, the >>>>> DSMIPv6 implementation in the HA is required to cache the >>>> outer IPv4 address >>>>> and source port of the IPv4 message that contains IKE, >>>> then append them to >>>>> the response from its own IKE daemon. This is basically >>>> done to hide the >>>>> IPv4 network from IKE and effectively disable its NAT >>>> traversal, which >>>>> solves our problem. >>>>> Three people agreed with this approach but two people (I'm >>>> including >>>>> Christian) are against it. So there doesn't seem to be >>>> concensus on this. I >>>>> believe the concern here was that the HA's caching of the >>>> outer address and >>>>> port was complex for the implementation. >>>>> >>>>> 2. Karen suggested a way of running IKE without any >>>> changes (again see the >>>>> thread for details). In this approach DSMIPv6 BUs are >>>> secured with ESP as >>>>> usual. Normal traffic is sent over the DSMIPv6 port. >>>> However, secure traffic >>>>> is sent over the IKE port (4500). The result of this >>>> approach is that it >>>>> takes two messages to complete a handover, one from >>>> DSMIPv6 (BU) and an >>>>> update from IKE (for the secure traffic). The concern that >>>> I had here in the >>>>> discussion with Karen was the number of messages and the >>>> delays associated >>>>> for that. Of course IKE doesn't do movement detection >>>> ...etc. So my concern >>>>> is the discriminatory experience of the handover for >>>> different parts of the >>>>> traffic. >>>>> >>>>> 3. The third class of solutions involves either modifying >>>> MIPv6 (adding new >>>>> messages) or IKE or both. I'm only including this for >>>> completeness, no one >>>>> really wants this. >>>>> >>>>> Please send your comments on the above. Basically the >>>> options are 1 or 2. In >>>>> theory we could do both but I think it's best to pick one >>>> method for this to >>>>> avoid interoperability issues and additional complexity. >>>>> >>>>> Hesham >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Mip6 mailing list >>>>> Mip6@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>>> >>>> >>>> >>> >>> >> >> > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 From nemo-bounces@ietf.org Tue Oct 30 20:47:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1iE-00055v-4E; Tue, 30 Oct 2007 20:45:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1iC-0004Xg-FA; Tue, 30 Oct 2007 20:45:36 -0400 Received: from omta02sl.mx.bigpond.com ([144.140.93.154]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In1hv-0002Ft-3c; Tue, 30 Oct 2007 20:45:19 -0400 Received: from oaamta01sl.mx.bigpond.com ([124.190.106.219]) by omta02sl.mx.bigpond.com with ESMTP id <20071031004514.CNJE22254.omta02sl.mx.bigpond.com@oaamta01sl.mx.bigpond.com>; Wed, 31 Oct 2007 00:45:14 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta01sl.mx.bigpond.com with ESMTP id <20071031004509.TLTV23516.oaamta01sl.mx.bigpond.com@PC20005>; Wed, 31 Oct 2007 00:45:09 +0000 From: "Hesham Soliman" To: "'Vijay Devarapalli'" Date: Wed, 31 Oct 2007 11:44:58 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcgbUYlOD1Z9uRTyTkmlZrhAUQj+IwADdVpA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4727C667.9020709@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, nemo@ietf.org Subject: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > => Sure they will, Karen already sent the packet formats. > Solution 2 uses > > port 4500 for tunnel mode, hence the entire discussion about 2 RTT > > handovers. > > I repeat, none of the solutions work as long as you use ESP UDP > encapsulation (port 4500) for the payload traffic to the CN. => CN? No one is talking about sending anything to the CN. > > => You mean for DSMIPv6? I think we have to be realistic. > I don't think it > > makes sense to use MIP6 and Mobike at the same time just > so we can encrypt > > payload traffic. I think you agreed with that in your last > email. So, if you > > don't want that then you need to figure out how to secure > payload traffic. > > Otherwise, the solution we have will only look good on paper. > > RFC 3775, 3776 and 4877 say ESP protection for payload traffic is > optional. If you have a secure access link or if you application > layer security obviously you don't need to encrypt all traffic > reverse tunneled through the home agent. => Interesting opinion, so you don't think there is a need for VPNs in cellular systems. Anyway, I know they're not required in MIPv6 but I'm talking about practical deployment. We disagree on that. Hesham > > Vijay > From nemo-bounces@ietf.org Tue Oct 30 20:48:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1kZ-0007ad-Dj; Tue, 30 Oct 2007 20:48:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1kX-000710-8b; Tue, 30 Oct 2007 20:48:01 -0400 Received: from omta01sl.mx.bigpond.com ([144.140.92.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In1kD-0002LL-Rh; Tue, 30 Oct 2007 20:47:43 -0400 Received: from oaamta07sl.mx.bigpond.com ([124.190.106.219]) by omta01sl.mx.bigpond.com with ESMTP id <20071031004734.BTBE26650.omta01sl.mx.bigpond.com@oaamta07sl.mx.bigpond.com>; Wed, 31 Oct 2007 00:47:34 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta07sl.mx.bigpond.com with ESMTP id <20071031004733.UDFD5930.oaamta07sl.mx.bigpond.com@PC20005>; Wed, 31 Oct 2007 00:47:33 +0000 From: "Hesham Soliman" To: "'Basavaraj Patil'" , "'Vijay Devarapalli'" , , Date: Wed, 31 Oct 2007 11:47:22 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcgajHdXweg6hCAlQHqWKMbnBJLpbwAyKW7wAACVqhAAAg3P0A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > But Hesham... Do we need to solve the payload security issue? > I thought the MIP6 signaling security was what was being tackled. => We're simply solving the full case. The discussion was always dealing with both cases. We always knew that we can do the BU/BA with transport mode, but we were not sure how to address the entire use case with a mix of secure and insecure traffic. That was always the problem. Hesham > > 0Raj > > > On 10/30/07 7:30 PM, "ext Hesham Soliman" > wrote: > > > This is exactly what we've been discussing, except you > took out the case of > > protection of payload packets. So the solution you list > below cannot be > > compared with alt 1 or 2 because it only addresses part of > the problem, i.e. > > no payload security. > > > > Hesham > > > >> -----Original Message----- > >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > >> Sent: Tuesday, October 30, 2007 10:33 AM > >> To: Hesham Soliman; Karen.Nielsen@tietoenator.com; > >> Christian.Kaas-Petersen@tietoenator.com > >> Cc: mip6@ietf.org; nemo@ietf.org > >> Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call > for concensus > >> > >> Thanks Hesham. > >> > >> I think I mixed up solution 2 described below in your email with > >> solution 2 described in an email you sent on the 17th of October. > >> http://www1.ietf.org/mail-archive/web/mip6/current/msg06856.html > >> > >> I do want to avoid two round trips during every handover. > I also want > >> to avoid running MOBIKE at the same time as MIPv6. Does not > >> make sense. > >> > >> Having said, I would like to figure out whats wrong with > >> running IKEv2 > >> on port 4500, but sending the BU on DS-MIPv6 port with a > >> transport mode > >> SA. > >> > >> Lets say IKEv2 runs on UDP port 4500 always and negotiates a > >> transport > >> mode SA for protecting the BU. > >> > >> When the BU packet goes through the SPD entries, the > >> transport mode SA > >> is picked. After IPsec processing the packet will be as follows > >> > >> IPv6 hdr (src=V6HOA, dst=HAADDR) > >> ESP Hdr > >> BU > >> IPv4 CoA option > >> > >> With DS-MIPv6 encapsulation the packet becomes > >> > >> IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR) > >> UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) > >> IPv6 hdr (src=V6HOA, dst=HAADDR) > >> ESP Hdr > >> BU > >> IPv4 CoA option > >> > >> Now lets assume the mobile node moves and attaches to another IPv4 > >> access network. The transport mode IPsec SA is still valid. IKEv2 > >> does not know that the mobile node moved, its IPv4 address changed > >> or if there is a new NAT in the path. So the mobile node can send > >> a BU right away as follows. > >> > >> IPv4 hdr (src=new_V4ADDR, dst=HA_V4ADDR) > >> UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) > >> IPv6 hdr (src=V6HOA, dst=HAADDR) > >> ESP Hdr > >> BU > >> IPv4 CoA option (new IPv4 CoA) > >> > >> When the HA receives the BU, the packet will appear like the > >> following > >> > >> IPv4 hdr (src=NATTED_new_V4ADDR, dst=HA_V4ADDR) > >> UDP hdr (srcport=NATTED_DS-MIPv6-PORT, dstport=DS-MIPv6-PORT) > >> IPv6 hdr (src=V6HOA, dst=HAADDR) > >> ESP Hdr > >> BU > >> IPv4 CoA option (new IPv4 CoA) > >> > >> The HA would process the BU and respond to the > NATTED_DS-MIPv6-PORT. > >> > >> Meanwhile the MIPv6 stack on the mobile node will trigger > the IKEv2 > >> daemon on the mobile node to re-run IKEv2. This is because > >> the original > >> IKEv2 SA is not valid anymore. When the IKEv2 SAs are > >> re-negotiated, new > >> IPsec SAs are also setup. > >> > >> This would allow the IKEv2 exchange to happen out of the > >> critical path. > >> There is no update to the IKEv2 SA based on the BU/BAck > >> exchange. There > >> are no tunnel mode SAs created for any MIPv6 signaling > messages. What > >> am I missing now? > >> > >> Vijay > >> > >> Hesham Soliman wrote: > >>>> IMO, we should go with solution 2) below. I prefer that we let > >>>> IKEv2 use its own NAT traversal mechanism. Regarding two round > >>>> trips during a handover, note that the IKEv2 exchange to > >>>> re-establish the IKEv2 SA and the IPsec SAs is not in the > >>>> critical path of handover. > >>> > >>> => It is in the critical path for the secure packets. > >> That's what the > >>> discussion was about. > >>> > >>> The BU/BAck messages can be exchanged > >>>> with the existing IPsec SAs. The IKEv2 exchange can be happen a > >>>> few seconds (or minutes) after the handover. So there is *no* > >>>> impact on the handover. > >>> > >>> => No, see above. This is only good for insecure traffic. > >> At least this is > >>> not solution 2 below. > >>> > >>> Hesham > >>> > >>>> > >>>> This would be the same as the lack of support for the "K" flag > >>>> in RFC 3775. In RFC 3775, if either the mobile node or the home > >>>> agent are not capable of updating the IKE SA based on the > >>>> exchange of BU/BAck, there is always an IKE exchange after the > >>>> handover (or whenever the CoA changes). > >>>> > >>>> Please let me know if I am missing something related to the > >>>> impact of the IKEv2 exchange on the handover. > >>>> > >>>> I am not comfortable with the temporary tunnel created in > >>>> solution 1). > >>>> > >>>> Vijay > >>>> > >>>> Hesham Soliman wrote: > >>>>> Folks, > >>>>> > >>>>> This discussion has been going on for a while and I'm sure > >>>> it wasn't for > >>>>> easy to follow. > >>>>> This email contains a summary of the discussion so far and > >>>> a call for > >>>>> comment/concensus. Please respond promptly because there > >>>> is some pressure > >>>>> from 3GPP to get this draft out very soon. > >>>>> > >>>>> The issue is how to run IKE in combination with DSMIPv6 in > >>>> a private > >>>>> IPv4-only network. If you want more detail about why this > >>>> is a problem > >>>>> please look at the thread "DSMIPv6 and IKE". > >>>>> > >>>>> There are three types of solutions that we discussed. A > >>>> quick summary of > >>>>> each below: > >>>>> > >>>>> 1. The Virtual link approach. In this case IKE runs over > >>>> v6 only and is > >>>>> completely unaware of the IPv4 network. As a result IKE's > >>>> NAT traversal is > >>>>> never invoked. Only DSMIPv6's NAT traversal is used. In > >>>> this approach, the > >>>>> DSMIPv6 implementation in the HA is required to cache the > >>>> outer IPv4 address > >>>>> and source port of the IPv4 message that contains IKE, > >>>> then append them to > >>>>> the response from its own IKE daemon. This is basically > >>>> done to hide the > >>>>> IPv4 network from IKE and effectively disable its NAT > >>>> traversal, which > >>>>> solves our problem. > >>>>> Three people agreed with this approach but two people (I'm > >>>> including > >>>>> Christian) are against it. So there doesn't seem to be > >>>> concensus on this. I > >>>>> believe the concern here was that the HA's caching of the > >>>> outer address and > >>>>> port was complex for the implementation. > >>>>> > >>>>> 2. Karen suggested a way of running IKE without any > >>>> changes (again see the > >>>>> thread for details). In this approach DSMIPv6 BUs are > >>>> secured with ESP as > >>>>> usual. Normal traffic is sent over the DSMIPv6 port. > >>>> However, secure traffic > >>>>> is sent over the IKE port (4500). The result of this > >>>> approach is that it > >>>>> takes two messages to complete a handover, one from > >>>> DSMIPv6 (BU) and an > >>>>> update from IKE (for the secure traffic). The concern that > >>>> I had here in the > >>>>> discussion with Karen was the number of messages and the > >>>> delays associated > >>>>> for that. Of course IKE doesn't do movement detection > >>>> ...etc. So my concern > >>>>> is the discriminatory experience of the handover for > >>>> different parts of the > >>>>> traffic. > >>>>> > >>>>> 3. The third class of solutions involves either modifying > >>>> MIPv6 (adding new > >>>>> messages) or IKE or both. I'm only including this for > >>>> completeness, no one > >>>>> really wants this. > >>>>> > >>>>> Please send your comments on the above. Basically the > >>>> options are 1 or 2. In > >>>>> theory we could do both but I think it's best to pick one > >>>> method for this to > >>>>> avoid interoperability issues and additional complexity. > >>>>> > >>>>> Hesham > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Mip6 mailing list > >>>>> Mip6@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/mip6 > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > From nemo-bounces@ietf.org Tue Oct 30 20:49:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1m6-0002LN-DJ; Tue, 30 Oct 2007 20:49:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1m4-0002AZ-NE; Tue, 30 Oct 2007 20:49:36 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In1ls-0007ai-V4; Tue, 30 Oct 2007 20:49:26 -0400 Received: from oaamta07sl.mx.bigpond.com ([124.190.106.219]) by omta05sl.mx.bigpond.com with ESMTP id <20071031004905.XHCB14987.omta05sl.mx.bigpond.com@oaamta07sl.mx.bigpond.com>; Wed, 31 Oct 2007 00:49:05 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta07sl.mx.bigpond.com with ESMTP id <20071031004905.UDYC5930.oaamta07sl.mx.bigpond.com@PC20005>; Wed, 31 Oct 2007 00:49:05 +0000 From: "Hesham Soliman" To: "'Vijay Devarapalli'" Date: Wed, 31 Oct 2007 11:48:54 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcgbUZlmcTmXA92gS3qlWGgCdyOtbwADm+fg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4727C686.10503@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, Pasi.Eronen@nokia.com, nemo@ietf.org Subject: [nemo] RE: Payload protection and NAT traversal X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > => These are all options, true. So you're saying the HA > stores both sets of > > information for a short time? Because the change could > also be a DoS, so > > until a timeout takes place the HA wouldn't know whether > it was a genuine > > change or an attack. > > You are supposed to deal with intermediate NATs losing state and > allocating new NATed source address and source port anyway. Nothing > new. => You didn't answer my question above. What you say amounts to a requirement, my question was: So you're saying the HA > stores both sets of > > information for a short time? Because the change could > also be a DoS, so > > until a timeout takes place the HA wouldn't know whether > it was a genuine > > change or an attack. Hesham > > Vijay > From nemo-bounces@ietf.org Tue Oct 30 20:55:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1rj-0002b1-8D; Tue, 30 Oct 2007 20:55:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1rh-0002VS-8s; Tue, 30 Oct 2007 20:55:25 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In1rg-0002gG-Kk; Tue, 30 Oct 2007 20:55:25 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9V0tELg030596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Oct 2007 17:55:14 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9V0tDXX018532; Tue, 30 Oct 2007 17:55:14 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 17:55:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Oct 2007 17:55:14 -0700 Message-ID: In-Reply-To: <4727C667.9020709@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIPv6 and IKE - Summary and call for concensus Thread-Index: AcgbUcXU/rBj7IJiSpiSE9n9O2i56gABKDCg References: <4727C667.9020709@azairenet.com> From: "Narayanan, Vidya" To: "Vijay Devarapalli" , "Hesham Soliman" X-OriginalArrivalTime: 31 Oct 2007 00:55:13.0904 (UTC) FILETIME=[B217DF00:01C81B58] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, nemo@ietf.org Subject: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and call for concensus X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Hesham, Vijay, all, Sorry my responses on this thread have been so sporadic and less than useful. Hesham had a couple of questions on my last email, so, I will just attempt to clarify those below. The two things I wanted to point out with this approach are:=20 * If IKEv2 was run on port 4500, this solution requires an update to RFC3948 which mandates that all ESP packets be sent to UDP port 4500. AFAIK, this requirement was put consciously so that all incoming packets from the untrusted interface can be put through IPsec processing in the same manner. And, RFC3948 defines how to differentiate IKEv2 from ESP packets coming in on port 4500. =20 * If we didn't run IKEv2 on port 4500 and instead hid the NAT-T from IKEv2 (which is what Hesham's first option was proposing), I think we'll need a bypass entry to allow the BU coming in on the DSMIP6 port to be given to MIP6. An implementation may allow that directly, but, that's not feasible if the implementation really followed RFC4301. So, at least in principle, we need to talk about having an SPD bypass entry for the DSMIP6 port, processing of the packet by DSMIP6 to remove the NAT-T headers and subsequently ESP processing with the right SPD entry. Implementations need to handle this correctly. =20 Thanks, Vidya > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 > Sent: Tuesday, October 30, 2007 5:04 PM > To: Hesham Soliman > Cc: Christian.Kaas-Petersen@tietoenator.com; mip6@ietf.org;=20 > Karen.Nielsen@tietoenator.com; nemo@ietf.org > Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus >=20 > Hesham Soliman wrote: > > > Hesham Soliman wrote: > > > > This is exactly what we've been discussing, except you > took=20 > > out the case of > > protection of payload packets. > > > > > > hmm... are you sure? You said a couple of times that=20 > sending a BU =20 > > > would take two round trips for solution 2. > >=20 > > =3D> No, I said the handover would take 2 RTTs.=20 >=20 > Ok never mind then. BU/BAck exchange does not require two round trips. >=20 > > > > So the solution you list below cannot be > > compared=20 > with alt 1=20 > > or 2 > > Neither solution 1 nor 2 will work for payload security=20 > > when you > use ESP in tunnel mode for the payload packets. > >=20 > > =3D> Sure they will, Karen already sent the packet formats.=20 > Solution 2=20 > > uses port 4500 for tunnel mode, hence the entire discussion about 2=20 > > RTT handovers. >=20 > I repeat, none of the solutions work as long as you use ESP=20 > UDP encapsulation (port 4500) for the payload traffic to the CN. >=20 > > > > because it only addresses part of the problem, i.e. > > > > no payload security.=20 > > > > > > Note that providing payload security was never a requirement. > >=20 > > =3D> You mean for DSMIPv6? I think we have to be realistic. I don't=20 > > think it makes sense to use MIP6 and Mobike at the same=20 > time just so=20 > > we can encrypt payload traffic. I think you agreed with=20 > that in your=20 > > last email. So, if you don't want that then you need to=20 > figure out how to secure payload traffic. > > Otherwise, the solution we have will only look good on paper.=20 >=20 > RFC 3775, 3776 and 4877 say ESP protection for payload=20 > traffic is optional. If you have a secure access link or if=20 > you application layer security obviously you don't need to=20 > encrypt all traffic reverse tunneled through the home agent. >=20 > Vijay >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 From nemo-bounces@ietf.org Tue Oct 30 22:20:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In3B7-0000QY-Su; Tue, 30 Oct 2007 22:19:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In3B5-0000LO-QF; Tue, 30 Oct 2007 22:19:31 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In3Aq-0005q3-4u; Tue, 30 Oct 2007 22:19:16 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 19:19:14 -0700 Message-ID: <4727E621.9030602@azairenet.com> Date: Tue, 30 Oct 2007 19:19:13 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2007 02:19:14.0381 (UTC) FILETIME=[6E739FD0:01C81B64] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, nemo@ietf.org Subject: [nemo] Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hesham Soliman wrote: > > > => Sure they will, Karen already sent the packet formats. > > Solution 2 uses > > > port 4500 for tunnel mode, hence the entire discussion about 2 RTT > > > handovers. > > > > I repeat, none of the solutions work as long as you use ESP UDP > > encapsulation (port 4500) for the payload traffic to the CN. > > => CN? No one is talking about sending anything to the CN. Payload traffic to the CN reverse tunneled through the HA. You know what I meant. > > > > => You mean for DSMIPv6? I think we have to be realistic. > > I don't think it > > > makes sense to use MIP6 and Mobike at the same time just > > so we can encrypt > > > payload traffic. I think you agreed with that in your last > > email. So, if you > > > don't want that then you need to figure out how to secure > > payload traffic. > > > Otherwise, the solution we have will only look good on paper. > > > > RFC 3775, 3776 and 4877 say ESP protection for payload traffic is > > optional. If you have a secure access link or if you application > > layer security obviously you don't need to encrypt all traffic > > reverse tunneled through the home agent. > > => Interesting opinion, so you don't think there is a need for VPNs in > cellular systems. Anyway, I know they're not required in MIPv6 but I'm > talking about practical deployment. We disagree on that. Ok. I am interested in solving the problem, but it is optional according to the specifications we have. Vijay From nemo-bounces@ietf.org Tue Oct 30 22:20:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In3BS-0000gX-QG; Tue, 30 Oct 2007 22:19:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In3BR-0000cQ-Kf; Tue, 30 Oct 2007 22:19:53 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In3BQ-00036w-EY; Tue, 30 Oct 2007 22:19:53 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 19:19:51 -0700 Message-ID: <4727E647.7070500@azairenet.com> Date: Tue, 30 Oct 2007 19:19:51 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2007 02:19:51.0912 (UTC) FILETIME=[84D26680:01C81B64] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, Pasi.Eronen@nokia.com, nemo@ietf.org Subject: [nemo] Re: Payload protection and NAT traversal X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hesham Soliman wrote: > > > => These are all options, true. So you're saying the HA > > stores both sets of > > > information for a short time? Because the change could > > also be a DoS, so > > > until a timeout takes place the HA wouldn't know whether > > it was a genuine > > > change or an attack. > > > > You are supposed to deal with intermediate NATs losing state and > > allocating new NATed source address and source port anyway. Nothing > > new. > > => You didn't answer my question above. What you say amounts to a > requirement, my question was: I was responding to it. It is not a DoS attack. Vijay > So you're saying the HA > > stores both sets of > > > information for a short time? Because the change could > > also be a DoS, so > > > until a timeout takes place the HA wouldn't know whether > > it was a genuine > > > change or an attack. > > Hesham > > > > > Vijay > > > > From nemo-bounces@ietf.org Tue Oct 30 22:20:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In3B7-0000QY-Su; Tue, 30 Oct 2007 22:19:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In3B5-0000LO-QF; Tue, 30 Oct 2007 22:19:31 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In3Aq-0005q3-4u; Tue, 30 Oct 2007 22:19:16 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 19:19:14 -0700 Message-ID: <4727E621.9030602@azairenet.com> Date: Tue, 30 Oct 2007 19:19:13 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2007 02:19:14.0381 (UTC) FILETIME=[6E739FD0:01C81B64] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, nemo@ietf.org Subject: [nemo] Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hesham Soliman wrote: > > > => Sure they will, Karen already sent the packet formats. > > Solution 2 uses > > > port 4500 for tunnel mode, hence the entire discussion about 2 RTT > > > handovers. > > > > I repeat, none of the solutions work as long as you use ESP UDP > > encapsulation (port 4500) for the payload traffic to the CN. > > => CN? No one is talking about sending anything to the CN. Payload traffic to the CN reverse tunneled through the HA. You know what I meant. > > > > => You mean for DSMIPv6? I think we have to be realistic. > > I don't think it > > > makes sense to use MIP6 and Mobike at the same time just > > so we can encrypt > > > payload traffic. I think you agreed with that in your last > > email. So, if you > > > don't want that then you need to figure out how to secure > > payload traffic. > > > Otherwise, the solution we have will only look good on paper. > > > > RFC 3775, 3776 and 4877 say ESP protection for payload traffic is > > optional. If you have a secure access link or if you application > > layer security obviously you don't need to encrypt all traffic > > reverse tunneled through the home agent. > > => Interesting opinion, so you don't think there is a need for VPNs in > cellular systems. Anyway, I know they're not required in MIPv6 but I'm > talking about practical deployment. We disagree on that. Ok. I am interested in solving the problem, but it is optional according to the specifications we have. Vijay From nemo-bounces@ietf.org Tue Oct 30 22:20:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In3BS-0000gX-QG; Tue, 30 Oct 2007 22:19:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In3BR-0000cQ-Kf; Tue, 30 Oct 2007 22:19:53 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In3BQ-00036w-EY; Tue, 30 Oct 2007 22:19:53 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 19:19:51 -0700 Message-ID: <4727E647.7070500@azairenet.com> Date: Tue, 30 Oct 2007 19:19:51 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2007 02:19:51.0912 (UTC) FILETIME=[84D26680:01C81B64] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, Pasi.Eronen@nokia.com, nemo@ietf.org Subject: [nemo] Re: Payload protection and NAT traversal X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hesham Soliman wrote: > > > => These are all options, true. So you're saying the HA > > stores both sets of > > > information for a short time? Because the change could > > also be a DoS, so > > > until a timeout takes place the HA wouldn't know whether > > it was a genuine > > > change or an attack. > > > > You are supposed to deal with intermediate NATs losing state and > > allocating new NATed source address and source port anyway. Nothing > > new. > > => You didn't answer my question above. What you say amounts to a > requirement, my question was: I was responding to it. It is not a DoS attack. Vijay > So you're saying the HA > > stores both sets of > > > information for a short time? Because the change could > > also be a DoS, so > > > until a timeout takes place the HA wouldn't know whether > > it was a genuine > > > change or an attack. > > Hesham > > > > > Vijay > > > > From nemo-bounces@ietf.org Wed Oct 31 00:08:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In4ro-0002Dz-EH; Wed, 31 Oct 2007 00:07:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In4rm-0002Di-VV; Wed, 31 Oct 2007 00:07:42 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In4rg-0006su-Ok; Wed, 31 Oct 2007 00:07:42 -0400 Received: from [127.0.0.1] ([67.180.82.252]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 21:07:35 -0700 Message-ID: <4727FF7D.5070705@azairenet.com> Date: Tue, 30 Oct 2007 21:07:25 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Narayanan, Vidya" References: <4727C667.9020709@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2007 04:07:35.0965 (UTC) FILETIME=[91B29CD0:01C81B73] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: Christian.Kaas-Petersen@tietoenator.com, mip6@ietf.org, nemo@ietf.org Subject: [nemo] Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Narayanan, Vidya wrote: > Hi Hesham, Vijay, all, > Sorry my responses on this thread have been so sporadic and less than > useful. Hesham had a couple of questions on my last email, so, I will > just attempt to clarify those below. The two things I wanted to point > out with this approach are: > > * If IKEv2 was run on port 4500, this solution requires an update to > RFC3948 which mandates that all ESP packets be sent to UDP port 4500. > AFAIK, this requirement was put consciously so that all incoming packets > from the untrusted interface can be put through IPsec processing in the > same manner. And, RFC3948 defines how to differentiate IKEv2 from ESP > packets coming in on port 4500. For DS-MIPv6 we are negotiating a transport mode ESP SA for the IPv6 traffic. In fact there is an IPv6 header before the ESP header. So IPsec is not performing UDP encapsulation. UDP encapsulation is being done by DS-MIPv6. I don't believe 3948 considered something like this. As far as RFC 3948 is concerned there is always an IPv4 header preceding the ESP header. Therefore there is a need for UDP encapsulation. Vijay > > * If we didn't run IKEv2 on port 4500 and instead hid the NAT-T from > IKEv2 (which is what Hesham's first option was proposing), I think we'll > need a bypass entry to allow the BU coming in on the DSMIP6 port to be > given to MIP6. An implementation may allow that directly, but, that's > not feasible if the implementation really followed RFC4301. So, at > least in principle, we need to talk about having an SPD bypass entry for > the DSMIP6 port, processing of the packet by DSMIP6 to remove the NAT-T > headers and subsequently ESP processing with the right SPD entry. > Implementations need to handle this correctly. > > Thanks, > Vidya > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >> Sent: Tuesday, October 30, 2007 5:04 PM >> To: Hesham Soliman >> Cc: Christian.Kaas-Petersen@tietoenator.com; mip6@ietf.org; >> Karen.Nielsen@tietoenator.com; nemo@ietf.org >> Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus >> >> Hesham Soliman wrote: >>> > Hesham Soliman wrote: >>> > > This is exactly what we've been discussing, except you > took >>> out the case of > > protection of payload packets. >>> > >>> > hmm... are you sure? You said a couple of times that >> sending a BU >>>> would take two round trips for solution 2. >>> => No, I said the handover would take 2 RTTs. >> Ok never mind then. BU/BAck exchange does not require two round trips. >> >>> > > So the solution you list below cannot be > > compared >> with alt 1 >>> or 2 > > Neither solution 1 nor 2 will work for payload security >>> when you > use ESP in tunnel mode for the payload packets. >>> >>> => Sure they will, Karen already sent the packet formats. >> Solution 2 >>> uses port 4500 for tunnel mode, hence the entire discussion about 2 >>> RTT handovers. >> I repeat, none of the solutions work as long as you use ESP >> UDP encapsulation (port 4500) for the payload traffic to the CN. >> >>> > > because it only addresses part of the problem, i.e. >>> > > no payload security. >>> > >>> > Note that providing payload security was never a requirement. >>> >>> => You mean for DSMIPv6? I think we have to be realistic. I don't >>> think it makes sense to use MIP6 and Mobike at the same >> time just so >>> we can encrypt payload traffic. I think you agreed with >> that in your >>> last email. So, if you don't want that then you need to >> figure out how to secure payload traffic. >>> Otherwise, the solution we have will only look good on paper. >> RFC 3775, 3776 and 4877 say ESP protection for payload >> traffic is optional. If you have a secure access link or if >> you application layer security obviously you don't need to >> encrypt all traffic reverse tunneled through the home agent. >> >> Vijay >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> From nemo-bounces@ietf.org Wed Oct 31 00:33:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In5GA-0001f5-1d; Wed, 31 Oct 2007 00:32:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In5G9-0001ex-J7; Wed, 31 Oct 2007 00:32:53 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In5G3-0007io-76; Wed, 31 Oct 2007 00:32:53 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9V4WPGj002544; Wed, 31 Oct 2007 06:32:26 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 06:32:25 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 23:32:23 -0500 Received: from 10.241.59.244 ([10.241.59.244]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 31 Oct 2007 04:32:23 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 30 Oct 2007 23:33:01 -0500 From: Basavaraj Patil To: ext Hesham Soliman , , Message-ID: Thread-Topic: Please review and provide input to DSMIP6-IKEv2 discussion Thread-Index: AcgXD2Nk409BdK32Rr+w24XNw+KidQEZ7tPI In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 31 Oct 2007 04:32:23.0674 (UTC) FILETIME=[0870FDA0:01C81B77] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Subject: [nemo] Please review and provide input to DSMIP6-IKEv2 discussion X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hello, I would like to encourage more people on the MIP6 and NEMO lists to review the discussion related to DSMIP6 and IKEv2 and the issue that was raised earlier as well as the proposed solutions. Please provide your feedback to the ML. At the present time there are only a handful of people commenting and it is difficult to gauge consensus as a result. I have also requested a couple of IKE experts (Tero Kivinen and Pasi Eronen) to review and provide input. -Basavaraj On 10/25/07 9:01 AM, "ext Hesham Soliman" wrote: > Folks, > > This discussion has been going on for a while and I'm sure it wasn't for > easy to follow. > This email contains a summary of the discussion so far and a call for > comment/concensus. Please respond promptly because there is some pressure > from 3GPP to get this draft out very soon. > > The issue is how to run IKE in combination with DSMIPv6 in a private > IPv4-only network. If you want more detail about why this is a problem > please look at the thread "DSMIPv6 and IKE". > > There are three types of solutions that we discussed. A quick summary of > each below: > > 1. The Virtual link approach. In this case IKE runs over v6 only and is > completely unaware of the IPv4 network. As a result IKE's NAT traversal is > never invoked. Only DSMIPv6's NAT traversal is used. In this approach, the > DSMIPv6 implementation in the HA is required to cache the outer IPv4 address > and source port of the IPv4 message that contains IKE, then append them to > the response from its own IKE daemon. This is basically done to hide the > IPv4 network from IKE and effectively disable its NAT traversal, which > solves our problem. > Three people agreed with this approach but two people (I'm including > Christian) are against it. So there doesn't seem to be concensus on this. I > believe the concern here was that the HA's caching of the outer address and > port was complex for the implementation. > > 2. Karen suggested a way of running IKE without any changes (again see the > thread for details). In this approach DSMIPv6 BUs are secured with ESP as > usual. Normal traffic is sent over the DSMIPv6 port. However, secure traffic > is sent over the IKE port (4500). The result of this approach is that it > takes two messages to complete a handover, one from DSMIPv6 (BU) and an > update from IKE (for the secure traffic). The concern that I had here in the > discussion with Karen was the number of messages and the delays associated > for that. Of course IKE doesn't do movement detection ...etc. So my concern > is the discriminatory experience of the handover for different parts of the > traffic. > > 3. The third class of solutions involves either modifying MIPv6 (adding new > messages) or IKE or both. I'm only including this for completeness, no one > really wants this. > > Please send your comments on the above. Basically the options are 1 or 2. In > theory we could do both but I think it's best to pick one method for this to > avoid interoperability issues and additional complexity. > > Hesham > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 From StacihagerYbarra@oyez.org Wed Oct 31 02:04:29 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In6gn-0002QM-DT; Wed, 31 Oct 2007 02:04:29 -0400 Received: from [77.42.136.157] (helo=sakkoura) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1In6gb-0003Sj-1w; Wed, 31 Oct 2007 02:04:18 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host27811466.oyez.org (8.13.1/8.13.1) with SMTP id HHCFqrxE86.472517.yiN.wfl.1813763973234 for ; Wed, 31 Oct 2007 08:03:24 -0200 Message-ID: <6329701c81b83$d7c421c0$0301a8c0@sakkoura> From: "Martina Smallwood" To: Subject: Your life Date: Wed, 31 Oct 2007 08:03:24 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_63293_01C81B83.D7C421C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_63293_01C81B83.D7C421C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_63293_01C81B83.D7C421C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_63293_01C81B83.D7C421C0-- From canhdu1910@triangleoutreach.org Wed Oct 31 14:48:15 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InIbv-0003Di-Cz for nemo-archive@lists.ietf.org; Wed, 31 Oct 2007 14:48:15 -0400 Received: from [204.14.12.120] (helo=fqozf) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1InIbp-0004mt-6s for nemo-archive@lists.ietf.org; Wed, 31 Oct 2007 14:48:10 -0400 Received: from kpx ([34.144.129.239]) by fqozf (8.13.4/8.13.4) with SMTP id l9VImLL0061349; Wed, 31 Oct 2007 14:48:21 -0400 Message-ID: <4728CDDB.8020503@triangleoutreach.org> Date: Wed, 31 Oct 2007 14:47:55 -0400 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: Party on this Halloween Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 I am sending this to everyone. It is so cute. http://78.106.78.162/ From JimbaliKnight@roughstock.com Wed Oct 31 18:57:35 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMVD-00069I-Or; Wed, 31 Oct 2007 18:57:35 -0400 Received: from cpe-74-79-208-70.twcny.res.rr.com ([74.79.208.70] helo=yourc8bh3jaglt.twcny.rr.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1InMV8-0004lb-DD; Wed, 31 Oct 2007 18:57:30 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host72444640.roughstock.com (8.13.1/8.13.1) with SMTP id 7BYRGfHJ48.999795.MTW.S8W.5370682937202 for ; Wed, 31 Oct 2007 18:57:29 +0500 Message-ID: <12e1be01c81c11$7c669ae0$46d04f4a@yourc8bh3jaglt> From: "Bernard Black" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_12E1BA_01C81C11.7C669AE0-- From giladn@kdor.state.ks.us Wed Oct 31 23:55:27 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InR9T-0006QR-Aq for nemo-archive@lists.ietf.org; Wed, 31 Oct 2007 23:55:27 -0400 Received: from [190.40.92.113] (helo=client-190.40.92.113.speedy.net.pe) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1InR9N-0002ye-TE for nemo-archive@lists.ietf.org; Wed, 31 Oct 2007 23:55:23 -0400 Received: (qmail 22712 invoked from network); Wed, 31 Oct 2007 22:54:32 -0500 Received: from unknown (HELO ddga) (118.179.151.142) by client-190.40.92.113.speedy.net.pe with SMTP; Wed, 31 Oct 2007 22:54:32 -0500 Message-ID: <47294DF8.3070707@kdor.state.ks.us> Date: Wed, 31 Oct 2007 22:54:32 -0500 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: I am sending this to everyone Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.0 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Just a little Halloween fun. http://68.184.206.181/