From jari.arkko@lmf.ericsson.se Wed Apr 2 02:18:02 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16242 for ; Wed, 2 Apr 2003 02:17:59 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h327Gkrs018724; Wed, 2 Apr 2003 09:16:46 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4KVHPF; Wed, 2 Apr 2003 09:16:47 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h327GjK25972; Wed, 2 Apr 2003 09:16:45 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h327GCYl021374; Wed, 2 Apr 2003 09:16:12 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h327GCUI021373; Wed, 2 Apr 2003 09:16:12 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from sina.com.cn ([218.20.60.80]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h327G6Ym021365 for ; Wed, 2 Apr 2003 09:16:09 +0200 (MET DST) Message-Id: <200304020716.h327G6Ym021365@sw.ericsson.se> From: =?GB2312?B?s8LWx8H6?= <777man@sina.com.cn> To: ietf-send@standards.ericsson.net Content-Type: text/plain;charset="GB2312" Reply-To: 777man@sina.com.cn Date: Wed, 2 Apr 2003 15:16:11 +0800 X-Priority: 3 X-Mailer: Foxmail 4.1 [cn] Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk 您好! 非常高兴能够与您联系, 我是上海广电应确信有限公司华南区渠道经理 陈智龙，我从一位朋友处得知您的E-MAIL 地址，冒昧给你写信，如果这封信给您带来不便，还请原谅！ 上海广电应确信有限公司由上海广电信息产业股份有限公司和美国领先的企业安全产品供应商Intrusion.com合作成立。向社会提供全系列的交换机和网络安全产品。其中Infinite Switch6000系列企业级智能交换机和U-Trust SC系列安全产品在全球同类产品中具有技术领先的优势，特别是U-Trust SC系列安全产品 内嵌了当今世界技术最领先的以色列CHECK POINT公司的防火墙产品,组合成高性能的网络安全硬件平台,充分应用在银行,电信,电力,社保,交通,能源,医疗等行业,公司还凭借自身强大的技术实力,研发出具有自主可控的国产防火墙SVA-SF(目前有超小型,百兆系列)产品,可以为各种类型的网络环境和各种行业的用户提供全面高性能的产品和解决方案,并成为2001年在上海举行的APEC会议指定的网络设备供应商。 　　广电应确信不但为智能化小区、电子政务,网上银行、网上证券交易、网上投保、军队提供从2层到4---7层的以太网交换机，还从企业信息安全体系的架构、咨询、风险的评估、安全漏洞的测试到整个网络的设计、安全策略的部署实施等提供安全的整套解决方案。 衷心希望我们将来能够有机会合作,您如果对技术上有什么疑问可以致电我们上海总部免费800电话查询: 800-8201122 或直接访问我公司的网站: www.svanetworks.com ,对于渠道政策的疑问可以直接与我联系, 并祝 工作愉快,身体健康! (广电应确信 安全应确信) 上海广电应确信有限公司广州办事处 网络安全产品部 陈智龙 广州市天河路351号广东外经贸大厦2022室 Tel:020-38819640，38819641 Fax:020-38819642 手机:13822194195 www.svanetworks.com E-MAIL: 777man@sina.com.cn -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Apr 4 13:04:56 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01413 for ; Fri, 4 Apr 2003 13:04:56 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h34I4VI3026806; Fri, 4 Apr 2003 20:04:31 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A40KD0Y; Fri, 4 Apr 2003 20:04:31 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h34I4T228969; Fri, 4 Apr 2003 20:04:29 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h34I3uYl021090; Fri, 4 Apr 2003 20:03:56 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h34I3uGn021089; Fri, 4 Apr 2003 20:03:56 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h34I3rYl021085 for ; Fri, 4 Apr 2003 20:03:54 +0200 (MET DST) Message-ID: <019901c2fad4$55029ac0$036015ac@T23KEMPF> From: "James Kempf" To: Subject: Separate WG Draft for CGAs? Date: Fri, 4 Apr 2003 10:02:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Folks, There was some interest expressed prior to and at the last meeting in SFO for separating out CGAs. The original reason was IPR considerations, but, from a practical standpoint, Tuomas Aurea has already done a very nice job of specifying a CGA algorithm in http://www.ietf.org/internet-drafts/draft-aura-cga-00.txt. Rather than have to edit Tuomas' text into the base SEND draft, Pekka and I thought it might be easier to make Tuomas' draft a WG draft and refer to it in the base draft. Any objections or other comments? jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Apr 4 13:52:17 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02471 for ; Fri, 4 Apr 2003 13:52:17 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h34IpDRs012457; Fri, 4 Apr 2003 20:51:13 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A40KMR2; Fri, 4 Apr 2003 20:51:14 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h34IpC200117; Fri, 4 Apr 2003 20:51:12 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h34IorYl026506; Fri, 4 Apr 2003 20:50:53 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h34IoraB026505; Fri, 4 Apr 2003 20:50:53 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h34IoqYl026501 for ; Fri, 4 Apr 2003 20:50:52 +0200 (MET DST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h34Iom611681; Fri, 4 Apr 2003 21:50:48 +0300 Date: Fri, 4 Apr 2003 21:50:48 +0300 (EEST) From: Pekka Savola To: James Kempf cc: ietf-send@standards.ericsson.net Subject: Re: Separate WG Draft for CGAs? In-Reply-To: <019901c2fad4$55029ac0$036015ac@T23KEMPF> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk On Fri, 4 Apr 2003, James Kempf wrote: > There was some interest expressed prior to and at the last meeting in SFO for > separating out CGAs. The original reason was IPR considerations, but, from a > practical standpoint, Tuomas Aurea has already done a very nice job of > specifying a CGA algorithm in > http://www.ietf.org/internet-drafts/draft-aura-cga-00.txt. Rather than have to > edit Tuomas' text into the base SEND draft, Pekka and I thought it might be > easier to make Tuomas' draft a WG draft and refer to it in the base draft. > > Any objections or other comments? The subject of CGA algorithm specification is largely orthogonal to the SEND protocol use of CGA. If IPR issues were to surface in CGA, it would have to be even more completely ripped out of the SEND protocol, IMHO. As such, a separate SEND algorithm document is probably useful but not necessarily as useful as one would hope if worse comes to worst. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Apr 4 15:05:15 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05507 for ; Fri, 4 Apr 2003 15:05:15 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h34K5cRs022170; Fri, 4 Apr 2003 22:05:39 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4S1B47; Fri, 4 Apr 2003 22:05:39 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h34K5X201644; Fri, 4 Apr 2003 22:05:33 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h34K4wYl005101; Fri, 4 Apr 2003 22:04:58 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h34K4wPu005100; Fri, 4 Apr 2003 22:04:58 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h34K4tYl005096 for ; Fri, 4 Apr 2003 22:04:56 +0200 (MET DST) Date: Fri, 04 Apr 2003 12:05:18 -0800 Subject: Re: Separate WG Draft for CGAs? From: Alper Yegin To: James Kempf , Message-ID: In-Reply-To: <019901c2fad4$55029ac0$036015ac@T23KEMPF> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > There was some interest expressed prior to and at the last meeting in SFO for > separating out CGAs. The original reason was IPR considerations, but, from a > practical standpoint, Tuomas Aurea has already done a very nice job of > specifying a CGA algorithm in > http://www.ietf.org/internet-drafts/draft-aura-cga-00.txt. Rather than have to > edit Tuomas' text into the base SEND draft, Pekka and I thought it might be > easier to make Tuomas' draft a WG draft and refer to it in the base draft. As I explained earlier, imo, there are more reasons to split the draft into pieces than the IPR issue. So, I'm all for a split. And here is my suggestion: - one draft that includes how CGAs work (i.e., Tuomas' draft) plus how they will be used with ND (i.e., half of current SEND draft) - one might further consider this as two separate drafts. Well, if we believe that CGAs will be used for other purposes in the future, it makes sense to have this separate as well. - another draft on how to secure router discovery (i.e., the other half of SEND draft) alper -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Apr 7 12:08:42 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24867 for ; Mon, 7 Apr 2003 12:08:41 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h37G5oRs024874; Mon, 7 Apr 2003 18:05:50 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4093HW; Mon, 7 Apr 2003 18:05:51 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h37G5j227934; Mon, 7 Apr 2003 18:05:45 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h37G54Yl003131; Mon, 7 Apr 2003 18:05:04 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h37G54tu003130; Mon, 7 Apr 2003 18:05:04 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from web41811.mail.yahoo.com (web41811.mail.yahoo.com [66.218.93.145]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with SMTP id h37G52Yl003126 for ; Mon, 7 Apr 2003 18:05:02 +0200 (MET DST) Message-ID: <20030407160456.58817.qmail@web41811.mail.yahoo.com> Received: from [65.213.193.49] by web41811.mail.yahoo.com via HTTP; Mon, 07 Apr 2003 09:04:56 PDT Date: Mon, 7 Apr 2003 09:04:56 -0700 (PDT) From: CAITR Reply-To: info@caitr.org Subject: Internetworking 2003: Call for Papers To: ietf-send@standards.ericsson.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1193345935-1049731496=:58615" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk --0-1193345935-1049731496=:58615 Content-Type: text/plain; charset=us-ascii Call for Papers ============== Internetworking 2003, June 22-24, 2003, San Jose, California http://www.caitr.org/internetworking03/index.htm REMINDER: Deadline for submissions is April 11, 2003 The Internetworking 2003 Technical Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following: - Voice over IP (VoIP) - IP Video Conferencing - Storage Area Networks (SANs) - Unicast and Multicast Routing and Convergence - QoS Routing - Network Security and Service Integration - Operational Support Systems - Virtual Private Networks - Internetworking Wireless LANs and 3G Wireless Networks - IP-based Infrastructure for Wireless Networks - Internetworking IP and Optical Networks - Internetworking MPLS with Legacy ATM and Frame Relay Networks - Transition from IPv4 to IPv6 and interworking - Pervasive Computing - High Speed Transport Layer Protocols - Peer to Peer Networking and Grid Computing - Video Teleconferencing (VTC) - 802.11 Hotspots Conference Technical Co-chairs: - Dr. Maurice Gagnaire, ENST, France - Daniel Awduche Technical Program Committee of the Internetworking 2003 Conference: - Roberto Sabella, Erisson - Dr. Moshe Zukerman, Univ. of Melbourne - Nada Golmie, NIST - Dr. Guy Pujolle, LIP6, France - Dr. Samir Tohme, ENST, France - Stefano Trumpy, Italian National Research Council - Dr. Ibrahim Habib, City Univ. of NY - Dr. Vishal Sharma, Metanoia - Dr. Parviz Yegani, Cisco Systems - Dr. G.S. Kuo - Dr. Abbas Jamalipour, Univ. of Sydney - Dr. Hussein Mouftah, Univ. of Ottawa - James Kempf - Elizabeth Rodriguez, Co-chair, IETF Working Group on IP Storage - Dr. Ferit Yegenoglu, Isocore - Dr. Ali Zadeh, George Mason University - Tony Przygienda, Co-chair, IETF Working Group on IS-IS for IP Internets - Ran Canetti, Co-chair, IETF Working Group on Multicast Security --0-1193345935-1049731496=:58615 Content-Type: text/html; charset=us-ascii

Call for Papers
==============

Internetworking 2003, June 22-24, 2003, San Jose, California
http://www.caitr.org/internetworking03/index.htm

REMINDER: Deadline for submissions is April 11, 2003

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

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

Conference Technical Co-chairs:
- Dr. Maurice Gagnaire, ENST, France
- Daniel Awduche

Technical Program Committee of the Internetworking 2003 Conference:
- Roberto Sabella, Erisson
- Dr. Moshe Zukerman, Univ. of Melbourne
- Nada Golmie, NIST
- Dr. Guy Pujolle, LIP6, France
- Dr. Samir Tohme, ENST, France
- Stefano Trumpy, Italian National Research Council
- Dr. Ibrahim Habib, City Univ. of NY
- Dr. Vishal Sharma, Metanoia
- Dr. Parviz Yegani, Cisco Systems
- Dr. G.S. Kuo
- Dr. Abbas Jamalipour, Univ. of Sydney
- Dr. Hussein Mouftah, Univ. of Ottawa
- James Kempf
- Elizabeth Rodriguez, Co-chair, IETF Working Group on IP Storage
- Dr. Ferit Yegenoglu, Isocore
- Dr. Ali Zadeh, George Mason University
- Tony Przygienda, Co-chair, IETF Working Group on IS-IS for IP Internets
- Ran Canetti, Co-chair, IETF Working Group on Multicast Security

--0-1193345935-1049731496=:58615-- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Apr 8 02:42:12 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00700 for ; Tue, 8 Apr 2003 02:42:12 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h386ctRs004447; Tue, 8 Apr 2003 08:38:55 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4SYFYX; Tue, 8 Apr 2003 08:38:56 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h386cs201172; Tue, 8 Apr 2003 08:38:54 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h386cOYl000317; Tue, 8 Apr 2003 08:38:24 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h386cOjf000316; Tue, 8 Apr 2003 08:38:24 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from azhg2958.com ([217.78.77.13]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with SMTP id h386bqYl000280 for ; Tue, 8 Apr 2003 08:38:00 +0200 (MET DST) Message-Id: <200304080638.h386bqYl000280@sw.ericsson.se> From: "Rev. Dr. (Mrs.) Tina Mgbada" Reply-To: t_mgbada@totalise.co.uk To: ietf-send@standards.ericsson.net Date: Tue, 8 Apr 2003 08:37:58 -0700 Subject: Rev. Dr. (Mrs.) Tina Mgbada X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h386cNYl000310 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit FROM THE DESK OF Rev (Mrs.) Tina Mgbada N N P C. I am Rev (Mrs.) Tina Mgbada, Personal Assistant to the Group Managing Director of the Nigerian National Petroleum Corporation (NNPC).I have been mandated by my boss Mr. Jackson Gauis Obaseki to urgently look for a trustworthy business minded individual who can conveniently handle a transaction without much stress. On the 23rd/24th of December 2002, the Office building of the Nigerian National Petroleum Corporation was gutted with fire, although a youth movement claims responsibility, we the insider know that it was perpetrated by High ranking Government officials who want to cover their trace of embezzling the enormous Nigerian Oil money and to avoid being probed by the Independent Corrupt Practices Commission. As it is now, there are three of these papers that were with me for payment when this happened and after showing it to my boss, he decided this was a one time chance which would be carried out successfully with out any risk. The documents are already approved payment vouchers for the payment of us$18 million meant for the Organization Administrative Arm of the NNPC. As it is now, we have claimed it was burnt in the Fire but also my boss has issued instruction for the transfer of the money to the Union Bank of Switzerland (UBS AG), with the Identification of the Beneficiary as Confidential and to be provided in a later time. If you are ready to assist us, my boss Mr. Jackson Gauis-Obaseki, would write a letter stating you as the beneficiary of the fund. You would have to take charge of the collection of the fund immediately on his behave and I would come over to supervise the disbursement of the fund. For the above to be carried out without any hitch, you would have to provide quickly your full name, Banking Account and bank address for the transfer, and your personal Telephone and fax number as the UBS would be contacting you strictly through fax. My boss has agreed to compensate you with US$5 Million and pay you any expenses you may incur during the course of this transaction. Please being that as soon as the UBS contacts you, we would not have right over the said fund and the UBS would only deal with the stated beneficiary therefore we demands that you always give us a feed back to keep us abreast. As soon as I see your response and willingness to help as regards to this, I will furnish you on the next line of action to take, but be rest assured that this transaction is 100% risk free, NOTE: I know there may be scams and junk mails flying here and there on the internet but certainly, this is not thesame. Please do not fail to understand that in spite of all that, opportunities of this kind still around. Now I urge you to take this message seriously and with an open mind, with good faith and trust. Join me and I am assuring you now that you will never be disappointed. Treat as strictly confidential. NOTE:Do contact me with my private email address (t_mgbada@totalise.co.uk) Best regards, Rev. Dr. (Mrs.) Tina Mgbada -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Apr 8 06:04:45 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04270 for ; Tue, 8 Apr 2003 06:04:44 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h38A15I3003629; Tue, 8 Apr 2003 12:01:05 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4S51LX; Tue, 8 Apr 2003 12:01:06 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h38A10sY002006; Tue, 8 Apr 2003 12:01:00 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h38A0TYl025314; Tue, 8 Apr 2003 12:00:29 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h38A0TFS025302; Tue, 8 Apr 2003 12:00:29 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from helimore2232.com ([80.179.100.59]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with SMTP id h38A0MYl025101 for ; Tue, 8 Apr 2003 12:00:25 +0200 (MET DST) Message-Id: <200304081000.h38A0MYl025101@sw.ericsson.se> From: "DR OWEN GEORGE" Reply-To: owengeorge@latinmail.com To: ietf-send@standards.ericsson.net Date: Tue, 8 Apr 2003 11:00:13 -0700 Subject: BUSINESS PROPOSAL X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h38A0SYl025265 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit FROM THE DESK OF DR OWEN GEORGE UNION BANK OF NIGERIA TELEPHONE+234-1-7763352 REPLY THROUGH THE NUMBERS ABOVE STRICTLLY A PRIVATE BUSINESS PROPOSAL I AM DR OWEN GEORGE, THE MANAGER, BILLS AND EXCHANGE AT THE FOREIGN REMITTANCE DEPARTMENT OF THE UNION BANK OF NIGERA PLC. I AM WRITING THIS LETTER TO ASK FOR YOUR SUPPORT AND COOPERATION TO CARRY OUT THIS BUSINESS OPPORTUNITY IN MY DEPARTMENT. WE DISCOVERED AN ABANDONED SUM OF $15,000.000.00 (FIFTEEN MILLION UNITED STATES DOLLARS ONLY) IN AN ACCOUNT THAT BELONGS TO ONE OF OUR FOREIGN CUSTOMERS WHO DIED ALONG WITH HIS ENTIRE FAMILY OF A WIFE AND TWO CHILDREN IN NOVEMBER 1997 IN A PLANE CRASH. SINCE WE HARD OF HIS DEATH, WE HAVE BEEN EXPECTING.HIS NEXT-OF-KIN TO COME OVER AND PUT CLAIMS FOR HIS MONEY AS THE HEIR, BECAUSE WE CANNOT RELEASE THE FUND FROM HIS ACCOUNT UNLESS SOMEONE APPLIES FOR CLAIM AS THE NEXT-OF-KIN TO THE DECEASED AS INDICATED IN OUR BANKING GUIDELINES. UNFORTUNATELY, NEITHER THEIR FAMILY MEMBER NOR DISTANT RELATIVE HAS EVER APPEARED TO CLAIM THE SAID FUND. UPON THIS DISCOVERY, I AND OTHER OFFICIALS IN MY DEPARTMENT HAVE AGREED TO MAKE BUSINESS WITH YOU AND RELEASE THE TOTAL AMOUNT INTO YOUR ACCOUNT AS THE HEIR OF THE FUND SINCE NO ONE CAME FOR IT OR DISCOVERED HE MAINTAINED ACCOUNT WITH OUR BANK, OTHERWISE THE FUND WILL BE RETURNED TO THE BANKS TREASURY AS UNCLAIMED FUND. WE HAE AGREED THAT OUR RATIO OF SHARING WILL BE AS STATEDTHUS: 25% FOR YOU AS FOREIGN PARTNER, 65% FOR US THE OFFICAIALS IN MY DEPARTMENT AND 10% FOR THE SETTLEMENT OF ALL LOCAL AND FOREIGN EXPENSES INCURRED BY US AND YOU DURING THE COURSE OF THIS BUSINESS. UPON THE SUCESSFUL COMPLETION OF THIS TRANSFER, I AND ONE OF MY COLLEAGUES WILL COME TO YOUR COUNTRY AND MIND OUR SHARE. IT IS FROM OUR 60% WE INTEND TO IMPORT AGRICULTURAL MACHINERIES INTO MY COUNTRY AS A WAY OF RECYCLING THE FUND. TO COMMENCE THIS TRANSACTION, WE REQUIRE YOU TO IMMEDIATELY INDICATE YOUR INTEREST BY A RETURN E-MAIL AND ENCLOSE YOUR PRIVATE CONTACT TELEPHONE NUMBER, FAX NUMBER FULL NAME AND ADDRESS AND YOUR DESIGNATED BANK COORDINATES TO ENABLE US FILE LETTER OF CLAIM TO THE APPROPRIATE DEPARTMENTS FOR NECESSARY APPROVALS BEFORE THE TRANSFER CAN BE MADE. NOTE ALSO, THIS TRANSACTION MUST BE KEPT STRICTLY CONFIDENTIAL BECAUSE OF ITS NATURE. I LOOK FORWARD TO RECEIVING YOUR PROMPT RESPONSE. DR OWEN GEORGE -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Apr 9 04:27:56 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18086 for ; Wed, 9 Apr 2003 04:27:55 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h398OiI3025302; Wed, 9 Apr 2003 10:24:44 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2Q16M7PH; Wed, 9 Apr 2003 10:24:45 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h398Oh220698; Wed, 9 Apr 2003 10:24:43 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h398NwYl020076; Wed, 9 Apr 2003 10:23:58 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h398NwWP020075; Wed, 9 Apr 2003 10:23:58 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from aol.com (host42-176.pool21757.interbusiness.it [217.57.176.42]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with SMTP id h398NtYl020071; Wed, 9 Apr 2003 10:23:56 +0200 (MET DST) Message-ID: <000100d2ce28$cdb54413$54158808@quybuet.vhq> From: "Mike Nicholson" To: , Subject: Want to meet up?... 6228IcIL1-786bhqa3072fkVT2-728W-29 Date: Wed, 09 Apr 2003 14:07:45 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00C6_12E36A0C.B7808B41" X-Priority: 3 X-Mailer: MIME-tools 5.503 (Entity 5.501) Importance: Normal Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk ------=_NextPart_000_00C6_12E36A0C.B7808B41 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 MTMyNWhUUlo1LTc0M2pGeFc4MzM3eGFaYzktMDI4TG5ubjk5NTBWT1BnMC0y bDQyDQo8aHRtbD4NCjxoZWFkPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0i I0ZGRkZGRiIgdGV4dD0iIzAwMDAwMCI+DQo8ZGl2IGFsaWduPSJjZW50ZXIi Pg0KICA8dGFibGUgd2lkdGg9IjUyMyIgaGVpZ2h0PSIyNiI+DQogICAgPHRy PiANCiAgICAgIDx0ZCBoZWlnaHQ9IjIiIGFsaWduPSJjZW50ZXIiIHZhbGln bj0ibWlkZGxlIiBiZ2NvbG9yPSIjRkZGRkZGIiB3aWR0aD0iNTIxIj4NCiAg ICAgICAgPHAgYWxpZ249ImxlZnQiPjxmb250IHNpemU9IjIiIGZhY2U9InZl cmRhbmEiIGNvbG9yPSIjMDAwMDAwIj5IZXksIEhvdw0KICAgICAgICBkbyB5 b3UgbGlrZSB0aGUgc2l0ZSBJIGp1c3QgZm91bmQ/PC9mb250PjwvcD4NCiAg ICAgIDwvdGQ+DQogICAgPC90cj4NCiAgPC90YWJsZT4NCjwvZGl2Pg0KPGRp diBhbGlnbj0iY2VudGVyIj4NCiAgPGNlbnRlcj4NCiAgPHRhYmxlIGJvcmRl cj0iMCIgd2lkdGg9IjY1JSIgaGVpZ2h0PSIwIiBjZWxsc3BhY2luZz0iMCIg Y2VsbHBhZGRpbmc9IjAiPg0KICAgIDx0cj4NCiAgICAgIDx0ZCB3aWR0aD0i MTAwJSIgaGVpZ2h0PSIxMTciPg0KICAgICAgICA8cCBhbGlnbj0iY2VudGVy Ij48YSBocmVmPSJodHRwOi8vcmQueWFob28uY29tLypodHRwOi8vd3d3LmVt YWlsb2ZmZXIudXMvZnMvaW5kZXguaHRtbCI+PGltZyBib3JkZXI9IjAiIHNy Yz0iaHR0cDovL3JkLnlhaG9vLmNvbS8qaHR0cDovL3d3dy5lbWFpbG9mZmVy LnVzL2ZzL2ZzMl90b3AuanBnIiB3aWR0aD0iNTIzIiBoZWlnaHQ9IjE0NiI+ PC9hPjwvdGQ+DQogICAgPC90cj4NCiAgICA8dHI+DQogICAgICA8dGQgd2lk dGg9IjEwMCUiIGhlaWdodD0iMSI+DQogICAgICAgIDxwIGFsaWduPSJjZW50 ZXIiPjxhIGhyZWY9Imh0dHA6Ly9yZC55YWhvby5jb20vKmh0dHA6Ly93d3cu ZW1haWxvZmZlci51cy9mcy9pbmRleC5odG1sIj48aW1nIGJvcmRlcj0iMCIg c3JjPSJodHRwOi8vcmQueWFob28uY29tLypodHRwOi8vd3d3LmVtYWlsb2Zm ZXIudXMvZnMvZnMyX2JvdHRvbS5qcGciIHdpZHRoPSI1MjMiIGhlaWdodD0i MTQ2Ij48L2E+PC90ZD4NCiAgICA8L3RyPg0KICA8L3RhYmxlPg0KICA8L2Nl bnRlcj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0KNjcyNlhPanU0LTg1 OEVjdWQ2NDkweldqcDUtMzc4ckN5Rjg1MTV6SG5DNS04ODN0aWJJNzU5NURq d1IwLTg4OFJ0RFI1MzE2bDY4 -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- ------=_NextPart_000_00C6_12E36A0C.B7808B41-- From jari.arkko@lmf.ericsson.se Wed Apr 9 07:22:40 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22018 for ; Wed, 9 Apr 2003 07:22:40 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h39BLpI3013662; Wed, 9 Apr 2003 13:21:51 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2Q1ZRBN5; Wed, 9 Apr 2003 13:21:52 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h39BLo226839; Wed, 9 Apr 2003 13:21:50 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h39BLJYl011711; Wed, 9 Apr 2003 13:21:19 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h39BLJYp011710; Wed, 9 Apr 2003 13:21:19 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h39BLHYl011706 for ; Wed, 9 Apr 2003 13:21:17 +0200 (MET DST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21761; Wed, 9 Apr 2003 07:18:41 -0400 (EDT) Message-Id: <200304091118.HAA21761@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-send@standards.ericsson.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-send-psreq-02.txt Date: Wed, 09 Apr 2003 07:18:41 -0400 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Securing Neighbor Discovery Working Group of the IETF. Title : IPv6 Neighbor Discovery trust models and threats Author(s) : P. Nikander et al. Filename : draft-ietf-send-psreq-02.txt Pages : 27 Date : 2003-4-8 The existing IETF standards specify that IPv6 Neighbor Discovery and Address Autoconfiguration mechanisms MAY be protected with IPsec AH. However, the current specifications limit the security solutions to manual keying due to practical problems faced with automatic key management. This document specifies three different trust models and discusses the threats pertinent to IPv6 Neighbor Discovery. The purpose of this discussion is to define the requirements for Securing IPv6 Neighbor Discovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-send-psreq-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-send-psreq-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-send-psreq-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-8141951.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-send-psreq-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-send-psreq-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-8141951.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Apr 10 02:54:36 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09751 for ; Thu, 10 Apr 2003 02:54:35 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3A6rkRs018486; Thu, 10 Apr 2003 08:53:46 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2TCX0N8Q; Thu, 10 Apr 2003 08:53:47 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h3A6ri207156; Thu, 10 Apr 2003 08:53:44 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h3A6r3Yl015914; Thu, 10 Apr 2003 08:53:03 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h3A6r3M5015913; Thu, 10 Apr 2003 08:53:03 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from sina.com.cn ([218.19.60.116]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h3A6qdYm015894 for ; Thu, 10 Apr 2003 08:52:44 +0200 (MET DST) Message-Id: <200304100652.h3A6qdYm015894@sw.ericsson.se> From: =?GB2312?B?s8LWx8H6?= <777man@sina.com.cn> To: ietf-send@standards.ericsson.net Content-Type: multipart/mixed; boundary="=_NextPart_2rfkindysadvnqw3nerasdf";charset="GB2312" MIME-Version: 1.0 Reply-To: 777man@sina.com.cn Date: Thu, 10 Apr 2003 14:52:52 +0800 X-Priority: 3 X-Mailer: FoxMail 4.0 beta 2 [cn] Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk This is a multi-part message in MIME format --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/plain X-MIME-Autoconverted: from 8bit to base64 by tjatte.sw.ericsson.se id h3A6ri207156 Content-Transfer-Encoding: base64 xPq6wyENCiAgINfuvfy5pNf3yse38dLAyLu3scOmLMGs1/jPwsC00KrQqrXEyrG85La8w7vT 0MLwP9TauaTX99au0+AssrvSqs38wcuxo9bYye3M5cW2LMS/x7C5+sTat8e15NDNt87R18H3 0NAsuNDIvsLKvc+43yy4vbz+1tDM4bmpwcvQqbzytaW1xNSkt8C068qpLL/J0tTK1MrUIQ0K ICAgwe3N4s7S0qrP8rj3zru96cnc0ru/7tDC0M21xMrKus/QodDNvtbT8s34yrnTw7XEt8C7 8Me9svrGtywgVS1UcnVzdCBTRiAxMjAs1eK/7rfAu/DHvcrK08PT2jUw08O7pyjNrMqxyc/N +NPDu6fK/SnS1M/CtcTW0NCh0M2+1tPyzfjC57Dsuau7t76zLLfAu/DHvdfUtPhWUE65psTc LNans9ZQUFBPRdCt0uks1qez1ravzKzCt9PJLNans9ZOQVS5psTcLNans9ZVUky3w87Kv9jW xrXILNXi0fnHv7TzuabE3LXEt8C78Me9z9bU2rj4tb2+rc/6ycy1xLzbuPG7ubK7tb3Iy8Px sdLSu83y1KosuPfOu8rHsrvKx9PQtePQy8ikxNg/DQogICDO0tTatcjXxbj3zru+rc/6ycy7 8s+1zbO8r7PJyczF89PRtcTAtNDFu/LAtLXnLM7Su+G9q77fzOW1xLzbuPG6zcf+tcDV/rLf 0+vE+rrDusO5tc2oLM/g0MXO0sPHv8nS1NXStb3A+9LmtcS5ss2steMhDQoNCg0KICAg16MN Crmk1/fT5L/sLMntzOW9ob+1IQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICi5 47Xn06bIt9DFICAgICCwssir06bIt9DFKQ0KDQoNCsnPuqO547Xn06bIt9DF09DP3rmry765 49bdsOzKwrSmDQrN+MLnsLLIq7L6xreyvyAgs8LWx8H6DQq549bdytDM7LrTwrczNTG6xbnj tqvN4r6tw7O088/DMjAyMsrSDQpUZWw6MDIwLTM4ODE5NjQwo6wzODgxOTY0MQ0KRmF4OjAy MC0zODgxOTY0Mg0Kyta7+joxMzgyMjE5NDE5NSANCiAgICAgICAgICAgIHd3dy5zdmFuZXR3 b3Jrcy5jb20NCiAgICBFLU1BSUw6IDc3N21hbkBzaW5hLmNvbS5jbg0KICAgDQoNCg== --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: application/octet-stream; name="国外建议的预防SARS的方法.doc" Content-Disposition: attachment; filename="国外建议的预防SARS的方法.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAJwAAAAAAAAAA EAAAKQAAAAEAAAD+////AAAAACYAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAOSAJBAAA8FK/AAAAAAAAEAAAAAAABAAA5BAAAA4AYmpiav3P/c8AAAAAAAAAAAAAAAAAAAAA AAAECBYAMhoAAJ+lAACfpQAAcgYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAPQAAAAAAAAA9AAAAPQA AAAAAAAA9AAAAAAAAAD0AAAAAAAAAPQAAAAAAAAA9AAAABQAAAAAAAAAAAAAAAgBAAAAAAAAbAIA AAAAAABsAgAAAAAAAGwCAAAAAAAAbAIAABQAAACAAgAADAAAAAgBAAAAAAAACwgAAPIAAACYAgAA AAAAAJgCAAAAAAAAmAIAAAAAAACYAgAAAAAAAJgCAAAAAAAAmAIAAAAAAACYAgAAAAAAAJgCAAAA AAAAZgcAAAIAAABoBwAAAAAAAGgHAAAAAAAAaAcAAAAAAABoBwAAAAAAAGgHAAAAAAAAaAcAACQA AAD9CAAAIAIAAB0LAABsAAAAjAcAADkAAAAAAAAAAAAAAAAAAAAAAAAA9AAAAAAAAACYAgAAAAAA AAAAAAAAAAAAAAAAAAAAAACYAgAAAAAAAJgCAAAAAAAAmAIAAAAAAACYAgAAAAAAAIwHAAAAAAAA JAcAAAAAAAD0AAAAAAAAAPQAAAAAAAAAmAIAAAAAAAAAAAAAAAAAAJgCAAAAAAAAxQcAABYAAAAk BwAAAAAAACQHAAAAAAAAJAcAAAAAAACYAgAA9AMAAPQAAAAAAAAAmAIAAAAAAAD0AAAAAAAAAJgC AAAAAAAAZgcAAAAAAAAAAAAAAAAAACQHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAmAIAAAAAAABmBwAAAAAAACQHAABCAAAAJAcAAAAAAAAAAAAA AAAAAGYHAAAAAAAA9AAAAAAAAAD0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZgcAAAAAAACYAgAAAAAAAIwCAAAMAAAAALJMrSb/ wgEIAQAAZAEAAGwCAAAAAAAAjAYAAHYAAABmBwAAAAAAAAAAAAAAAAAAZgcAAAAAAADbBwAAMAAA AAsIAAAAAAAAZgcAAAAAAACJCwAAAAAAAAIHAAAiAAAAiQsAAAAAAABmBwAAAAAAACQHAAAAAAAA CAEAAAAAAAAIAQAAAAAAAPQAAAAAAAAA9AAAAAAAAAD0AAAAAAAAAPQAAAAAAAAAAgDZAAAA/VYW WfperouEdoSYMpZTAEEAUgBTAIR2uWXVbAz/1GstTv1WhHbReSAAZlsaWYZOKABsj32PKQAgAAsA RABhAHQAZQA6ACAAVAB1AGUALAAgADgAIABBAHAAcgAgADIAMAAwADMAIAAxADAAOgA0ADcAOgAy ADAAIAArADAAOAAwADAAIAAoAEMAUwBUACkAIAANAB91O20vZo5/fVmEdiwAQGLlTveL3U/NkWBP nVs1jYR2L1UAToR2q45TTyEACwA6ACAARgBXADoAIAD9VhZZ+l6ui4R2hJgyllMAQQBSAFMAhHa5 ZdVsDP/Uay1O/VaEdtF5ZlsaWYZOKABsj32PKQAgAA0AXnnYeYR2Xpd4UYtXJ2C6gI5wY2soV5mZ L25/XttsIE+tZAz/jk4vZhFi+VsVX3eNUwBBAFIAUwAoACVOzZF8VDhU/H4IVIFfCf+EdsV14FYI /wsAi0+CWaBRtnLFddJrCf9cT4ZOAE4LThR4dnoCMLBzKFepixFizk4fdWlyO1NmWxR4dnoFgIR2 0ommXtl+qGAATptO+l6uiwIwIAANAORux48nYMV10mv9gB9ZFV93jb51xXWEdp9T4FYvZgz/xXXS a/2AH1kakMePf08odcV1uk6rjlNPLU6EdkQATgBBAPpX4FYNWTZS+3zffmVnCwANWTZS6oHxXQIw glmcZ8V10msnWc+RDVk2UuqB8V0M/xlSEWLsToR2q45TTzFcDU79gGNrOF7lXVxPhk4CMI5OL2YM /xFi7E6rjlNPCwBTXy1OhHZNUat1xn7egDFcGk+IX+tfhHZAZ4lj2Y+bTh9h02fFddJrAjA2cQyA DP/Zj5tOxXXSa16XOF5qgA5mDP/WTuxO/YAfWadOCwAfddBnzXkWU2ZbaXIojQyA/Fv0gRFi7E6E dk1Rq3XGft6Ae2uhTgIwZJZka+VOFlkM/6BRtnLFddJrL2YATs15sGWLV4R22FMCX8V1CwDSawz/ g1sNTv2Aq4gRYuxOhHarjlNPxosrUgIw2Y83aAz/KFcRYuxOhHZNUat1+3zffoxUxXXSa0tO9JUx XBpPVVwAXwBOOld/lfZlCwD0lYR2l2WJTgIwnltFlgpODP/FddJrdl4NTv2AQGd7awBOKk5lULde uk6rjlNPLU6EdkBiCWdNUat1xn7egAIwuk6rjlNPhHZNUat1CwCfUv2Aio06Xwz/ZGu6TtdTxXXS a7VPs1uEduBRh3MxXIqND1wCMEBi5U4M/yhXH2HTZ8V10msOVIR2xXXFYCVOzZHFYLVRjFS3Xg1Z CwCEduBRh3P6VyxnCk4Ld2Rruk6Edk1Rq3WfUv2ACWcaWTpfAjAgAA0AYE/gZdVsf5BNUauIH2HT Zwz/ZJZel2BPDU67U6Vj5omriB9h02cFgIxUq4gfYdNnMFc6UwIwRk8vZgz/YE/vU+VOPVxgT0Bi /YADjAsAqFJgT4R2TVGrdft8334M/2543U9gTwRZjk4cIF6XOF5lULdeHSCEdrZyAWAM//OBEVwo V9mPtWtelzhe9mUfZwIwglmcZ2BPhHZNUQsAq3X7fN9+H1k6Xwz/MVyXe2BPXpc4Xg1OeF6EdquI H2HTZwpOxXXSawz/X04aTwZcxXXSa4R2tU+zW02WMFIAZ05PUJamXgIw0XlmWwsAtlvsTrBzKFdj ayhXFHh2eoJZVU+7bJd1ZGvNebqAjnAM/0Bi5U4ATppbgYndT8GLYE/9gB9ZO20wUglnSGW7bJd1 uWXVbBR4dnr6UQsAZWdLTk1SAjALTmKXL2YATptOKFftd/ZlH2eFUf2AH1meWDpfYE+Edk1Rq3Wf Uv2AhHa5ZdVsGv8gAA0Al2InbBZTQlIa/5diJ2wWU0JSL2YATs15WFsoV45O35jBVC1OhHb9gB9Z iF99WZ5YOl8RYuxOTVGrdft8336EdhZTZltpciiNAjBgTwsA71PlTmCXDWcodQBOm06XYidsFlNC Ut1PZVDBVGVnnlg6X2BPhHZNUat1n1L9gBr/IAANAC0ALQDPaylZDWcodfR+1k59VEUAMQAwADAA MAAgAEkAVQAgACgAO1NmW/1WRZZVU01PDP9pAG4AdABlAHIAbgBhAHQAbwBpAG4AYQBsACAAdQBu AGkAdABzACkAAjBBAGwAcABoAC0A9H4fdSB9RQAvZgsAAE7NeR91aXI7bSdg9H7WTn1URQACMINb CWckTs15Yl8PXxr/ZAAtAPR+H3UgfUUAjFRkAGwALQD0fh91IH1FAC4AZAAtAPR+H3UgfUUAL2bq gTZxYl8PXwsADP9kAGwALQD0fh91IH1FAC9mCFQQYmJfD18CMABnfVkNZyh1ZAAtAPR+1k59VEUA DP/gVjpOg1vvU+VO9GbrX4R2q4gRYuxOhHarjlNPQGI4VDZlCwACMAsALQAtAM9rKVkxADAAMAAw AOtrS1H0ftZOfVRDACgAl2JPV0CIeJH0fh91IH1DACkAAjBgT19O71PlTmCXz2spWd+YKHUkTipO 0WdUaHt8NGycZwj/i08LAIJZVGhQWwn/ZWe3g9ZT9H7WTn1UQwACMAsALQAtAEIAZQB0AGEA4YBX f1xTIH0M/89rKVkNZyh1DU6FjcePMQAwADAAMAAwAEkAVQALAC0ALQBSeAz/z2spWTIAMAAwAK5f S1ELAC0ALQAMlQz/z2spWQ1OhY3HjzUAMAAwAOtrS1ELAC0ALQBreJuPeJEM/89rKVk1ADAA62tL UQsALQAtADeM8YAYdb2ADP/PaylZNQAwAOtrS1ELAKFsCWf7TlVPuk7NUyBmDWcodeVOCk5pciiN CWdvUlxPKHUCMCAADQAtAC0Az2spWZ1V/342gwz/4FY6Tv9+NoMtTitUCWcnWc+Rl2InbBZTQlJ7 fMSebpGMVDaDeJECMAsALQAtABpZA1R/iaJ+/2cM/zBp3IMM/4xUdlGDW6J+coKMVPFtcoKEdjRs nGcCMCAADQAoV9mPtWtelzhe9mUfZw1OgYlaUGdSyHDQj6hSAf/gVjpOZ1LIcNCPqFIaT4tTkWJg T4R2TVGrdft8336fUv2ACP8OTmBPhHYKTnxUCwA4VB9h02cJZ3NRhHZNUat1+3zffp9S/YAJ/wz/ dl4UTmRri1ORYsVgtVEaTwFj7X59WeBRKVkCMIJZnGdgT+VOe1EQYppbH2c7lbxwCwCEdmBO72AM /6OQSE4oV9mPtWv2ZfSVYE/vU+VOWlAATptOe4+mXhZiLU6mXtCPqFICMCAADQBueN1PYE/fmCh1 s40fWYR2s3g0bBZTCFRpct+YaXII/4tPglkM/ydZc3zKU3ZRg1vMWytUwG2JfIR235hpcgn/DP/g VjpOs3g0bBZTCwAIVGlyL2ZNUat1xn7egABnzZGBiYR235hpcgIwnVUATptORwBhAHQAbwByAGEA ZABlAAj/AE7NeW6ZmWUJ/xZiUABvAGMAYQByAGkACP8ATs15bpmZZQn/DP8LAOBWOk7WTuxO/ZAv ZsxbK1SzeDRsFlMIVGlyhHZumZllAjAgAA0Az2spWd1PwYtFUbONYXcgdwz/DU6BiX9P6oHxXQRZ jk4nfSBfjFSLU5tSS04LTgIwJnFRhgEwJ30gX/2QGk9xX81Uq45TT4R2i1ObUgsAd4MUXJmECP+L T4JZDP8/UTaDWpGJW4xU1nyudiiNwG8gfQn/zk4MgItTkWKrjlNPTVGrdZ9S/YACMCAADQDjU2l/ fYY2cQ1O/YAxADAAMAAlAISYMpYfYdNnDP9GTy9m/YAfWXeNMFIATppbhHZcTyh1DP/NTjZx71Pl Ts9REVyriB9h02fgUYdzAjAgAA0A5U4KTkBiCWfhT29gR1cJZx91aXI7U2ZbBnS6iy9lAWMM/9mP m076Xq6L/ZAvZg1O71MdYK6LjFRBUwZS71Ngl4R2AjAKTh1e3U9RTwsAAjARYh93w18MXhtnYE/s Ti1OoWwJZwBOKk66ThpPq4gfYdNnAjARYhpP9mU7UjpOYE/sTidZtltIeXd5c16JWwH/IAANAEcA bwBvAGQAIABsAHUAYwBrACAAYQBuAGQAIAB0AGEAawBlACAAZQB4AHQAcgBlAG0AZQBsAHkAIABj AGEAcgBlAC4ACwBdeWBP7E59WdCPDP9DUwdO3U/NkQIwIAANAFAAYQByAGMAbwAgAE0ALgAgAFMA aQB1ACwAIABNAFAAaABpAGwALAAgAFAAaABEACAAQwBhAG4AZABpAGQAYQB0AGUAIAANAFcAZQBz AHQAIABWAGkAcgBnAGkAbgBpAGEAIABVAG4AaQB2AGUAcgBzAGkAdAB5ACAAUwBjAGgAbwBvAGwA IABvAGYAIABNAGUAZABpAGMAaQBuAGUACwB/iRdfCVQ8XJpOJ1lmWztTZltilg0AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAOAQAAJAE AACUBAAAwAQAAM4EAAAEBQAABgUAAAgFAABaBQAAXAUAAKQFAACoBQAA+AUAAPoFAABGBgAASAYA AJQGAACWBgAA4gYAAOQGAAAwBwAAMgcAAH4HAACABwAAzAcAAM4HAADyBwAA9gcAAEIIAABECAAA kAgAAJIIAADeCAAA4AgAACwJAAAuCQAAZgkAAGoJAAC2CQAAuAkAAOgJAADsCQAAOgoAADwKAABe CgAAYAoAALgKAAC6CgAADgsAABALAAASCwAAFAsAAGoLAABsCwAAhAsAAIYLAAC4CwAAugsAANAL AADSCwAA7gsAAPALAAAIDAAACgwAACQMAAAmDAAASgwAAE4MAACGDAAAiAwAALYMAAC6DAAABg0A AAgNAABUDQAAVg0AAIgNAACMDQAA2A0AANoNAAA0DgAA9/Dn3NDczgDc0NzO3NDc0NzQ3NDc0NzQ 3NDcztzQ3NDc0NzQ3M7c0NzO3NDc0NzQ3NDc0NzQ3NDc0NzQ3NDc0NzQ3M7c0NzO3NDc0NzO3NDc AAAAA28oABdDShgAT0oCAFFKAgBeSgIAYUoYAG8oABRDShgAT0oCAFFKAgBeSgIAYUoYAAAQQ0oS AE9KAwBRSgMAYUoSAAAMT0oCAFFKAgBeSgIAAA9PSgIAUUoCAF5KAgBvKAEAUQAEAACUBAAACAUA AKgFAAD2BwAAagkAAOwJAABODAAAugwAAIwNAABcDgAA6A4AADoPAADODwAALhAAAHYQAADkEAAA /QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAA AAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAA AAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsA AAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AAAEAAAAQAAQAAOQQAAD+AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIBAQE0DgAANg4AAFgOAABc DgAAqA4AAKoOAADkDgAA6A4AADYPAAA6DwAAhg8AAIgPAADKDwAAzg8AABQQAAAqEAAALhAAAHIQ AADOEAAA5BAAAPPo5ujz6Obo5ujz6Obz6Obz5gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA28oABRDShgA T0oCAFFKAgBeSgIAYUoYAAAXQ0oYAE9KAgBRSgIAXkoCAGFKGABvKAAAEzAAMZA4ATJQAgAfsIIu ILDGQSGwCAcisAgHI5CgBSSQoAUlsAAAF7BTAxiw4AMMkKkBAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAQAAoAAQBpAA8AAwAA AAMAAAAAAEYAAEDx/wIARgAMAAIAY2uHZQAACwAAAAMkAzEkAGEkAwAkAENKFQBLSAIAUEoDAF9I AQRhShgAbUgJBG5IBAhzSAkEdEgECAAAAAAAAAAAAAAAAAAAAAAAABwAQUDy/6EAHAAMAAYA2J6k i7VrPYRXW1NPAAAAAAAAAAAAAAAAXABeYAEA8gBcAAwACABuZhqQIAAoAFcAZQBiACkAAAAZAA8A AyQAE6RkABSkZAAxJAFbJAFcJAFhJAAAIABCKg1DShIAS0gAAE9KAwBRSgMAYUoSAG8oAXBoDwAA AAAAAAByBgAADQAAGgAAAAD/////AAAAAEoAAACEAAAA1AAAAPsBAAC1AgAA9gIAACcEAABdBAAA xgQAAC4FAAB0BQAAnQUAAOcFAAAXBgAAOwYAAHQGAACYAAAAADAAAAAAAAAAgAAAAICYAAAADzAA AAAAAAAAgAAAAICYAAAADzAAAAAAAAAAgAAAAICYAAAADzAAAAAAAAAAgAAAAICYAAAADzAAAAAA AAAAgAAAAICYAAAADzAAAAAAAAAAgAAAAICYAAAADzAAAAAAAAAAgAAAAICYAAAADzAAAAAAAAAA gAAAAICYAAAADzAAAAAAAAAAgAAAAICYAAAADzAAAAAAAAAAgAAAAICYAAAADzAAAAAAAAAAgAAA AICYAAAADzAAAAAAAAAAgAAAAICYAAAADzAAAAAAAAAAgAAAAICYAAAADzAAAAAAAAAAgAAAAICY AAAADzAAAAAAAAAAgAAAAICYAAAADzAAAAAAAAAAgAAAAIAABAAANA4AAOQQAAAJAAAADAAAAAAE AADkEAAACgAAAAAEAADkEAAACwAAAAAAAAAHAAAACwAAABQAAAAVAAAAGAAAABkAAAAbAAAASgAA AFAAAABRAAAAXwAAAGcAAABuAAAAcgAAAH4AAAB/AAAAgQAAAIQAAACcAAAAoQAAAKgAAACpAAAA rAAAAK4AAAC0AAAAtQAAANIAAADUAAAA8gAAAPUAAAD8AAAA/QAAACMBAAAkAQAASgEAAEsBAABx AQAAcgEAAJgBAACZAQAAvwEAAMABAADmAQAA5wEAAPkBAABwAgAAlgIAAJcCAACzAgAA3AIAAPMC AAD4AgAA/wIAAAkDAAAQAwAAHQMAACQDAAAlAwAAKQMAACoDAAAtAwAALgMAAC8DAAAwAwAAOQMA ADoDAABCAwAARAMAAEcDAABIAwAASQMAAEwDAABPAwAAUgMAAFMDAABWAwAAVwMAAFwDAABdAwAA XgMAAGEDAABkAwAAZQMAAG8DAABxAwAAdAMAAHUDAACHAwAAiAMAAIkDAACMAwAAjgMAAJIDAACX AwAAmQMAAKADAACiAwAAtQMAALYDAADAAwAAwQMAAMIDAADJAwAA1QMAAN8DAADjAwAA5gMAAOgD AADrAwAA8gMAAPUDAAD3AwAA+gMAAAAEAAACBAAABAQAAAcEAAAOBAAAEAQAABIEAAATBAAAJQQA ACkEAABDBAAARgQAAFsEAABdBAAAfQQAAH4EAACDBAAAhAQAAJAEAACRBAAAqgQAAKsEAADEBAAA xgQAANUEAADWBAAA5QQAAOYEAADsBAAA7QQAAP4EAAAHBQAADQUAABMFAAAUBQAAGgUAABsFAAAs BQAAdAUAAHoFAAB+BQAAmwUAAJ0FAADDBQAAxAUAAOUFAAAKBgAAFQYAACAGAAAjBgAAJQYAACoG AABnBgAAcQYAAHQGAAAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAH AAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcA BQAHAAUABwAFABwABwAFABwABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFABwABwAFAAcABQAH AAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcA BQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAF AAcABQAHAAUABwAFAAcABQAHAAUAHAAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAcAAcA HAAHAAQABwAAAAAAqAAAAKkAAABLAQAATgEAAEkCAABKAgAATgIAAMoDAADNAwAACAQAAAsEAAA5 BAAAPwQAAEAEAABCBAAAYQUAAGQFAAA7BgAAdAYAAAcAcwAHADMABwBzADMABwAzAAcAcwAHADMA BwBzAAcAcwAHAAQAAAAAAPYCAAAlAwAAOwYAAHEGAAB0BgAABwAFAAcABQAHAP//AgAAAAIAcABj ABoARQA6AFwAKk66TuFPb2BcAP1WFln6Xq6LhHaEmDKWUwBBAFIAUwCEdrll1WwuAGQAbwBjAP9A A4ABAHEGAABxBgAAAMEOAwEAAQBxBgAAAAAAAHEGAAAAAAAAAjQAAAAAAAAAAAQAAAAFAAAABgAA cgYAANAAAAQAAAAA0AAADAAAAADQAAAOAAAAANAAABAAAAAA//8BAAAABwBVAG4AawBuAG8AdwBu AP//AQAIAAAAAAAAAAAAAAD//wEAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAQAAABHFrwC AAACAgYDBQQFAgMEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABS AG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0A YgBvAGwAAAAzJpABAAACCwYEAgICAgIEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBs AAAAOwaQAYYDAgEGAAMBAQEBAQMAAAAAAA4IEAAAAAAAAAABAAQAAAAAAItbU08AAFMAaQBtAFMA dQBuAAAAIAAEAHEIiBgAAKQBAABoAQAAAAB5U3SGgVN0hgAAAAABAAQAAADuAAAAUAUAAAEAAgAA AAQAAxALAAAAAAAAAAAAAAABAAEAAAABAAAAAAAAACEDAAAAAAAAAwAtABMAIQApACwALgA6ADsA PwBdAH0AqAC3AMcCyQIVIBYgGSAdICYgNiIBMAIwAzAFMAkwCzANMA8wETAVMBcwAf8C/wf/Cf8M /w7/Gv8b/x//Pf9A/1z/Xf9e/+D/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACgAWwB7ALcAGCAcIAgwCjAMMA4wEDAUMBYwCP8O/zv/W//h/+X/ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAgHoAW0AJwAgoAyAAAAAAAAAAAAAAAAAAAAhgYAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAATKD UQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//EgAAAAAAAAAdAP1WFln6Xq6L hHaEmDKWUwBBAFIAUwCEdrll1WwM/9RrLU79VoR20XkgAGZbGlmGTigAbI99jykAIAAAAAAAAAAC AHAAYwACAHAAYwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAA AAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAIwBAAARAAAAAQAAAJAAAAACAAAAmAAAAAMAAADUAAAA BAAAAOAAAAAFAAAA7AAAAAYAAAD4AAAABwAAAAQBAAAIAAAAFAEAAAkAAAAgAQAAEgAAACwBAAAK AAAASAEAAAwAAABUAQAADQAAAGABAAAOAAAAbAEAAA8AAAB0AQAAEAAAAHwBAAATAAAAhAEAAAIA AACoAwAAHgAAADMAAAC5+s3ivajS6bXE1KS3wFNBUlO1xLe9t6ijrLHI1tC5+rXEv8Yg0ae24MHL KNeq1NgpIAAAHgAAAAEAAAAA+s3iHgAAAAMAAABwYwDiHgAAAAEAAAAAYwDiHgAAAAEAAAAAYwDi HgAAAAcAAABOb3JtYWwA6R4AAAADAAAAcGMAbR4AAAACAAAAMQAAbR4AAAATAAAATWljcm9zb2Z0 IFdvcmQgOS4wAMRAAAAAABgNjwAAAABAAAAAAB5hACb/wgFAAAAAADZujyb/wgEDAAAAAQAAAAMA AADuAAAAAwAAAFAFAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN 1ZwuGxCTlwgAKyz5rjAAAAAYAQAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAfAAAAAYAAACEAAAA EQAAAIwAAAAXAAAAlAAAAAsAAACcAAAAEAAAAKQAAAATAAAArAAAABYAAAC0AAAADQAAALwAAAAM AAAA+wAAAAIAAACoAwAAHgAAAAEAAAAAdoSYAwAAAAsAAAADAAAAAgAAAAMAAACGBgAAAwAAAPwK CQALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAAMwAAALn6zeK9qNLptcTU pLfAU0FSU7XEt723qKOsscjW0Ln6tcS/xiDRp7bgwcso16rU2CkgAAwQAAACAAAAHgAAAAUAAADM 4sS/AAMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAA AAsAAAAMAAAADQAAAP7///8PAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAA/v///xcAAAAYAAAA GQAAABoAAAAbAAAAHAAAAB0AAAD+////HwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAAP7////9 ////KAAAAP7////+/////v////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYA AAAAAAAAAAAAAABA9FutJv/CASoAAACAAAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIA////////////////AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAAAAQAAAAAAAAVwBvAHIAZABEAG8A YwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEF AAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMhoAAAAA AAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAKAACAQIAAAAEAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAABYAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwBy AG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAHgAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgEBAAAABgAAAP////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZgAAAAAAAABPAGIAagBlAGMAdABQ AG8AbwBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgABAP// /////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAQPRbrSb/wgFA9FutJv/CAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAQAAAP7///////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGFAAAAE1pY3Jvc29mdCBX b3JkIM7EtbUACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAA== --=_NextPart_2rfkindysadvnqw3nerasdf-- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Apr 11 13:04:30 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21357 for ; Fri, 11 Apr 2003 13:04:29 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3BH1SRs012548; Fri, 11 Apr 2003 19:01:28 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2VDNN4H7; Fri, 11 Apr 2003 19:01:29 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h3BH1KsY005333; Fri, 11 Apr 2003 19:01:20 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h3BH0iYl004480; Fri, 11 Apr 2003 19:00:44 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h3BH0ijR004479; Fri, 11 Apr 2003 19:00:44 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from great.matglobal.net (213-25-18-123.tvk.tpsa.pl [213.25.18.123]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with SMTP id h3BH0hYl004464 for ; Fri, 11 Apr 2003 19:00:43 +0200 (MET DST) Received: (qmail 6207 invoked from network); 11 Apr 2003 19:00:51 -0000 Received: from unknown (HELO jc00586-33456) (unknown) by unknown with SMTP; 11 Apr 2003 19:00:51 -0000 Message-ID: <413-22003451117039687@jc00586-33456> To: "SECURED HOST" From: "" Subject: =?windows-1252?Q?=BB=BB=BB=BB_SECURED_HOST_=AB=AB=AB=AB?= Date: Fri, 11 Apr 2003 13:00:39 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h3BH0hYl004465 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit *SECURED OFFSHORE HOSTING SERVERS* [Host your website offshore, securely, and privately!] WE WILL NOT SHUT YOU DOWN DUE TO COMPLAINTS! =====U N I T E D S E R V E R S F E D E R A T I ON===== http://www.unitedserversfederation.org -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Apr 14 02:48:52 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25832 for ; Mon, 14 Apr 2003 02:48:51 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3E6iDI3010366; Mon, 14 Apr 2003 08:44:13 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2V1AK9TC; Mon, 14 Apr 2003 08:44:14 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h3E6i9sY004909; Mon, 14 Apr 2003 08:44:09 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h3E6hVYl012492; Mon, 14 Apr 2003 08:43:31 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h3E6hVJI012491; Mon, 14 Apr 2003 08:43:31 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h3E6hUYl012479 for ; Mon, 14 Apr 2003 08:43:30 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 1C1F21C for ; Mon, 14 Apr 2003 09:53:31 +0300 (EEST) Message-ID: <3E9A58AC.50601@nomadiclab.com> Date: Mon, 14 Apr 2003 09:43:56 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: Timestamps vs. nonces Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit In last weeks phone meeting I promised to write up something about the problems with timestamps. In the first look, coarse grained timestamps look like a good idea. If we can assume that the nodes have roughly the same idea of time, then it is easy to ignore old messages and therefore mitigate replay attacks. If a node is running in the past, it does not cause any harm, since its messages will be ignored. However, if a node has a wrong notion of the time so that they run in the future, this is a problem. Firstly, the host ignores all other hosts since it thinks that they are doing replay attacks or running in the past. Secondly, and more importantly, the node itself becomes vulnerable to a replay attack. This may be or may not be a problem, depending on what are the consequences of such a replay attack. The real problem lies in synchornizing the clocks whenever the nodes detect that they are likely to run with a wrong notion of time. Just adjusting to whatever the other nodes are using does not work, since it would make the node vulnerable to someone fooling around with its notion of time, in a preparation of an attack. If we could assume a human to adjust the time whenever it is wrong, I think timestamps would be acceptable. But can we do that? I thought that our goal is zero configuration, more or less. Requiring human intervention whenever a node looses its idea of the current time does not sound like a good design. Thus, IMHO, we should aim for not using timestamps. I'd rather leave out or re-design functionality that would require timestamps, or maybe even leave such functionality vulnerable to some (non-severe) replay attacks. --Pekka -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Apr 14 05:03:55 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28573 for ; Mon, 14 Apr 2003 05:03:54 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3E92FI3022233; Mon, 14 Apr 2003 11:02:15 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2V10GQPY; Mon, 14 Apr 2003 11:02:16 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h3E92E208083; Mon, 14 Apr 2003 11:02:14 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h3E91nYl029881; Mon, 14 Apr 2003 11:01:49 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h3E91nGu029880; Mon, 14 Apr 2003 11:01:49 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h3E91mYl029876 for ; Mon, 14 Apr 2003 11:01:48 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id E9C4D1C for ; Mon, 14 Apr 2003 12:11:51 +0300 (EEST) Message-ID: <3E9A7918.9000502@nomadiclab.com> Date: Mon, 14 Apr 2003 12:02:16 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: Thoughts about transition mode Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit On last weeks telephone meeting I promised to write up my thoughts about the transition mode. Here are now some notes. For some time already I have had the feeling that the current transition mode idea, i.e. having two logically separate links on one physical link, will not fly. I still cannot point out the exact reasons, but my strong intuitive feeling is that there will be a number of problems. OTOH, only implementation work will tell for sure. As an alternativity, I would promise the following approach. I am only considering ND here, Router Discovery will require more work. Have two different modes for each link: 1. Mixed mode. Allow both SEND and legacy nodes. SEND nodes are somewhat vulnerable to downgrading (aka bidding down) attacks by attackers claiming to be legacy nodes. 2. Secure mode. All SEND nodes ignore the legacy nodes. At the ND level, SEND nodes defend their IP addresses against legacy nodes/attackers, but do not participate in legacy traffic otherwise. The mode selection is a configuration switch. All SEND nodes MUST implement both modes, and the default configuration SHOULD be mixed mode, for the time being. Defending addresses ------------------- In both modes all SEND nodes MUST reply to unproteced NS queries with both an AH protected and AH unprotected NA. That is, if a SEND node receives an unprotected NS that refers to any of its addresses, it will send two replies: One contains a normal, legacy NA, and the other one sem same NA, protected with AH. Mixed mode ---------- In this mode SEND nodes keep track of the other nodes on the link, and whether they are SEND nodes or not. Basically, if another node is a SEND node, its public key is recorded in the Neighbor Cache. The mere presense of the public key is enough to signal that the node is a SEND node. If the node needs to garbage collect Neighbor Cache entries, it should avoid garbage collecting SEND ND entries. Otherwise an attacker would be able to fill the ND with new entries, forcing the SEND node entries to be flushed, etc. When a SEND node wants to get the link-layer address of another node, it first sends an AH protected NS. If it does not receive any reply within RetransTimer/10 milliseconds, it sends an unprotected ND. Since the default RetransTimer is 1000 milliseconds, this causes an 100 ms additional delay in contacting non-SEND hosts. I think this is acceptable. If retransmissions are required, the node behaves as if it were doing both the AH protected and unprotected address resolutions at the same time, RetransTimer/10 milliseconds apart. That is, it always sends first an AH protected NS, and then RetransTimer/10 milliseconds later an unprotected one. If a SEND node receives an AH protected NS, is simply replies with an AH protected NA. If a SEND node receives an unprotected NS, is replies first with an AH protected NA, and a few milliseconds after that with an unprotected NA. 10 ms delay is probably ideal for most environments, but we may need to do some simulation or experiments. DAD is an interesting question here. I will not touch it since we cannot use AH for DAD right now. Secure mode ----------- In this mode SEND nodes keep track only about other SEND nodes. They ignore all unprotected messages other than unprotected NS messages, which they MUST reply to in order to protect their addresses. As a result, legacy nodes may try to send traffic to SEND nodes, but SEND nodes will not reply since they do not "see" the legacy nodes on the link. This is perfectly acceptable, since the purpose of this mode is to ignore the legacy nodes and pretend that they do not exist. ----------------------------------------------------- I know that implementing this is not as easy as the currently proposed implementation is. In effect, the implementation requires a fairly rich API between the ND layer and the IPsec layer, allowing the ND layer to receive and send both protected and unprotected packets. In other words, the IPsec layer must include meta data in the packets so that the ND layer can learn the public key of the other SEND nodes. Respectively, the ND layer must be able to inform the IPsec layer whether to protect a given packet or not. I do not think this is too hard. We have to remember that to implement SEND one has to change the IPsec implementation anyway. In the case where it is undesirable to change the IPsec policy implementation, the actual policy can be implemented in the SEND SA code. That is, one can configure IPsec to use AH always for ND/RD packets, but the actual AH SA code would pass up also unprotected packets and would allow sending unprotected packets. Thoughts? --Pekka -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Apr 14 05:39:49 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29158 for ; Mon, 14 Apr 2003 05:39:49 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3E9eNRs006180; Mon, 14 Apr 2003 11:40:23 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2VDN573H; Mon, 14 Apr 2003 11:40:16 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h3E9eD209278; Mon, 14 Apr 2003 11:40:13 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h3E9dlYl003871; Mon, 14 Apr 2003 11:39:47 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h3E9dlH5003869; Mon, 14 Apr 2003 11:39:47 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h3E9djYl003865 for ; Mon, 14 Apr 2003 11:39:46 +0200 (MET DST) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id h3E9dgw22797; Mon, 14 Apr 2003 11:39:42 +0200 (MEST) Message-ID: <3E9A81DE.7E05F72E@inrialpes.fr> Date: Mon, 14 Apr 2003 11:39:42 +0200 From: Claude Castelluccia Organization: INRIA X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Nikander CC: SEND WG Subject: Re: Thoughts about transition mode References: <3E9A7918.9000502@nomadiclab.com> Content-Type: multipart/alternative; boundary="------------AD3BADA1A3D734DEF376CF99" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk --------------AD3BADA1A3D734DEF376CF99 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Pekka Nikander wrote: > > > 1. Mixed mode. Allow both SEND and legacy nodes. > SEND nodes are somewhat vulnerable to downgrading > (aka bidding down) attacks by attackers claiming > to be legacy nodes. Hello Pekka, The bidding down attack can be prevented by embedding the address type in the address itself? For example if it is decided that legacy addresses have the lowest bit set to 0 and the SEND addresses have the lowest bit set to 1, the bidding down attack can not be performed... Is that right? cheers, Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------AD3BADA1A3D734DEF376CF99 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Pekka Nikander wrote:
 

1.  Mixed mode.  Allow both SEND and legacy nodes.
     SEND nodes are somewhat vulnerable to downgrading
     (aka bidding down) attacks by attackers claiming
     to be legacy nodes.

Hello Pekka,
The bidding down attack can be prevented by embedding the
address type in the address itself?

For example if it is decided that legacy addresses have the
lowest bit set to 0 and the SEND addresses have the lowest
bit set to 1, the bidding down attack can not be performed...

Is that right?

cheers,
Claude.
  

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------AD3BADA1A3D734DEF376CF99-- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Apr 14 06:56:56 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00383 for ; Mon, 14 Apr 2003 06:56:55 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3EAuIS8029258; Mon, 14 Apr 2003 12:56:22 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2VAMF02B; Mon, 14 Apr 2003 12:55:29 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h3EAsr212245; Mon, 14 Apr 2003 12:54:53 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h3EAsPYl013082; Mon, 14 Apr 2003 12:54:26 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h3EAsPNj013080; Mon, 14 Apr 2003 12:54:25 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h3EAsOYl013074 for ; Mon, 14 Apr 2003 12:54:24 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 83E861C for ; Mon, 14 Apr 2003 14:04:28 +0300 (EEST) Message-ID: <3E9A937D.7040706@nomadiclab.com> Date: Mon, 14 Apr 2003 13:54:53 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: SEND WG Last call on draft-ietf-send-psreq-03 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Second WG Last Call on draft-ietf-send-psreq-03.txt starts today and runs for one week, until Monday, April 21st. This draft is intended to be a comprehensive security analysis of threats to Neighbor Discovery as it currently exists today in RFCs 2641 and 2642, according to three different trust models that group current network deployments into three different equivalence classes. As such, it functions as a requirements template for the SEND design team. Text, HTML and XML versions of the draft are available at the interim web page: http://www.tml.hut.fi/~pnr/SEND/ The HTML version is directly available at: http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-psreq-03.html The draft was submitted to the IETF drafts respository today and should show up there shortly. Compared to the version discussed at San Francisco, there is one new threat, the new section 4.2.2. For an easy overview of the differences, see http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-psreq-03-diff.html --Pekka Nikander -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Apr 14 07:02:33 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00557 for ; Mon, 14 Apr 2003 07:02:32 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3EB2pI3026349; Mon, 14 Apr 2003 13:02:52 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2V1ANLJN; Mon, 14 Apr 2003 13:02:38 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h3EB2EsY009443; Mon, 14 Apr 2003 13:02:14 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h3EB28Yl014627; Mon, 14 Apr 2003 13:02:08 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h3EB28iD014626; Mon, 14 Apr 2003 13:02:08 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h3EB27Yl014622 for ; Mon, 14 Apr 2003 13:02:07 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 280A91C; Mon, 14 Apr 2003 14:12:11 +0300 (EEST) Message-ID: <3E9A954C.5000504@nomadiclab.com> Date: Mon, 14 Apr 2003 14:02:36 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Claude Castelluccia Cc: SEND WG Subject: Re: Thoughts about transition mode References: <3E9A7918.9000502@nomadiclab.com> <3E9A81DE.7E05F72E@inrialpes.fr> In-Reply-To: <3E9A81DE.7E05F72E@inrialpes.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Claude Castelluccia wrote: > Pekka Nikander wrote: > >> >> >> 1. Mixed mode. Allow both SEND and legacy nodes. >> SEND nodes are somewhat vulnerable to downgrading >> (aka bidding down) attacks by attackers claiming >> to be legacy nodes. >> > Hello Pekka, > The bidding down attack can be prevented by embedding the > address type in the address itself? Depends on the design details. Currently we (the DT) do not want to make the SEND and non-SEND nodes to live in totally separate name spaces. If we wanted that, the easiest way would be to use a separate link local prefix, and we could use the transition mode as currently defined in -00. However, I don't like that solution, and therefore I wrote the note. Note also that I write "somewhat vulnerable". That is, it looks like the vulnerabilities would probably be quite minor. However, the details need to be worked out before we can really evaluate the situation. > For example if it is decided that legacy addresses have the > lowest bit set to 0 and the SEND addresses have the lowest > bit set to 1, the bidding down attack can not be performed... > > Is that right? As far as I can see, that would fix the problem. In practice, though, we would either need a separate link local prefix or take in to use the u and g bits in the IID. For a number of reasons (some of which I don't even remember), we don't want to do that, if possible. If we need to take the road of having different address spaces for SEND and non-SEND nodes, the easiest way is probably to allocate a second link local prefix for SEND nodes, and to use different routing prefixes for SEND and non-SEND nodes. Then we would have two logically completely different links, just like what is currently defined in the draft. The biggest problem with the separate link local prefix is that SEND nodes would not be able to talk to non-SEND nodes without the help of a router. That would make the transition harder, requiring the routers to be updated first, since one could not be able to use SEND before there is a router that supports SEND. With the mixed mode, one can use SEND independent on whether there is a SEND capable router or not. I don't remember the problems with u and g, but I think they were more related to the difficulty of assigning the bits than anything technical. --Pekka Nikander -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Apr 15 07:27:07 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22861 for ; Tue, 15 Apr 2003 07:27:07 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3FBIRI4023173; Tue, 15 Apr 2003 13:18:30 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2V1A5NZP; Tue, 15 Apr 2003 13:17:39 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h3FBGxsY018905; Tue, 15 Apr 2003 13:16:59 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h3FBGJYl026133; Tue, 15 Apr 2003 13:16:19 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h3FBGJis026132; Tue, 15 Apr 2003 13:16:19 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h3FBGHYl026125 for ; Tue, 15 Apr 2003 13:16:18 +0200 (MET DST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21966; Tue, 15 Apr 2003 07:13:36 -0400 (EDT) Message-Id: <200304151113.HAA21966@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-send@standards.ericsson.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-send-psreq-03.txt Date: Tue, 15 Apr 2003 07:13:36 -0400 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Securing Neighbor Discovery Working Group of the IETF. Title : IPv6 Neighbor Discovery trust models and threats Author(s) : P. Nikander et al. Filename : draft-ietf-send-psreq-03.txt Pages : 29 Date : 2003-4-14 The existing IETF standards specify that IPv6 Neighbor Discovery and Address Autoconfiguration mechanisms MAY be protected with IPsec AH. However, the current specifications limit the security solutions to manual keying due to practical problems faced with automatic key management. This document specifies three different trust models and discusses the threats pertinent to IPv6 Neighbor Discovery. The purpose of this discussion is to define the requirements for Securing IPv6 Neighbor Discovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-send-psreq-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-send-psreq-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-send-psreq-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-14131150.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-send-psreq-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-send-psreq-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-14131150.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Apr 15 07:40:50 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23634 for ; Tue, 15 Apr 2003 07:40:49 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3FBbOSG010733; Tue, 15 Apr 2003 13:37:29 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2VAMW7GQ; Tue, 15 Apr 2003 13:36:38 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h3FBZtsY019308; Tue, 15 Apr 2003 13:35:55 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h3FBZhYl028239; Tue, 15 Apr 2003 13:35:43 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.8/8.12.8/Submit) id h3FBZhMJ028238; Tue, 15 Apr 2003 13:35:43 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.8/8.12.8/unixcenter-xnetx-1.0) with ESMTP id h3FBZgYl028234 for ; Tue, 15 Apr 2003 13:35:42 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 8A30D1C; Tue, 15 Apr 2003 14:45:43 +0300 (EEST) Message-ID: <3E9BEEA9.8010609@nomadiclab.com> Date: Tue, 15 Apr 2003 14:36:09 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Cc: ietf-send@standards.ericsson.net Subject: Re: Separate WG Draft for CGAs? References: <019901c2fad4$55029ac0$036015ac@T23KEMPF> In-Reply-To: <019901c2fad4$55029ac0$036015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit James Kempf wrote: > Folks, > > There was some interest expressed prior to and at the last meeting in SFO for > separating out CGAs. The original reason was IPR considerations, but, from a > practical standpoint, Tuomas Aurea has already done a very nice job of > specifying a CGA algorithm in > http://www.ietf.org/internet-drafts/draft-aura-cga-00.txt. Rather than have to > edit Tuomas' text into the base SEND draft, Pekka and I thought it might be > easier to make Tuomas' draft a WG draft and refer to it in the base draft. > > Any objections or other comments? Since there were no objections, we decided to take Tuomas' draft as a WG item. The WG milestones have been updated accordingly. The WG now needs to start editing the draft so that it fits in to the purposes of the working group, and all that is not needed is either removed or moved into an appendix. I will produce an initial issue list, probably later this week or early next week. --Pekka Nikander -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Apr 17 16:05:52 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05772 for ; Thu, 17 Apr 2003 16:05:51 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3HK0jI3021873; Thu, 17 Apr 2003 22:00:46 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id JBS0PRV8; Thu, 17 Apr 2003 22:00:45 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h3HK0dsY008779; Thu, 17 Apr 2003 22:00:39 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3HJwVWI010425; Thu, 17 Apr 2003 21:58:31 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h3HJwVRl010419; Thu, 17 Apr 2003 21:58:31 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from usa.net (pc1-ayle1-4-cust220.wtfd.cable.ntl.com [80.3.25.220]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with SMTP id h3HJvYWI010385 for ; Thu, 17 Apr 2003 21:57:54 +0200 (MET DST) Message-ID: From: To: bill.brown@standards.ericsson.net Subject: Toner Cartridge Prices-per your request Date: Fri, 18 Apr 2003 06:53:00 -1100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_7D6_D929_C31E5D80.BA4929D3" X-Priority: 3 User-Agent: Microsoft Outlook Express 6.00.2600.0000 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk ------=_NextPart_7D6_D929_C31E5D80.BA4929D3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_7D6_D929_C31E5D80.BA4929D3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable fgfg
 

VERTEX LASER AND 

COPIER SUPPLIES
 
TAKE ADVANTAGE OF THE SAVINGS WHILE THEY LAST!!!

SPECIAL PRICING ON

PRINTER AND COPIER SUPPLIES
 

 ORDER BY PHONE: 1-888-288-9043
ORDER BY FAX: 1-888-977-1577

***EMAIL REMOVAL LINE: 1-888-248-4930***

 PLEASE ORDER BY PAGE NUMBER AND/OR ITEM NUMBER
 
 

      For Hewlett Packard Printers: (Page 2)
ITEM
 DESCRIPTION
MFG #
PRICE
Item #1
Laserjet Series 4L, 4P 
 92274A
$44
Item #2
Laserjet Series 1100,3200
 C4092
 $44
Item #3
 Laserjet Series  2
  92295A
  $49
 Item # 4
 Laserjet Series  2P
 92275A
  $54
 Item #5
 Laserjet Series 5P,6P, 5MP, 6MP
 3603A
 $44
Item #6
 Laserjet Series 5SI,8000
 3909A
$95
 Item #7 
 Laserjet Series 2100, 2200 
 C4096
 $74
 Item #8
 Laserjet Series 8100
 C4182
 $115
 Item #9
Laserjet Series 5L/6L
 3906A
 $39
 Item #10 
Laserjet Series  4V
C3900 
 $95
 Item #11
Laserjet Series 4000
C4127X
 $79
 Item #12
Laserjet Series 3SI/4SI
 92291A 
$54
 Item #13
Laserjet Series 4,4M,5,5M 
92298A
$49
 Item #13A
Laserjet Series 5000
C4129X
$125
 Item #13B
Laserjet Series 1200,3300
C7115A
$59
 Item #13C
Laserjet Series 4100
C8061X
$99
 Item #18
Laserjet Series  3100
3906A
$39
 Item #19
Laserjet Series 4500 Black
C4191 
$69
 Item #20
Laserjet Series 4500 Color
CALL
$89
 
For Hewlett Packand Canon Fax (on Page 2)
ITEM
DESCRIPTION
MFG #
PRICE
Item # 14
Leserfax 500, 700
FX1
$59
Item # 15
Laserfax 5000, 7000
FX2
$64
Item # 16
Laserfax 6000
FX3
$59
Item #17
Laserfax 8500, 9000
FX4
$54
Item #18
Laserfax 3200
3906A
$44

For Lexmark / IBM Machines: (on Page 3)
  ITEM
DESCRIPTION
MFG #
PRICE
Item #1
IBM 4019/4029 
1380200 
$95
Item #2
Optra R,4039, 4049
1382150
$117
Item #3
Optra E310, E312
 12A2202
$89
Item #4
Optra E
 69G8256 
$59
Item #5
Optra S
 1382625 
$135
Item #6
Optra T
  12A5840
$165
Item #7
Optra E410/412
  4K00198 
$115

For Apple Printers: (on Page 8)
ITEM
DESCRIPTION
MFG#
PRICE
Item  #1
Personal LaserWriter
M0089LLA
$54
Item #2
LaserWriter 300PX/ 320-4L,+4ML
M2045GA
$54
Item #3
LaserWriter Select 360
M1960GA
$74
Item #4
LaserWriter 16/ 600 Pro 
M2473GA
$59
Item #5
LaserWriter 12/ 640 PS
M4683GA 
$89
Item #6
Laser Writer NT/2NT
M4532GA
$49

  For Canon Copiers: (Page 10)
ITEM
DESCRIPTION
MFG #
PRICE
Item # 1
PC 6/ 6RE/ 7/ 8/ 11/ 12/ 65
 A30 
$69
Item # 2
PC 300/320/340/360  All 300 Series
 E40 
$89
Item #3
PC 700/720/760  All 700 Series
 E40 
$89
Item #4
PC 900/910/920  All 900 Series
 E40
$89

For Epson and Panasonic Printers:(on Pages 4 & 7)
ITEM
 DESCRIPTION
MFG #
PRICE
Item # 1
Epson 1000/1500
S051011 
$105
Item #2 
Epson EPL7000/8000 
S051200 
$105 
Item #3
Panasonic 90/95 
----------------
$105

 
 
 

NOTES:

University and School Purchase orders welcome. (No Credit approval required. All other Purchase
    orders require credit approval
 Pay by check (C.O.D.), Credit card or purchase order (Net 30 Days)
Shipping charges start at $4.5 per cartridge. Add $1.5 for each additional cartridge. Cartridges
    delivered by Federal Express within 2 to 5 working days depending on your location.
Shipping and billing addresses are required for Purchase Order transactions. Your invoice will
    be attached to your packaging. Please peal and pay within 30 days.
30 day standard return policy (money back guarantee) on all merchandise. 90 day unlimited exchange policy
    for defective merchandise.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

We do not carry:

    - Xerox, Brother, Panasonic, or Fujitsu Products
    - Deskjet/Inkjet or Bubblejet products
     -Any Offbrands besides the ones listed above. All cartridges
          are compatible high yield products.
 
 

DISCLAIMERS:

     All trademarks, brand names and diagrams listed or shown above
are property of their respective holders   and used for descriptive purposes only
.We do not carry any HP OEM  Products.









































------=_NextPart_7D6_D929_C31E5D80.BA4929D3-- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Apr 18 20:13:35 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02117 for ; Fri, 18 Apr 2003 20:13:34 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3J0ClI3026825; Sat, 19 Apr 2003 02:12:47 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id JDVHHB8N; Sat, 19 Apr 2003 02:12:48 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h3J0Cj220783; Sat, 19 Apr 2003 02:12:45 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3J0BaWI012814; Sat, 19 Apr 2003 02:11:36 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h3J0Bar0012813; Sat, 19 Apr 2003 02:11:36 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from usa.net ([210.99.78.3]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with SMTP id h3J0BIWI012800 for ; Sat, 19 Apr 2003 02:11:27 +0200 (MET DST) Message-ID: From: To: bill.brown@standards.ericsson.net Subject: Toner Cartridge Prices-per your request Date: Fri, 18 Apr 2003 23:52:15 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_32E_A3A0_A71D2053.C34598FC" X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk ------=_NextPart_32E_A3A0_A71D2053.C34598FC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_32E_A3A0_A71D2053.C34598FC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable fgfg

 

VERTEX LASER AND 

COPIER SUPPLIES
 
TAKE ADVANTAGE OF THE SAVINGS WHILE THEY LAST!!!

SPECIAL PRICING ON

PRINTER AND COPIER SUPPLIES
 

 ORDER BY PHONE: 1-888-288-9043
ORDER BY FAX: 1-888-977-1577

***EMAIL REMOVAL LINE: 1-888-248-4930***

 PLEASE ORDER BY PAGE NUMBER AND/OR ITEM NUMBER
 
 

      For Hewlett Packard Printers: (Page 2)
ITEM
 DESCRIPTION
MFG #
PRICE
Item #1
Laserjet Series 4L, 4P 
 92274A
$44
Item #2
Laserjet Series 1100,3200
 C4092
 $44
Item #3
 Laserjet Series  2
  92295A
  $49
 Item # 4
 Laserjet Series  2P
 92275A
  $54
 Item #5
 Laserjet Series 5P,6P, 5MP, 6MP
 3603A
 $44
Item #6
 Laserjet Series 5SI,8000
 3909A
$95
 Item #7 
 Laserjet Series 2100, 2200 
 C4096
 $74
 Item #8
 Laserjet Series 8100
 C4182
 $115
 Item #9
Laserjet Series 5L/6L
 3906A
 $39
 Item #10 
Laserjet Series  4V
C3900 
 $95
 Item #11
Laserjet Series 4000
C4127X
 $79
 Item #12
Laserjet Series 3SI/4SI
 92291A 
$54
 Item #13
Laserjet Series 4,4M,5,5M 
92298A
$49
 Item #13A
Laserjet Series 5000
C4129X
$125
 Item #13B
Laserjet Series 1200,3300
C7115A
$59
 Item #13C
Laserjet Series 4100
C8061X
$99
 Item #18
Laserjet Series  3100
3906A
$39
 Item #19
Laserjet Series 4500 Black
C4191 
$69
 Item #20
Laserjet Series 4500 Color
CALL
$89
 
For Hewlett Packand Canon Fax (on Page 2)
ITEM
DESCRIPTION
MFG #
PRICE
Item # 14
Leserfax 500, 700
FX1
$59
Item # 15
Laserfax 5000, 7000
FX2
$64
Item # 16
Laserfax 6000
FX3
$59
Item #17
Laserfax 8500, 9000
FX4
$54
Item #18
Laserfax 3200
3906A
$44

For Lexmark / IBM Machines: (on Page 3)
  ITEM
DESCRIPTION
MFG #
PRICE
Item #1
IBM 4019/4029 
1380200 
$95
Item #2
Optra R,4039, 4049
1382150
$117
Item #3
Optra E310, E312
 12A2202
$89
Item #4
Optra E
 69G8256 
$59
Item #5
Optra S
 1382625 
$135
Item #6
Optra T
  12A5840
$165
Item #7
Optra E410/412
  4K00198 
$115

For Apple Printers: (on Page 8)
ITEM
DESCRIPTION
MFG#
PRICE
Item  #1
Personal LaserWriter
M0089LLA
$54
Item #2
LaserWriter 300PX/ 320-4L,+4ML
M2045GA
$54
Item #3
LaserWriter Select 360
M1960GA
$74
Item #4
LaserWriter 16/ 600 Pro 
M2473GA
$59
Item #5
LaserWriter 12/ 640 PS
M4683GA 
$89
Item #6
Laser Writer NT/2NT
M4532GA
$49

  For Canon Copiers: (Page 10)
ITEM
DESCRIPTION
MFG #
PRICE
Item # 1
PC 6/ 6RE/ 7/ 8/ 11/ 12/ 65
 A30 
$69
Item # 2
PC 300/320/340/360  All 300 Series
 E40 
$89
Item #3
PC 700/720/760  All 700 Series
 E40 
$89
Item #4
PC 900/910/920  All 900 Series
 E40
$89

For Epson and Panasonic Printers:(on Pages 4 & 7)
ITEM
 DESCRIPTION
MFG #
PRICE
Item # 1
Epson 1000/1500
S051011 
$105
Item #2 
Epson EPL7000/8000 
S051200 
$105 
Item #3
Panasonic 90/95 
----------------
$105

 
 
 

NOTES:

University and School Purchase orders welcome. (No Credit approval required. All other Purchase
    orders require credit approval
 Pay by check (C.O.D.), Credit card or purchase order (Net 30 Days)
Shipping charges start at $4.5 per cartridge. Add $1.5 for each additional cartridge. Cartridges
    delivered by Federal Express within 2 to 5 working days depending on your location.
Shipping and billing addresses are required for Purchase Order transactions. Your invoice will
    be attached to your packaging. Please peal and pay within 30 days.
30 day standard return policy (money back guarantee) on all merchandise. 90 day unlimited exchange policy
    for defective merchandise.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

We do not carry:

    - Xerox, Brother, Panasonic, or Fujitsu Products
    - Deskjet/Inkjet or Bubblejet products
     -Any Offbrands besides the ones listed above. All cartridges
          are compatible high yield products.
 
 

DISCLAIMERS:

     All trademarks, brand names and diagrams listed or shown above
are property of their respective holders   and used for descriptive purposes only
.We do not carry any HP OEM  Products.









































------=_NextPart_32E_A3A0_A71D2053.C34598FC-- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Apr 20 08:42:38 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03934 for ; Sun, 20 Apr 2003 08:42:38 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3KCaxRs008508; Sun, 20 Apr 2003 14:36:59 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id JBS153QP; Sun, 20 Apr 2003 14:36:58 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h3KCaosY006858; Sun, 20 Apr 2003 14:36:50 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3KCZmWI008739; Sun, 20 Apr 2003 14:35:48 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h3KCZmxd008738; Sun, 20 Apr 2003 14:35:48 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from usa.net ([61.236.246.126]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with SMTP id h3KCYYWI008695 for ; Sun, 20 Apr 2003 14:35:28 +0200 (MET DST) Message-ID: From: To: Adam.Block@standards.ericsson.net Subject: Toner Cartridge Prices-per your request Date: Sun, 20 Apr 2003 07:14:59 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_965_8617_5C20B933.C6FC7C60" X-Priority: 3 User-Agent: Microsoft Outlook Express 5.50.4522.1200 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk ------=_NextPart_965_8617_5C20B933.C6FC7C60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_965_8617_5C20B933.C6FC7C60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable fgfg

 

VERTEX LASER AND 

COPIER SUPPLIES
 
TAKE ADVANTAGE OF THE SAVINGS WHILE THEY LAST!!!

SPECIAL PRICING ON

PRINTER AND COPIER SUPPLIES
 

 ORDER BY PHONE: 1-888-288-9043
ORDER BY FAX: 1-888-977-1577

***EMAIL REMOVAL LINE: 1-888-248-4930***

 PLEASE ORDER BY PAGE NUMBER AND/OR ITEM NUMBER
 
 

      For Hewlett Packard Printers: (Page 2)
ITEM
 DESCRIPTION
MFG #
PRICE
Item #1
Laserjet Series 4L, 4P 
 92274A
$44
Item #2
Laserjet Series 1100,3200
 C4092
 $44
Item #3
 Laserjet Series  2
  92295A
  $49
 Item # 4
 Laserjet Series  2P
 92275A
  $54
 Item #5
 Laserjet Series 5P,6P, 5MP, 6MP
 3603A
 $44
Item #6
 Laserjet Series 5SI,8000
 3909A
$95
 Item #7 
 Laserjet Series 2100, 2200 
 C4096
 $74
 Item #8
 Laserjet Series 8100
 C4182
 $115
 Item #9
Laserjet Series 5L/6L
 3906A
 $39
 Item #10 
Laserjet Series  4V
C3900 
 $95
 Item #11
Laserjet Series 4000
C4127X
 $79
 Item #12
Laserjet Series 3SI/4SI
 92291A 
$54
 Item #13
Laserjet Series 4,4M,5,5M 
92298A
$49
 Item #13A
Laserjet Series 5000
C4129X
$125
 Item #13B
Laserjet Series 1200,3300
C7115A
$59
 Item #13C
Laserjet Series 4100
C8061X
$99
 Item #18
Laserjet Series  3100
3906A
$39
 Item #19
Laserjet Series 4500 Black
C4191 
$69
 Item #20
Laserjet Series 4500 Color
CALL
$89
 
For Hewlett Packand Canon Fax (on Page 2)
ITEM
DESCRIPTION
MFG #
PRICE
Item # 14
Leserfax 500, 700
FX1
$59
Item # 15
Laserfax 5000, 7000
FX2
$64
Item # 16
Laserfax 6000
FX3
$59
Item #17
Laserfax 8500, 9000
FX4
$54
Item #18
Laserfax 3200
3906A
$44

For Lexmark / IBM Machines: (on Page 3)
  ITEM
DESCRIPTION
MFG #
PRICE
Item #1
IBM 4019/4029 
1380200 
$95
Item #2
Optra R,4039, 4049
1382150
$117
Item #3
Optra E310, E312
 12A2202
$89
Item #4
Optra E
 69G8256 
$59
Item #5
Optra S
 1382625 
$135
Item #6
Optra T
  12A5840
$165
Item #7
Optra E410/412
  4K00198 
$115

For Apple Printers: (on Page 8)
ITEM
DESCRIPTION
MFG#
PRICE
Item  #1
Personal LaserWriter
M0089LLA
$54
Item #2
LaserWriter 300PX/ 320-4L,+4ML
M2045GA
$54
Item #3
LaserWriter Select 360
M1960GA
$74
Item #4
LaserWriter 16/ 600 Pro 
M2473GA
$59
Item #5
LaserWriter 12/ 640 PS
M4683GA 
$89
Item #6
Laser Writer NT/2NT
M4532GA
$49

  For Canon Copiers: (Page 10)
ITEM
DESCRIPTION
MFG #
PRICE
Item # 1
PC 6/ 6RE/ 7/ 8/ 11/ 12/ 65
 A30 
$69
Item # 2
PC 300/320/340/360  All 300 Series
 E40 
$89
Item #3
PC 700/720/760  All 700 Series
 E40 
$89
Item #4
PC 900/910/920  All 900 Series
 E40
$89

For Epson and Panasonic Printers:(on Pages 4 & 7)
ITEM
 DESCRIPTION
MFG #
PRICE
Item # 1
Epson 1000/1500
S051011 
$105
Item #2 
Epson EPL7000/8000 
S051200 
$105 
Item #3
Panasonic 90/95 
----------------
$105

 
 
 

NOTES:

University and School Purchase orders welcome. (No Credit approval required. All other Purchase
    orders require credit approval
 Pay by check (C.O.D.), Credit card or purchase order (Net 30 Days)
Shipping charges start at $4.5 per cartridge. Add $1.5 for each additional cartridge. Cartridges
    delivered by Federal Express within 2 to 5 working days depending on your location.
Shipping and billing addresses are required for Purchase Order transactions. Your invoice will
    be attached to your packaging. Please peal and pay within 30 days.
30 day standard return policy (money back guarantee) on all merchandise. 90 day unlimited exchange policy
    for defective merchandise.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

We do not carry:

    - Xerox, Brother, Panasonic, or Fujitsu Products
    - Deskjet/Inkjet or Bubblejet products
     -Any Offbrands besides the ones listed above. All cartridges
          are compatible high yield products.
 
 

DISCLAIMERS:

     All trademarks, brand names and diagrams listed or shown above
are property of their respective holders   and used for descriptive purposes only
.We do not carry any HP OEM  Products.









































------=_NextPart_965_8617_5C20B933.C6FC7C60-- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Apr 22 05:43:02 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01333 for ; Tue, 22 Apr 2003 05:43:01 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3M9gBI3007652; Tue, 22 Apr 2003 11:42:11 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id JDV2QN75; Tue, 22 Apr 2003 11:42:12 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h3M9eKsY003677; Tue, 22 Apr 2003 11:40:20 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3M9dPWI017363; Tue, 22 Apr 2003 11:39:25 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h3M9dOxx017362; Tue, 22 Apr 2003 11:39:24 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3M9dNWI017358 for ; Tue, 22 Apr 2003 11:39:23 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 125B41C for ; Tue, 22 Apr 2003 12:49:22 +0300 (EEST) Message-ID: <3EA50DE9.1060308@nomadiclab.com> Date: Tue, 22 Apr 2003 12:39:53 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: Question: SEND deployment scenarios with certificates Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit This is a question from the Design Team to the Working Group. We solicit input for the design task. The current SEND design is primarily based on the idea of using CGA to authorize hosts to use their IP addresses. While CGA requires no configuration and scales well, we understand that some people want to use certificates to authorize hosts. The purpose of this message is to solicit discussion and information on deployment scenarios. The goal is to help us to really understand how host certifactes would be used and what information they shoud contain. To structure the discussion, I've included a number of questions, based on my strawman analysis of the situation. The questions can be found below, after the brief explanation of the current situation. Current thinking at the design team ----------------------------------- The design team has tentatively decided to use RFC 3281 authorization certitifates as the mandatory mechanism for certifying routers. For SEND purposes, there would be a new extension, enumerating the prefixes that the router is authorized to advertise. In the case that the issuer of a certificate does not want to specify prefixes but just indicate that the node in question is a SEND router, the prefix of ::/0 is used. In effect, that indicates that a router is authorized to advertise any prefixes, and therefore it is a router and not just a host. The usual mechanisms for checking authorization chains are planned to be used. The question now raises how to certify hosts. While routers are implicitly assumed to be trustworthy enough to select their own addresses, hosts cannot be. (This follows the assumptions of the second trust model in the psreq draft.) Thus, a host certificate apparently should include information that allows other hosts to decide whether a given host is authorized to use a certain address or not. The limitation of requiring the certificates to contain information about addresses seem to enforce us to a situation where certificates would only be used in static high security environments. However, it is unclear if there is any real need to use certificates in other environements, and if so, what are the tradeoffs. From a strawman economic analysis point of view, issuing host specific authorization certificates is fairly expensive in terms of required administrative effort. Thus, it seems plausible to assume that in most cases they would not be used in typical commercial environments. But is it so? What kind of deployment scenarios can people see? What do the economic factors play in these scenarios? (See below for the concrete questions.) Questions --------- [In a way, the questions below are presented in a "reverse" order, starting from the technically most specific and going towards more generic questions concerning deployment. If you have a specific deployment scenario in mind, it may make sense to process the questions in reverse order.] 1. Certificate format and representing addresses in certificates The current design team thinking leans towards using RFC3281 as the mandatory mechanism, and specifying hosts using the same extension as routers, but requiring that the prefix contained is an address, i.e., that the prefix is exactly 128 bits long. This would allow the routers, or some other authorized party holding such an certificate, to issue certificates to hosts as a part of an automatic process. It also follows the idea that a certificate gives a node an authority to assign addresses within the scope of the specified prefix. There remains the problem of link local addresses, though. It looks like only a local router can issue certificates for link local addresses. There cannot be any specific authorization for link local addresses for any link, since the prefix is always the same. Thus, anyone certified as a router can, in principle, further delegate the right to use link local addresses. On the other hand, is there any benefit from using certificates for link local addresses? Would it be better to use always use CGA for link local addresses? 1.1) Would RFC3281 be OK for host certificates? 1.2) Is the idea for using /128 bit prefixes for hosts OK? 1.3) How should link local addresses be certified, or would CGA be enough for them? 1.4) Is it necessary to certify the whole address (as we currently assume), or would it be enough to certify just an interface ID? 2. Precedence between CGA and certificates When both CGA and certificates are used, it is possible (but very unlikely) that there would be a collision. The easy approach is to require the CGA host to generate a new address. However, this leads to a variant of the DAD denial-of-service attack. That is, an attacker can simply create certificates for each address that the CGA host generates, and claim to be using them already. If the CGA host simply accepts the certificates without checking that the certificates are signed by a properly authorized key, the attacker could deny access to the CGA host. On the other hand, if the CGA host does check the certificate chain to see that it is properly rooted, an attacker can create very long certificate chains and thereby force the CGA host to spend large amounts of CPU cycles to check the chains. 2.1) How should collisions between CGA and certificates to be handled? 3. Issuing of certificates In a typical case, the hosts are configured to trust a number of root keys to authorize routers and hosts. The authority to act as a router or to use a certain address is then delegated from these keys, typically via intermediaries. Now, depending on the deployment scenario, it may make sense to use different kinds of delegations. Certifying static hosts, such as servers with static IP addresses, seems easy enough. However, there is the problem of handling mobile hosts and address renumbering. 3.1) Who (what node) would issue hosts certificates? 3.2) What kind of authority should that node have? 3.3) How to handle renumbering? 3.4) How to handle mobile hosts? 4. Deployment scenarios All of the questions above really corner around the question of what is the deployment scenario. We (or at least I) can easily understand how to handle the case of static hosts with static addresses and just a few prefixes. In that case, the hosts would be configured with a single certificate authority, and all hosts would be issued with a direct certificate, explicitly enumerating their addresses, the link local address included. Alternatively, instead of having direct certificates, there might be a short certificate chain, consisting of maybe 1 or 2 intermediary CAs. However, what I don't understand, and what we would like to understand better are alternative scenarios. How people would actually use host certificates in SEND. Here we are open to suggestions, and I haven't written down any specific questions. --Pekka Nikander on the behalf of the DT -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Apr 22 07:32:22 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03027 for ; Tue, 22 Apr 2003 07:32:22 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3MBWXRs001009; Tue, 22 Apr 2003 13:32:33 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id JBTA3GB4; Tue, 22 Apr 2003 13:32:35 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h3MBWWsY006191; Tue, 22 Apr 2003 13:32:32 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3MBW9WI000782; Tue, 22 Apr 2003 13:32:09 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h3MBW99f000781; Tue, 22 Apr 2003 13:32:09 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3MBW8WI000777 for ; Tue, 22 Apr 2003 13:32:08 +0200 (MET DST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3MBW7j08086; Tue, 22 Apr 2003 14:32:07 +0300 Date: Tue, 22 Apr 2003 14:32:06 +0300 (EEST) From: Pekka Savola To: Pekka Nikander cc: SEND WG Subject: Re: Question: SEND deployment scenarios with certificates In-Reply-To: <3EA50DE9.1060308@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk On Tue, 22 Apr 2003, Pekka Nikander wrote: > This is a question from the Design Team to the Working > Group. We solicit input for the design task. IMO, it's too early to answer most questions. Please work on resolving the IPR issue with Microsoft first and/or declare attempts unsuccesful. Thanks. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Apr 22 09:42:33 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08979 for ; Tue, 22 Apr 2003 09:42:33 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3MDhGI3020142; Tue, 22 Apr 2003 15:43:16 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id JN7B5AL1; Tue, 22 Apr 2003 15:43:17 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h3MDhF219869; Tue, 22 Apr 2003 15:43:15 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3MDgiWI015053; Tue, 22 Apr 2003 15:42:44 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h3MDghON015052; Tue, 22 Apr 2003 15:42:43 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3MDggWI015048 for ; Tue, 22 Apr 2003 15:42:42 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id AC3371C; Tue, 22 Apr 2003 16:52:42 +0300 (EEST) Message-ID: <3EA546F2.1080502@nomadiclab.com> Date: Tue, 22 Apr 2003 16:43:14 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Cc: SEND WG Subject: Re: Question: SEND deployment scenarios with certificates References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > Please work on resolving the IPR issue with Microsoft first and/or > declare attempts unsuccesful. IMHO this is mostly independent on the IPR issues. Or at least one way to restate the question is that how would *you* use host certificates even if you can use CGA without IPR worries. That is, if you have administrative reasons that mandate you to use certificates, what would those be? --Pekka Nikander -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Apr 22 14:17:43 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19320 for ; Tue, 22 Apr 2003 14:17:42 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3MIHVRs012209; Tue, 22 Apr 2003 20:17:32 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id J3B1GWVR; Tue, 22 Apr 2003 20:17:33 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h3MIHTsY012749; Tue, 22 Apr 2003 20:17:29 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3MIGwWI016568; Tue, 22 Apr 2003 20:16:58 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h3MIGwMU016567; Tue, 22 Apr 2003 20:16:58 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3MIGtWI016560 for ; Tue, 22 Apr 2003 20:16:56 +0200 (MET DST) Message-ID: <01af01c308fb$1c384890$766015ac@DCLKEMPFTP> From: "James Kempf" To: "Pekka Nikander" , "SEND WG" References: <3EA50DE9.1060308@nomadiclab.com> Subject: Re: Question: SEND deployment scenarios with certificates Date: Tue, 22 Apr 2003 11:15:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pekka, Though I can't claim to have any large deployment insight, I don't see host certs, other than the self-signed certs that Tumos specifies for CGA, as playing a large role in the near future. The "end host cert provisioning problem" (often subsumed under the name "global PKI") is a major bottleneck right now for reliable, end to end security, and I don't see much on the horizon that could help resolve it. For initial deployments of SEND, I see routers being provisioned with certs and hosts being provisioned with root CA certs, which they then use to validate the routers. This is isomorphic to the "host with collection of root CA certs authenticates server" model that has proven deployable in the Web. CGA is important because it provides security on ND when this model is used for RD, thus avoiding the need for end host certs. This doesn't mean that the SEND spec should ignore end host certs, but I believe the assumptions it makes about them should be fairly conservative, to avoid locking something in that might not be deployed. Further down the road, if the end host cert provisioning problem is solved, certs for end hosts might become more deployable. One possible step in that direction is some design work getting started in 3GPP to use their SIM-based AAA to deploy end host cert distribution. This might help to bootstrap end host PKI. jak ----- Original Message ----- From: "Pekka Nikander" To: "SEND WG" Sent: Tuesday, April 22, 2003 2:39 AM Subject: Question: SEND deployment scenarios with certificates > This is a question from the Design Team to the Working > Group. We solicit input for the design task. > > The current SEND design is primarily based on the idea > of using CGA to authorize hosts to use their IP addresses. > While CGA requires no configuration and scales well, > we understand that some people want to use certificates > to authorize hosts. > > The purpose of this message is to solicit discussion and > information on deployment scenarios. The goal is to help > us to really understand how host certifactes would be used > and what information they shoud contain. To structure > the discussion, I've included a number of questions, > based on my strawman analysis of the situation. The > questions can be found below, after the brief explanation > of the current situation. > > Current thinking at the design team > ----------------------------------- > > The design team has tentatively decided to use RFC 3281 > authorization certitifates as the mandatory mechanism > for certifying routers. For SEND purposes, there would be > a new extension, enumerating the prefixes that the router > is authorized to advertise. In the case that the issuer of > a certificate does not want to specify prefixes but just > indicate that the node in question is a SEND router, the > prefix of ::/0 is used. In effect, that indicates that > a router is authorized to advertise any prefixes, and > therefore it is a router and not just a host. The usual > mechanisms for checking authorization chains are planned > to be used. > > The question now raises how to certify hosts. While > routers are implicitly assumed to be trustworthy enough > to select their own addresses, hosts cannot be. (This > follows the assumptions of the second trust model in the > psreq draft.) Thus, a host certificate apparently should > include information that allows other hosts to decide > whether a given host is authorized to use a certain > address or not. > > The limitation of requiring the certificates to contain > information about addresses seem to enforce us to a > situation where certificates would only be used in static > high security environments. However, it is unclear if there > is any real need to use certificates in other environements, > and if so, what are the tradeoffs. > > From a strawman economic analysis point of view, issuing > host specific authorization certificates is fairly expensive > in terms of required administrative effort. Thus, it seems > plausible to assume that in most cases they would not be used > in typical commercial environments. But is it so? What > kind of deployment scenarios can people see? What do the > economic factors play in these scenarios? (See below for > the concrete questions.) > > Questions > --------- > > [In a way, the questions below are presented in a "reverse" > order, starting from the technically most specific and > going towards more generic questions concerning deployment. > If you have a specific deployment scenario in mind, it may > make sense to process the questions in reverse order.] > > 1. Certificate format and representing addresses in certificates > > The current design team thinking leans towards using > RFC3281 as the mandatory mechanism, and specifying hosts > using the same extension as routers, but requiring that > the prefix contained is an address, i.e., that the prefix > is exactly 128 bits long. > > This would allow the routers, or some other authorized > party holding such an certificate, to issue certificates > to hosts as a part of an automatic process. It also follows > the idea that a certificate gives a node an authority to > assign addresses within the scope of the specified prefix. > > There remains the problem of link local addresses, though. > It looks like only a local router can issue certificates > for link local addresses. There cannot be any specific > authorization for link local addresses for any link, since > the prefix is always the same. Thus, anyone certified as > a router can, in principle, further delegate the right to > use link local addresses. On the other hand, is there any > benefit from using certificates for link local addresses? > Would it be better to use always use CGA for link local > addresses? > > 1.1) Would RFC3281 be OK for host certificates? > 1.2) Is the idea for using /128 bit prefixes for hosts OK? > 1.3) How should link local addresses be certified, or > would CGA be enough for them? > 1.4) Is it necessary to certify the whole address (as we > currently assume), or would it be enough to certify > just an interface ID? > > 2. Precedence between CGA and certificates > > When both CGA and certificates are used, it is possible > (but very unlikely) that there would be a collision. > The easy approach is to require the CGA host to generate > a new address. However, this leads to a variant of the > DAD denial-of-service attack. That is, an attacker can > simply create certificates for each address that the CGA > host generates, and claim to be using them already. If > the CGA host simply accepts the certificates without > checking that the certificates are signed by a properly > authorized key, the attacker could deny access to the CGA > host. On the other hand, if the CGA host does check the > certificate chain to see that it is properly rooted, an > attacker can create very long certificate chains and > thereby force the CGA host to spend large amounts of > CPU cycles to check the chains. > > 2.1) How should collisions between CGA and certificates > to be handled? > > 3. Issuing of certificates > > In a typical case, the hosts are configured to trust > a number of root keys to authorize routers and hosts. > The authority to act as a router or to use a certain > address is then delegated from these keys, typically > via intermediaries. > > Now, depending on the deployment scenario, it may make > sense to use different kinds of delegations. Certifying > static hosts, such as servers with static IP addresses, > seems easy enough. However, there is the problem of > handling mobile hosts and address renumbering. > > 3.1) Who (what node) would issue hosts certificates? > 3.2) What kind of authority should that node have? > 3.3) How to handle renumbering? > 3.4) How to handle mobile hosts? > > 4. Deployment scenarios > > All of the questions above really corner around the > question of what is the deployment scenario. We > (or at least I) can easily understand how to handle > the case of static hosts with static addresses and > just a few prefixes. In that case, the hosts would be > configured with a single certificate authority, and > all hosts would be issued with a direct certificate, > explicitly enumerating their addresses, the link local > address included. Alternatively, instead of having > direct certificates, there might be a short certificate > chain, consisting of maybe 1 or 2 intermediary CAs. > > However, what I don't understand, and what we would > like to understand better are alternative scenarios. > How people would actually use host certificates in SEND. > Here we are open to suggestions, and I haven't written > down any specific questions. > > --Pekka Nikander > on the behalf of the DT > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Apr 23 03:53:53 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06782 for ; Wed, 23 Apr 2003 03:53:53 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3N7rqRs013919; Wed, 23 Apr 2003 09:53:52 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id JN9V71RF; Wed, 23 Apr 2003 09:53:53 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h3N7rosY019887; Wed, 23 Apr 2003 09:53:50 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3N7rEWI003290; Wed, 23 Apr 2003 09:53:14 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h3N7rEfw003289; Wed, 23 Apr 2003 09:53:14 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from outgoing.com ([216.133.0.252]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3N7rCWI003282 for ; Wed, 23 Apr 2003 09:53:12 +0200 (MET DST) Received: from alansis.com (unverified [192.168.1.165]) by outgoing.com with ESMTP id 112536 for ; Wed, 23 Apr 2003 00:56:10 -0800 Message-ID: <4120034323751693@alansis.com> X-EM-Version: 5, 0, 0, 19 X-EM-Registration: #00E05309100313001C00 From: "Alansis" To: "ietf-send@standards.ericsson.net" Subject: ADV: 20% off 902,468 leads! Date: Wed, 23 Apr 2003 00:51:06 -0700 MIME-Version: 1.0 Content-Type: text/html; charset=US-ASCII X-Server: High Performance Mail Server - http://surgemail.com Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Alansis
1. Log on to www.alansis.com
2. Enter your password: 271c7e
Alansis is not licensed as a mortgage solicitor, mortgage broker or mortgage lender in any state. Alansis provides a free service to consumers interested in obtaining information regarding mortgage, purchase or debt consolidation loans by introducing consumers to financial professionals.

This e-mail is an advertisement for Alansis sent to you on 4/23/2003 at 12:51:05 AM and is intended to confirm your information. If you would prefer not to receive any additional e-mail information from Alansis, please
click her e. Please allow a reasonable response time not to exceed three (3) days after which you will be removed from our e-mail database.

Alansis is located at 505 Montgomery Street, 11th Floor, San Francisco, CA 94111. Alansis may be contacted by e-mail at support@alansis.com.
-------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Apr 24 02:15:04 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05623 for ; Thu, 24 Apr 2003 02:15:03 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3O6EQI3001766; Thu, 24 Apr 2003 08:14:26 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id JQAF51CV; Thu, 24 Apr 2003 08:14:28 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h3O6EP206770; Thu, 24 Apr 2003 08:14:25 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3O6DWWI018738; Thu, 24 Apr 2003 08:13:32 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h3O6DVfr018737; Thu, 24 Apr 2003 08:13:31 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3O6DUWI018733 for ; Thu, 24 Apr 2003 08:13:30 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 888411C; Thu, 24 Apr 2003 09:23:28 +0300 (EEST) Message-ID: <3EA780A8.1080300@nomadiclab.com> Date: Thu, 24 Apr 2003 09:14:00 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Cc: James Kempf , SEND WG Subject: Re: FW: comments on send-ipsec-00 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Alper, Alper Yegin wrote: > I have sent my comments/questions twice on the SEND ML and they are still > not answered. ... > My question #2 is answered by Jari Arkko on the ML, and #4 was answered > during the IETF meeting. Others are still open questions. Many of your questions are still more or less open ones, being discussed at the Design Team. In particular, I am personally unhappy with the currently proposed transition scheme, as I earlier wrote on the mailing list. However, some other people at the Design Team consider the proposed API between AH and ND layers too demanding to implement. Based on my limited implementation experience with KAME I dont' agree with that; in KAME implementing such an API would be fairly easy. However, since I have no implementation experience on other IPsec implementations I have no other chance but to beleive what the others say. Anyway, please allow me to try to briefly answer to your remaining questions. >> - This is a simple, and possibly a dumb question: In what type of networks are >> we concerned about unauthorized nodes sending bogus router advertisements? >> Possibly in public access networks, right? Couldn't we simply prevent client >> hosts from sending RAs by installing filters on the enforcement points (like >> APs in WLAN hotspots)? Any RA sent on the radio network can be dropped. Sure >> it is none of the business of the L2 bridge to do that from an architectural >> point of view, but from a practical point of view...... IMHO such an approach might work, but it is clearly outside the scope of the working group charter. I vaguely remember that we already discussed this at some point of time, didn't we? >> - "If (DAD) clashes are detected >> after three tries, the node is probably under attack, so it should >> shut down and report the situation to an administrator." >> >> Isn't DAD mechanism protected by CGAs as well? How can the attacker produce >> the right cryptographic information to claim 3 different IP addresses in a >> row? As you note above, this was answered by Jari Arkko. To briefly repeat the current situation, it may not be possible to protect DAD with CGA, since AH based CGA requires that the source address is the CGA address. The Design Team is still trying to find the best solution to this. >> - Can the routers still send unsolicited advertisements that can be verified >> by hosts with different Trusted Roots? Or, do they have to unicast a different >> advertisement to each host? As far as I understand the currently proposed design, there are no changes in respect to the functionality here. So, the routers can still send unsolicitated advertisements. >> - "One effect of this is that secure hosts can not communicate with >> insecure hosts using link-local addresses, and vice versa." Can an insecure >> host and SEND-secured host still detect DAD collision on their link-local >> addresses? If not, then we end up duplicate link-local addresses on the same >> link, and this is a no good. As you note above, this was discussed at the San Francisco meeting. However, this is still partially an open problem. The Design Team is looking for a good answer, but the discussion is still ongoing. >> - "An attacker may still be able to >> prevent valid responses or requests from reaching the intended >> recipient. As a result both participants are forced to believe that >> no address collision exists, when there in fact is." >> >> How can the attacker do that? Is it a MitM physically separating victims? I don't remember the context of the quoted paragraph above. However, if it refers to the transition scheme, it is quite possible that the current design will change. In general, I think your questions are very good and to the point. However, it may take time before we have proper answers to all of them. The current goal is to have an -01 version of the draft out fairly soon, probably in early May. --Pekka Nikander -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Apr 24 14:06:56 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25650 for ; Thu, 24 Apr 2003 14:06:55 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3OI5ZRs002129; Thu, 24 Apr 2003 20:05:35 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id JPS2ARGB; Thu, 24 Apr 2003 20:05:36 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h3OI5X203311; Thu, 24 Apr 2003 20:05:33 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3OI4oWI011780; Thu, 24 Apr 2003 20:04:50 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h3OI4o5Z011779; Thu, 24 Apr 2003 20:04:50 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3OI4nWI011775 for ; Thu, 24 Apr 2003 20:04:49 +0200 (MET DST) Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id F2E081C; Thu, 24 Apr 2003 21:14:49 +0300 (EEST) Message-ID: <3EA82762.5060504@nomadiclab.com> Date: Thu, 24 Apr 2003 21:05:22 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Cc: SEND WG Subject: Revised DAD design References: <3EA780A8.1080300@nomadiclab.com> In-Reply-To: <3EA780A8.1080300@nomadiclab.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Alper, The DT made some progress wrt. your questions today. See below. >>> - "If (DAD) clashes are detected after three tries, the node is >>> probably under attack, so it should shut down and report the >>> situation to an administrator." >>> >>> Isn't DAD mechanism protected by CGAs as well? How can the >>> attacker produce the right cryptographic information to claim 3 >>> different IP addresses in a row? We revised the current design. In the new design all ND messages are protected with AH, including Neighbor Solicitations that are used during DAD. To do that, AH protected DAD messages are sent with the tentative address as the source address. This requires small changes on both sending and receiving DAD messages. However, it is fully backwards compatible since non-SEND nodes will ignored the AH protected NS messages. In the new design an attacker cannot produce the right cryptographic information, unless it is able to break public key cryptography. >>> Can an insecure host and SEND-secured host still detect DAD >>> collision on their link-local addresses? If not, then we end up >>> duplicate link-local addresses on the same link, and this is a no >>> good. Our new suggestion is that SEND nodes listen to multicast NS messages from unspecified source address, and if they receive such NS messages that contain their address as the target address, they reply with a similar NS message, i.e. with an NS that has an unspecified source address. If the non-SEND host conforms to the current specifications, it will think that there is a DAD collision, and selects another address. The reason for this design is that it can be implemented without changing SPD implementations. The SPD would contain PASS (don't use IPsec) entries for NS with unspecified source address, and require AH for all other NS/NA messages. There is still one case where this will lead to duplicate link-local addresses. That is, if first a non-SEND node arrives to the link and takes an address into use, and then a SEND node arrives and takes the same address, the non-SEND node will not see the AH protected DAD messages, and the SEND node will not detect the non-SEND node. In the first look one might think that if the arriving SEND node would also send unprotected DAD NS messages, that would solve the problem. Unfortunately it doesn't, for two reasons. Firstly, the SEND node would not be able to receive the unprotected NA messages that the non-SEND node would be sending as replies. Secondly, if the SEND node would listen to those messages, it would become to the DAD DoS attack. Thus, even if it received the unprotected NA messages, it would not be able to act upon them. Thus, there is no harm done if it doesn't even solicit for them. Thus, a collision of link local addresses is possible in this specific scenario. Given the tradeoffs, we think that this is acceptable. --Pekka Nikander -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Apr 24 14:37:26 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26544 for ; Thu, 24 Apr 2003 14:37:25 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3OIbcI3020629; Thu, 24 Apr 2003 20:37:38 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id JN0NSV99; Thu, 24 Apr 2003 20:37:40 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h3OIbbsY029521; Thu, 24 Apr 2003 20:37:37 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3OIbDWI015420; Thu, 24 Apr 2003 20:37:13 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h3OIbCPn015419; Thu, 24 Apr 2003 20:37:12 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3OIbAWI015415 for ; Thu, 24 Apr 2003 20:37:11 +0200 (MET DST) Date: Thu, 24 Apr 2003 11:37:38 -0700 Subject: Re: comments on send-ipsec-00 From: Alper Yegin To: Pekka Nikander CC: James Kempf , SEND WG Message-ID: In-Reply-To: <3EA780A8.1080300@nomadiclab.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pekka, ... >>> - This is a simple, and possibly a dumb question: In what type of networks >>> are >>> we concerned about unauthorized nodes sending bogus router advertisements? >>> Possibly in public access networks, right? Couldn't we simply prevent client >>> hosts from sending RAs by installing filters on the enforcement points (like >>> APs in WLAN hotspots)? Any RA sent on the radio network can be dropped. Sure >>> it is none of the business of the L2 bridge to do that from an architectural >>> point of view, but from a practical point of view...... > > IMHO such an approach might work, but it is clearly outside the scope > of the working group charter. I vaguely remember that we already > discussed this at some point of time, didn't we? I understand this is not the type of solution this WG is looking for. But if we think the problem can be simply and adequately solved that way, does this still leave something that needs to be solved? After all, the ultimate goal is to "solve the problem." If there are scenarios where this approach is not sufficient, it'd be good to understand them. [I had run this by few people face2face, but I don't remember it being discussed in the WG...] ... >>> - Can the routers still send unsolicited advertisements that can be verified >>> by hosts with different Trusted Roots? Or, do they have to unicast a >>> different >>> advertisement to each host? > > As far as I understand the currently proposed design, there are no > changes in respect to the functionality here. So, the routers can > still send unsolicitated advertisements. Sorry, I couldn't understand your answer. So, can a router send an unsolicited advertisement that can be verified by hosts with varying trusted domains? If two hosts have a completely independent chain of trust which leads to different trusted roots, how can the router sign the message that will verify at both hosts? ... >>> - "An attacker may still be able to >>> prevent valid responses or requests from reaching the intended >>> recipient. As a result both participants are forced to believe that >>> no address collision exists, when there in fact is." >>> >>> How can the attacker do that? Is it a MitM physically separating victims? > > I don't remember the context of the quoted paragraph above. However, > if it refers to the transition scheme, it is quite possible that the > current design will change. This quote is from section 12.1 of the draft. I'm trying to undertstand under what conditions we think an attacker can prevent delivery of packets. Alper -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Apr 24 15:26:55 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29634 for ; Thu, 24 Apr 2003 15:26:54 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3OJQsI3026129; Thu, 24 Apr 2003 21:26:54 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id JQAGAQ7H; Thu, 24 Apr 2003 21:26:55 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h3OJQqsY000051; Thu, 24 Apr 2003 21:26:52 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3OJQYWI020838; Thu, 24 Apr 2003 21:26:34 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h3OJQYT3020837; Thu, 24 Apr 2003 21:26:34 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3OJQXWI020833 for ; Thu, 24 Apr 2003 21:26:33 +0200 (MET DST) Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 9C9CC1C; Thu, 24 Apr 2003 22:36:34 +0300 (EEST) Message-ID: <3EA83A8B.1080302@nomadiclab.com> Date: Thu, 24 Apr 2003 22:27:07 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Cc: SEND WG Subject: Re: comments on send-ipsec-00 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Alper Yegin wrote: >>>> ... Couldn't we simply prevent client >>>> hosts from sending RAs by installing filters on the enforcement points (like >>>> APs in WLAN hotspots)? Any RA sent on the radio network can be dropped. Sure >>>> it is none of the business of the L2 bridge to do that from an architectural >>>> point of view, but from a practical point of view...... > > I understand this is not the type of solution this WG is looking for. But if > we think the problem can be simply and adequately solved that way, does this > still leave something that needs to be solved? After all, the ultimate goal > is to "solve the problem." If there are scenarios where this approach is not > sufficient, it'd be good to understand them. [I had run this by few people > face2face, but I don't remember it being discussed in the WG...] AFAIK, IETF is a standardization organization. In this particular case, I don't see how IETF could standardize this, since this seems to cross the IETF/IEEE standardization border. If you see how to proceed with this idea, please go ahead. I'd like to see the idea implemented. In the other hand, if vendors do implement RA filtering, it does not remove the need from doing something at SEND. Firstly, having multiple independent layers of defence doesn't usually hurt. Secondly, the currently planned SEND RA security scheme allows the hosts to authenticate the server. That provides additional assurance that the hosts are connected to the "right" network. > Sorry, I couldn't understand your answer. So, can a router send an > unsolicited advertisement that can be verified by hosts with varying trusted > domains? If two hosts have a completely independent chain of trust which > leads to different trusted roots, how can the router sign the message that > will verify at both hosts? If there are two independent certificate chains that lead to the same router key, yes. And yes, I think that it can be easily done. >>>>- "An attacker may still be able to >>>> prevent valid responses or requests from reaching the intended >>>> recipient. As a result both participants are forced to believe that >>>> no address collision exists, when there in fact is." > This quote is from section 12.1 of the draft. I'm trying to undertstand > under what conditions we think an attacker can prevent delivery of packets. I don't remember why that specific text was added to the draft, but multi-link subnets and MLD spoofing come to my mind. --Pekka Nikander -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Apr 24 16:01:51 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01032 for ; Thu, 24 Apr 2003 16:01:50 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3OJxJRs017001; Thu, 24 Apr 2003 21:59:19 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id JQAGAV69; Thu, 24 Apr 2003 21:59:20 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h3OJxH206728; Thu, 24 Apr 2003 21:59:17 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3OJx1WI024346; Thu, 24 Apr 2003 21:59:01 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h3OJx0EW024345; Thu, 24 Apr 2003 21:59:00 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3OJwwWI024339 for ; Thu, 24 Apr 2003 21:58:59 +0200 (MET DST) Date: Thu, 24 Apr 2003 12:59:31 -0700 Subject: Re: comments on send-ipsec-00 From: Alper Yegin To: Pekka Nikander CC: SEND WG Message-ID: In-Reply-To: <3EA83A8B.1080302@nomadiclab.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit >> I understand this is not the type of solution this WG is looking for. But if >> we think the problem can be simply and adequately solved that way, does this >> still leave something that needs to be solved? After all, the ultimate goal >> is to "solve the problem." If there are scenarios where this approach is not >> sufficient, it'd be good to understand them. [I had run this by few people >> face2face, but I don't remember it being discussed in the WG...] > > AFAIK, IETF is a standardization organization. In this particular > case, I don't see how IETF could standardize this, since this seems > to cross the IETF/IEEE standardization border. I'm not suggesting standardizing this method. I don't see why it has to be a IETF or IEEE standard either. It's a simple, standalone method. My question is if there is a problem left behind for IETF to tackle in the presence of such methods? If yes, we should identify the scenarios and work on them. > If you see how to > proceed with this idea, please go ahead. I'd like to see the idea > implemented. As far as I understand, many current access point products already do some sort of filtering. Maybe exactly this type of filtering, maybe not. But I don't see a technical challenge that prevents anyone from doing this. > > In the other hand, if vendors do implement RA filtering, it does > not remove the need from doing something at SEND. Firstly, having > multiple independent layers of defence doesn't usually hurt. > Secondly, the currently planned SEND RA security scheme allows > the hosts to authenticate the server. That provides additional > assurance that the hosts are connected to the "right" network. This additional benefit is not really in the scope of this WG. This is for network access authentication protocols (e.g., PANA, 802.1x) to deal with. I'm not sure if SEND can provide an adequate solution for network access authentication. > >> Sorry, I couldn't understand your answer. So, can a router send an >> unsolicited advertisement that can be verified by hosts with varying trusted >> domains? If two hosts have a completely independent chain of trust which >> leads to different trusted roots, how can the router sign the message that >> will verify at both hosts? > > If there are two independent certificate chains that lead to > the same router key, yes. And yes, I think that it can be easily done. Which router key is that? > >>>>> - "An attacker may still be able to >>>>> prevent valid responses or requests from reaching the intended >>>>> recipient. As a result both participants are forced to believe that >>>>> no address collision exists, when there in fact is." > >> This quote is from section 12.1 of the draft. I'm trying to undertstand >> under what conditions we think an attacker can prevent delivery of packets. > > I don't remember why that specific text was added to the draft, > but multi-link subnets and MLD spoofing come to my mind. Alper -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Apr 24 17:05:16 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03673 for ; Thu, 24 Apr 2003 17:05:15 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3OL3CRs025105; Thu, 24 Apr 2003 23:03:12 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id JN0NTKF5; Thu, 24 Apr 2003 23:03:14 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h3OL39sY001030; Thu, 24 Apr 2003 23:03:09 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3OL2gWI003035; Thu, 24 Apr 2003 23:02:42 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h3OL2gQr003034; Thu, 24 Apr 2003 23:02:42 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3OL2dWI003030 for ; Thu, 24 Apr 2003 23:02:40 +0200 (MET DST) Message-ID: <021e01c30aa4$7adbdf10$766015ac@DCLKEMPFTP> From: "James Kempf" To: "Alper Yegin" , "Pekka Nikander" Cc: "SEND WG" References: Subject: Re: comments on send-ipsec-00 Date: Thu, 24 Apr 2003 14:00:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Alper, > This additional benefit is not really in the scope of this WG. This is for > network access authentication protocols (e.g., PANA, 802.1x) to deal with. > I'm not sure if SEND can provide an adequate solution for network access > authentication. Security of Router Advertisments is in the SEND charter and is a hole in the RFC 2461 specification of security. Therefore, it will be part of SEND. Such security is not part of PANA's charter either, or are you proposing that it be made part of PANA's charter as . key distribution recently was? jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Apr 24 18:21:20 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08105 for ; Thu, 24 Apr 2003 18:21:20 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3OMLqRs003316; Fri, 25 Apr 2003 00:21:52 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id JN0NTSGG; Fri, 25 Apr 2003 00:21:53 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h3OMLpsY001839; Fri, 25 Apr 2003 00:21:51 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3OMLDWI011772; Fri, 25 Apr 2003 00:21:14 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h3OMLDqD011771; Fri, 25 Apr 2003 00:21:13 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h3OMLBWI011757 for ; Fri, 25 Apr 2003 00:21:12 +0200 (MET DST) Date: Thu, 24 Apr 2003 15:21:46 -0700 Subject: Re: comments on send-ipsec-00 From: Alper Yegin To: James Kempf CC: SEND WG Message-ID: In-Reply-To: <021e01c30aa4$7adbdf10$766015ac@DCLKEMPFTP> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit James, >> This additional benefit is not really in the scope of this WG. This > is for >> network access authentication protocols (e.g., PANA, 802.1x) to deal > with. >> I'm not sure if SEND can provide an adequate solution for network > access >> authentication. > > Security of Router Advertisments is in the SEND charter and is a hole > in the RFC 2461 specification of security. Therefore, it will be part > of SEND. Such security is not part of PANA's charter either, or are > you proposing that it be made part of PANA's charter as . key > distribution recently was? Here is the "additional benefit" being discussed (which is missing in your message): "Secondly, the currently planned SEND RA security scheme allows the hosts to authenticate the server. That provides additional assurance that the hosts are connected to the "right" network." Checking whether a client is connected to the right network, i.e., clients authenticating the network, is in the scope of PANA of course. There is a lot more to it than just verifying if a router is authorized to send any advertisements or authorized to advertise a prefix. No, I'm not suggesting PANA solve router advertisement security problem. At best PANA might help by bootstraping a trust relation, but this is not what we are discussing here anyways... Alper -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html --------------------------------------------------------------------